Kernel panic when routing large pings on an XScale (IXP425).

Kernel panic when routing large pings on an XScale (IXP425).

[Cian Masterson]

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):~#

Re: Kernel panic when routing large pings on an XScale (IXP425).

[Gary W. Smith]

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@klasonline.com> 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):~#
> 
> 
> 

Re: Kernel panic when routing large pings on an XScale (IXP425).

[Eduardo Spremolla]

I experience the very same error just yesterday:
KERNEL PANIC - Not Syncing: net/ipv4/xfrm4_output.c:106 : spin_lock
(net/xfrm/xfrm_state.C : ddd2b014) already locked by
net/ipv4/xfrm4_output.c/106

on a Fedora Core2 box running 2.6.10-1.771_FC2 kernel and 
ipsec-tools-0.5-2.fc2.

the curiosity is that this box was running ok for more than a month with
this policies:
 
spdadd 10.3.1.0/24 10.3.4.0/24 any -P in ipsec
           esp/tunnel/CENTER_IP-MY_IP/require;

spdadd 10.3.4.0/24 10.3.1.0/24 any -P out ipsec
           esp/tunnel/MY_IP-CENTER_IP/require;

and start to trouble when changed to :


spdadd 10.0.0.0/8 10.3.4.0/24 any -P in ipsec
           esp/tunnel/CENTER_IP-MY_IP/require;

spdadd 10.3.4.0/24 10.0.0.0/8 any -P out ipsec
           esp/tunnel/MY_IP-CENTER_IP/require;


LALO



On Mon, 2005-05-30 at 10:46 -0700, Gary W. Smith wrote:
> 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@klasonline.com> 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):~#
> > 
> > 
> > 
> 
> 


Este e-mail y cualquier posible archivo adjunto está dirigido únicamente al destinatario del mensaje y contiene información que puede ser confidencial. Si Ud. no es el destinatario correcto por favor notifique al remitente respondiendo este mensaje y elimine inmediatamente el e-mail y los posibles archivos adjuntos al mismo de su sistema. Está prohibida cualquier utilización, difusión o copia de este e-mail por cualquier persona o entidad que no sean las específicas destinatarias del mensaje. ANTEL no acepta ninguna responsabilidad con respecto a cualquier comunicación que haya sido emitida incumpliendo nuestra Política de Seguridad de la Información.
. . . . . . . . .
This e-mail and any attachment is confidential and is intended solely for the addressee(s). If you are not intended recipient please inform the sender inmediately, answering this e-mail and delete it as well as the attached files. Any use, circulation or copy of this e-mail by any person or entity that not is the specific addressee(s) is prohibited. ANTEL is not responsible for any communication emitted without respecting our Information Security Policy.

RE: Kernel panic when routing large pings on an XScale (IXP425).

[Gary W. Smith]

The patch over on the RH site will fix the problem though.  My problem
also started when I changed the subnetting to cover a broader range of
subnets that also route to other locations.


> -----Original Message-----
> From: Eduardo Spremolla [mailto:edspremolla@antel.com.uy]
> Sent: Tuesday, May 31, 2005 6:08 AM
> To: Gary W. Smith
> Cc: Cian Masterson; netfilter@lists.netfilter.org
> Subject: Re: Kernel panic when routing large pings on an XScale
(IXP425).
> 
> I experience the very same error just yesterday:
> KERNEL PANIC - Not Syncing: net/ipv4/xfrm4_output.c:106 : spin_lock
> (net/xfrm/xfrm_state.C : ddd2b014) already locked by
> net/ipv4/xfrm4_output.c/106
> 
> on a Fedora Core2 box running 2.6.10-1.771_FC2 kernel and
> ipsec-tools-0.5-2.fc2.
> 
> the curiosity is that this box was running ok for more than a month
with
> this policies:
> 
> spdadd 10.3.1.0/24 10.3.4.0/24 any -P in ipsec
>            esp/tunnel/CENTER_IP-MY_IP/require;
> 
> spdadd 10.3.4.0/24 10.3.1.0/24 any -P out ipsec
>            esp/tunnel/MY_IP-CENTER_IP/require;
> 
> and start to trouble when changed to :
> 
> 
> spdadd 10.0.0.0/8 10.3.4.0/24 any -P in ipsec
>            esp/tunnel/CENTER_IP-MY_IP/require;
> 
> spdadd 10.3.4.0/24 10.0.0.0/8 any -P out ipsec
>            esp/tunnel/MY_IP-CENTER_IP/require;
> 
> 
> LALO
> 
> 
> 
> On Mon, 2005-05-30 at 10:46 -0700, Gary W. Smith wrote:
> > 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
> >