George Neville-Neil wrote: > Sounds great. One more thought. Can you try this without > IPSEC_FILTERTUNNEL? > Since that copies packets I'm suspicious of it.
Hi, Thanks for the suggestion. Disabling IPSEC_FILTERTUNNEL does not prevent the crashes. I have been using i386 and amd64 virtual machines as well as an amd64 physical machine; this problem can be reproduced fairly reliably on all of them for 7.0 and 7.1 (and we're pretty sure we saw it in 6.x and didn't know what it was at the time). I've pared down the set of steps required to reproduce. Kernel config: | include GENERIC | ident IPSEC | options IPSEC | device crypto /etc/rc.conf: | ipsec_enable="YES" | ipsec_file="/etc/ipsec.conf" em0 is configured for DHCP and running on a 1500 mtu network. /etc/ipsec.conf: | add 10.1.10.234 10.1.10.235 esp 12345 -E 3des-cbc | 0x123456789012345678901234567890123456789012345678; | add 10.1.10.234 10.1.10.235 ah 22345 -A hmac-md5 | 0x12345678901234567890123456789012; | | spdadd 10.1.10.234/32 10.1.10.235/32 any -P out ipsec | esp/transport//require ah/transport//require; This is a minimal IPSEC configuration to cause outbound traffic to that IP be passed through IPSEC. You don't even need to configure the other endpoint to test the crash. Earlier today, I was able to cause a crash using just esp and using just ah. Either one alone or both together exhibit the crashes. A C program that sends long UDP messages is attached (there's a hardcoded remote IP in there). The program sends 2 UDP message of size 1960, sleeping for 3 seconds in between. Most of the time, on a clean boot, the first message is enough to cause a kernel panic. The second message almost always causes a kernel panic. I have never been able to run the program a second time without the system crashing. The exact point of the panic tends to vary. I've seen it frequently occurring in in_cksumdata, but it's all been really close to ip_output. I've been poking around in the debugger for hours over the past couple of days. I can't tell if the mbuf is being corrupted as it's passing through the crypto system or if it's happening in ip_fragment. I'm in a bit over my head in terms of trying to isolate and patch the bug. If anyone has the time to squash it or at least give me some pointers as to where I might look, that would help. -- Chris Cowart Network Technical Lead Network & Infrastructure Services, RSSP-IT UC Berkeley
pgpoPmSF43Ins.pgp
Description: PGP signature
