[Openswan Users] roadwarrior over pppoe

[David McCullough]

Jivin Paulo F. Sedrez lays it down ...
> On Wed, 2007-08-29 at 14:50 +1000, David McCullough wrote:
> > Jivin Paul Wouters lays it down ...
> > > On Wed, 29 Aug 2007, David McCullough wrote:
> > > >
> > > > The changes are not that hard,  just bulk edits really.
> 
> Yeah, I can confirm that: bulk edits. But one has to know what is being
> edited...

:-)

> > > > We did it as part of ocf-linux.sourceforge.net,  and the patch for
> > > > openswan-2.4.9 works on 2.6.22,  but is probably too much change
> > > > unless you really want OCF support.
> > > >
> > > > So if someone wanted to just fix up the vanilla 2.4.9 for 2.6.22 they
> > > > would find all the mods in the ocf-openswan-2.4.9-20070727.patch.gz
> > > > Specifically look at the changes in:
> > > >
> > > > 	openswan/linux/include/openswan/ipsec_kversion.h
> > > >
> > > > mostly revolving around the macros ip_hdr, skb_network_header,
> > > > skb_set_network_header and so on.  Then look at how they were used in the
> > > > patch to know how to fix up the stock 2.4.9 source.
> 
> I am going to this code right now, and - besides the skb and ocf stuff -
> it has a lot of interesting things - some corrections, optimizations and
> extensive logging included.

Yeah,  most of that has been pushed at and possibly into 3.0.
Some is more specific to our use and may not have been.

> > > Ahh, if you made the changes using ipsec_kversion, then I'll merge those in
> > > for 2.4.10.
> 
> I will try to make a patch for it in the next few days, but I will left
> out most of the code addition from ocf - I will focus in 2.6.22
> compatibility.

Good move.

> I don't known if the other improvements should go in
> 2.4.x version, if there is a 2.5.x to be released really soon. If there
> is not, I strong suggest David to submit the improvements that could
> into the 2.4.x branch.

That basically means cherry picking the OCF patch as you have done.

> There is one, in particular, that came to my attention, since it looks
> like a bug in one of the implementations of pluto: in the file
> programs/pluto/kernel.c, line 1289 and next of stock 2.4.9:
> 
>         orphaned_holds = p->next;
>         pfree(orphaned_holds);
> 
> David's patch:
> 
>         orphaned_holds = p->next;
>         pfree(p);

Yep,  thats a potential crash (and I think for us it did).
We tend to run on a lot of different platforms (x86, arm-le, arm-be,
superH, mips, you get the picture ;-).  We also use uClibc,  so the
errors that show up are different.

> I think David's is right, and the stock 2.4.9 shall sometime eat
> resources or crash.
> 
> (BTW, David, what is LEDMAN?)

LEDMAN is out LED driver for all our platforms.  Some devices have VPN
leds that need to be turned on/off appropriately. 

You'll also see "statsd" calls in there.  We use these hooks to push
tunnel state information into our stats collection daemon rather than
poll for them.

I would not include the LEDMAN/OCF/stats changes in 2.4.9 and
questionably laster versions as well,

Cheers,
Davidm

-- 
David McCullough,  david_mccullough at securecomputing.com,   Ph:+61 734352815
Secure Computing - SnapGear  http://www.uCdot.org http://www.cyberguard.com