Okay, for one final test, I turned off DEVICE_POLLING (it's built in the kernel but is not enabled via the kern.polling.enable=0 sysctl setting).
The box ran for a LOT longer (it's the weekend, I have slower traffic so I was able to handle it), but still crashed. So it's still something to do with ICMP I am sure of it. Greg * Greg Rumple ([EMAIL PROTECTED]) [030531 07:27]: > Well the bad news is I tried this live as well. I moved kern.hz up to > 5000 and let it go. Sure enough about 12 hours later it rebooted with > the normal core. I've tried turning off DEVICE_POLLING but the box does > NOT have enough cpu to handle that condition. It just pegs at 100% > interrupt bound (according to top) and dies. So for now gonna go back > to my "BROKEN" icmp blocking. > > Greg > > * Greg Rumple ([EMAIL PROTECTED]) [030530 20:27]: > > Okay in further crazy testing, so I switched back on DEVICE_POLLING, and > > cranked HZ up to 5000 (kern.hz="5000" in /boot/loader.conf) and now it > > doesn't reboot. Okay, I'm now baffled. So it's some kind of overflow > > with the slower HZ="1000" value? *shrug*. Anyway, I put the live > > device back up at my colo this morning, and it's been fine all day. I > > just blocked all ICMP at the router in front of the firewall (it runs > > FreeBSD as well with Zebra and happens to also run IPFIREWALL with > > DUMMYNET for traffic shaping). I'll crank the value up on my live site > > as well and see if the problem also goes away there. So far I've been > > sending packets at it with the 7plagues.pl script for quite a while now. > > > > Greg > > > > * Greg Rumple ([EMAIL PROTECTED]) [030530 20:10]: > > > Note it does not lose time if I disable DEVICE_POLLING > > > (kern.polling.enable=0). I've also been unable to cause the box to > > > reboot when not using DEVICE_POLLING, but I believe a large factor of > > > that is the box runs out of CPU (100% pegged in interrupt) and just > > > can't handle the packet stream fast enough. > > > > > > Greg > > > > > > * Darren Reed ([EMAIL PROTECTED]) [030530 19:27]: > > > > In some email I received from Greg Rumple, sie wrote: > > > > > And sure enough, I found a DoS tool that will crash it (with the error I > > > > > was getting) like clockwork. I can cause it to crash in as little as 10 > > > > > packets (it's an ICMP exploit btw interestingly enough (and rebuilding > > > > > the kernel with no INET6 didn't help btw)). > > > > > > > > > > I also started taking pieces out of the kernel in an attempt to narrow > > > > > it down. What I found was it only happens when I use the BIMAP piece of > > > > > the puzzle (along with the proxy arp of course). I basically stripped > > > > > my system down to the following. > > > > > > > > > > No ipf rules (so allow everything) > > > > > > > > > > ipnat.rules > > > > > ----------- > > > > > bimap fxp0 10.10.2.231/32 -> 1.2.3.231/32 > > > > > > > > If you remove the next two rules, it still panic's ? > > > > > > > > > map fxp0 10.10.2.0/24 -> 1.2.3.70/32 portmap tcp/udp 1025:65000 > > > > > map fxp0 10.10.2.0/24 -> 1.2.3.70/32 > > > > > > > > Darren > > > > > > > > > > -- > > > Greg Rumple > > > [EMAIL PROTECTED] > > > > > > > -- > > Greg Rumple > > [EMAIL PROTECTED] > > > > -- > Greg Rumple > [EMAIL PROTECTED] > -- Greg Rumple [EMAIL PROTECTED]
