[Openswan dev] IPComp

[Dominique Blas]

Le vendredi 2 Juillet 2004 13:36, Paul Wouters a écrit :
> On Thu, 1 Jul 2004, Dominique Blas wrote:
> 
> > Indeed, when using IPComp it works, when not using the compress it doesn't not work any more (no packet comes back through the tunnel).
> > With IPComp it works but only packets that size less than 348 bytes (ping -s 319 works) can come back through the tunnel (they go through but don't come back; however the echo reply
> > has exactly the same size as the echo request packet) and there is no error in the syslog.
> > I confirm that the scenario is the same with packets of 1500 bytes : they go through but don't come back.
> > 
> > Of course, when I try to send packet from the SFreeswan, only packets with an overall size of less that 348 (ping -s 320) can go through.
> 
> I can't advise on this bit. I will leave this to people who know more about
> the internals then I do, but.
> 
> > WITHOUT compression big packets (> 1000 bytes) can go through the interface (and come back) BUT many memory allocations from pluto failed (lack of memory) and,
> > finally, the tunnel hangs.
> 
Hi Paul,

> There have been a few fixes to pluto memory leaks from Hugh Redelmeier. 
Thank you aul, but I think was not enough precise in my mail. I apologize. The messages about lack of memory come from the Openswan 2.2.20dr1 NOT from the
SFS side. 
These messages don't appear when using compression (but return packets [ SFS -> O2 direction] are then limited to 348 bytes and fragmentation is not triggered).

>> I 
> recommend you upgrade the SFS machines to Openswan-1, which is a continuation
> of that SFS tree. 

Not obvious since this machine is an old one (kernel 2.4.19) and is more critical (several tunnels) than the one I'm testing today.

>> If you still experience problems, can you edit pluto's 
> Makefile and enable -DLEAK_DETECTIVE ?
> Then run it for a while, but before completely exhausting the memory,
In fact, O2 doesn't exhaust memory at all (neither SFS). It simply indicate in syslog that it cannot allocate more memory (I don't know how much it needs) and tunnel hangs immediatly.
This doesn't occur with compression set.

And it works between racoon and SFS (with compression set). 
But racoon occupies more memory than O2 (!?) [*], have still a memory leak (!!!?)[*] and doesn't have the DPE feature.

db

[*] But doesn't claim for misallocation.