On Fri, 11 Mar 2005, Herbert Xu wrote:
What does CTRL-SCROLLLOCK or SysRq tell us?
The kernel locks up solid - no SysRq, capslock/numlock lights don't toggle
when hitting the keys - completely dead.
I've managed to work out what causes it though:
I have overlapping subnets on the IPSEC tunnel - on the local side there
is 10.101.0.0/16 and on the remote side there is 10.0.0.0/8. The IPSEC
server is 10.101.0.254. The problem is that the policies I had required:
10.101.0.0/16 -> 10.0.0.0/8 Requires AH and ESP
10.0.0.0/8 -> 10.101.0.0/16 Requires AH and ESP
This obviously also matches traffic sent from 10.101.0.254 (the IPSEC
server) to any machine on the local 10.101.0.0/16 network. And since
there is no SA for that traffic it gets dropped.
This was a configuration mistake on my part and admittedly it shouldn't
work properly - however, it triggered a kernel bug: sending a packet with
the DF flag set which will grow to be > the MTU when encrypted causes the
kernel to generate an ICMP Frag Needed packet, which got caught by the
policy and this triggered the kernel to lock up hard.
So whilest the error in the configuration legitimately causes parts of the
network to not work, it certainly shouldn't have caused the kernel to lock
up. It seems the problem is occurring when the kernel generates a packet
which the policy drops.
I have fixed my configuration now so that I have policies like:
10.101.0.0/16 -> 10.101.0.0/16 None
10.101.0.0/16 -> 10.0.0.0/8 Requires AH and ESP
10.0.0.0/8 -> 10.101.0.0/16 Requires AH and ESP
Since the policy nolonger catches the kernel-generated packets the problem
nolonger occurs for me, but obviously there is a bug there that should
really be fixed.
- Steve Hill (BSc)
Senior Software Developer Email: steve@xxxxxxxxxxxx
Navaho Technologies Ltd. Tel: +44-870-7034015
|