On Fri, 2002-11-22 at 03:16, Daniel Hartmeier wrote: > On Thu, Nov 21, 2002 at 10:05:47PM -0500, Jason Dixon wrote: > > > Good news and bad news. The -current kernel (on a still -stable system) > > hasn't shown any of the panic problems. I've slammed it with a range of > > 2000 to 40000 igmp frag spoofed packets. However, when I tried to make > > a small change (remove the set limit on states, keep the limit on > > frags), "pfctl -F all && pfctl -f /etc/pf.conf" spit out the following > > error: > > > > pfctl: DIOCADDRULE: Operation not supported by device > > That means you're still running the old userland pfctl with the newer > kernel. Rebuild userland, too.
Duh, sorry. I'm out of town, so I was in a hurry to send back a response before investigating it properly. I'm a jerk. > Are you sure you've been running 3.2-stable before (kernel and > userland)? Because there have been no significant changes to pf_norm.c > (where the assert fired, according to your panic trace), and I can't > reproduce the panic (with -current), either. Yes. I had already created a -stable kernel and userland on this box in order to create a release. > I tcpreplay'd your tcpdump file, verifying that the fragments arrive at > the test box and are reassembled or filtered. The fragments, when > cached, use up an entry in pools pffrent and mclpl each, and a GENERIC > kernel doesn't handle 5000+ mbuf clusters here, so I had to either > increase NMBCLUSTERS or reduce 'limit frag' to avoid running out of > mbufs, but I couldn't cause a panic at all. *shrug* -J.
