[Openswan dev] IPComp
dblas at blas.net
Fri Jul 2 22:48:24 CEST 2004
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.
> > 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: "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: "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,
More information about the Dev