[Openswan dev] IPComp

[Dominique Blas]

Le vendredi 2 Juillet 2004 17:57, Paul Wouters a écrit :
> On Fri, 2 Jul 2004, D. Hugh Redelmeier wrote:
> 
> > | I have to say that my VPN head is a small machine with << only >> 64 MB
> > | of memory. That's fine for testing such configuration. I'm convinced
> > | that with 128MB I'd not see these behaviours.
> 
> I am not.
I was talking about the messages not the fact that, with IPComp, packets are << shrinked >> to 348 bytes.
>  
> > | 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.
> 
> Odd.
Yes.
>  
> > Pluto doesn't see the IPsec packets (for data transmission through
> > the tunnel), only the IKE packets (for negotiating the tunnel).  So
> > IPcomp should not in any way affect the amount of memory Pluto
> > allocates.
Please take into account the behavior of yesterday : the memory allocation occured when no compression was set.

> > 
> > A barf would be good.  Since I'm not working on *Swan these days, I
> > would not be the one to look at it.
> 
> He mailed me the barfs seperately. the key line is:
> 
> Jul  2 15:57:30 vin pluto[29579]: "BRU" #3: ERROR: netlink response for Add SA comp.661a at hhh.hhh.hhh.158 included errno 12: Cannot allocate memory
> Jul  2 15:57:30 vin pluto[29579]: "BRU" #4: ERROR: netlink response for Add SA comp.661a at hhh.hhh.hhh.158 included errno 12: Cannot allocate memory
> 
> The memory usage from the same barf shows:
> 
> + cat /proc/meminfo
> MemTotal:        56044 kB
> MemFree:          1892 kB
> Buffers:         30360 kB
> Cached:           7492 kB
> SwapCached:          0 kB
> Active:          28660 kB
> Inactive:        11112 kB
> HighTotal:           0 kB
> HighFree:            0 kB
> LowTotal:        56044 kB
> LowFree:          1892 kB
> SwapTotal:           0 kB
> SwapFree:            0 kB
> Dirty:               0 kB
> Writeback:           0 kB
> Mapped:           4388 kB
> Slab:            13412 kB
> Committed_AS:     5204 kB
> PageTables:        220 kB
> VmallocTotal:   974768 kB
> VmallocUsed:       388 kB
> VmallocChunk:   974180 kB


> 
> Which looks to me there is plenty of memory available (1892kB plus buffers/cache)
> 
Yes, the stats said there is plenty of memory ( ~ 35M) but the reality is a bit different.
That could help you maybe.

In this configuration, when I launch ntpd (~ 1M of RSS) and snmpd (~ 4M of RSS) there is a big probability that one or the other
or both were killed by the kernel because of exhaustion of memory.
Which can we believe the stats or the kernel decision ?
And if there is a bug in memory allocation (it's a 2.6.5 kernel) it doesn't, from my own point of view, 
solely explain the fact that IPcomp (OS2) versus compress (SFS) has this kind of behavior.

> This seems more likely a kernel bug in either the netlink code, or the ipsec 
> code of the 2.6 kernel, or maybe a bug in how we call the netlink code?
> 
> If you want an "easy" way out, I recommend trying to run with a 2.4 kernel
> and KLIPS for now, since you are using a standard Pentium-II based PC.

Sure SFS works well but I started to switch to 2.6 for some reasons a few months ago and can't go back no.
What I'm going to do is to test OS2 with a 2.6.7. I cannot test with the current machine since it is 300 miles far from here
so I'll test with my machine here but the conditons will be differents : 1 GB of memory !

I'll inform you of the results as soon as possible,

Best,

db