I experienced a similar problem when I was doing some IPSEC stuff with IPTABLES under RHEL 4. There was an issue with a TCP packet being locked by the system and in a chain and under a certain case it would attempt to lock it again. Not sure of the complete details though. Anyways, after talking with some people about my problem it had to do with locking of the chain before passing it around through other chains for IPSEC where it had to traverse the same table again. It sounds similar to my problem. Here is the link to the RedHat bug I submitted (and was closed) some time ago. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=154347 It does require a kernel recompile as it's a kernel bug. Hope this helps. Gary Smith On 5/30/05 7:26 AM, "Cian Masterson" <cianm@xxxxxxxxxxxxxx> wrote: > Hi, > > I am using iptables on an Intel ixp425 (XScale/ARM processor) and am > finding that I get a kernel panic when I try to send large (65k) pings > to the board, or route them across the board. Iptables is not > configured with any rules (see below) so all traffic is passed through > the board. I don't see any problems with regular pings/FTP > transfers/etc and I have left a chain of boards passing traffic over the > weekend with no problems, however the board will always experience a > kernel panic within 30 seconds of me initiating large pings. I have > applied the ixp425_eth_1_1_update_nf_bridge.patch patch that I got from > Intel > (http://developer.intel.com/design/network/products/npfamily/ixp400_osc.htm) > to no avail. I am running version 1.4 of Intel's software but before > anyone suggests it upgrading to 1.5 is simply not an option at this > point, unfortunately. > > If I don't insert the iptables modules the board passes large pings > without any problems so it is definitely a ixp425_eth.o/netfilter > interaction problem. I've downloaded and searched through the archives > for this board and have found a posting from Rob Ranslam of Intel > stating that if I also have ebtables then I'll need an extra patch from > sourceforge, however I *don't* have ebtables so I can't see how that > patch would be needed in my case. The documentation for the Intel patch > seems to relate to bridging, and I've seen posts from others who say > routing works but bridging doesn't but my problem definitely relates to > routing. Has anyone seen a problem like this and/or can anyone offer > any ideas as to where I should be looking for the problem as I'm a > netfilter newbie? Thanks. > > Slan, > Cian > > PS: Below is the output of iptables --list for reference; > root@(none):~# iptables > --list > Chain INPUT (policy > ACCEPT) > target prot opt source > destination > > > > Chain FORWARD (policy > ACCEPT) > target prot opt source > destination > > > > Chain OUTPUT (policy > ACCEPT) > target prot opt source > destination > root@(none):~# > > >
