Well the only thing to be sure about the issue would be to check if the
behaviour also occurs with for example strongswan or racoon as well - it
is possible that openswan may have problems when rekeying under heavy
traffic but without further testing this cannot be verified.
--
You received this
I'm not convinced this is 'a kernel bug' as opposed to being openswan
related - we only saw it under heavy VPN traffic, and the problem
immediately resolved itself if the VPN was restarted.
it's not solved, but worked around. we've been running a newer stock
kernel rather than the lucid ones.
--
This problem is not related to openswan but to the kernel so this bug
should be closed or reassigned to the kernel maintainers - is the
problem already solved for you?
** Changed in: openswan (Ubuntu)
Status: New => Invalid
** Changed in: openswan (Ubuntu)
Assignee: (unassigned) => Ha
so this is not specifically a ubuntu kernel bug. a stock 2.6.32.15
kernel also shows the issue.
it looks like there were some IPSEC locking fixes in net/ipv4/ah4.c that
went on between 2.6.32.15 (broken, just like the lucid kernel) and
2.6.33.5 (working), specifically commit
dff3bb0626279bae04ed10
just tried the 2.6.35-020635rc3-generic testing kernel from maverick. it
also seems to be good, but doesn't seem to have apparmor?
I was (a) hoping for apparmor support and (b) a little suspicious since
apparmor shows up in the stack trace I attached.. but it's not in either
of the 'good' kernels.
