Conntrack problem, machines freeze
Hello, I have simple linux router with three fastethernet cards (intel , e100 driver). About two months ago it started hanging. It's completly freezing machine (no ooops. First of all when it's booting few messages like this appears on screen: NF_IP_ASSERT: ip_conntrack_core.c:1128(ip_conntrack_alter_reply) I suppose it's showing before firewall script load rules (simple nat). After that somtimes it's working very long, sometimes it's freezing after few seconds. One time I've logged this message before it freezes: kernel: LIST_DELETE: ip_conntrack_core.c:302 `>tuplehash [IP_CT_DIR_REPLY]'(decb6084) not in _conntrack_hash[hr]. Components that has been already replaced: - computer hardware (twice to a new one) - fast ethernet cards (tried with intel, realtek and 3com) - fresh system (debian sarge) - switches Router and switches are connected to UPS (dedicated, also replaced). This is a vanilla kernel 2.4.31, problem also exist with kernels: 2.4.30, 2.4.29. I tried also with grsecuriry(hoping it could help) patch, but it wasn't. If you have any idea what I can try to fix please let me know. Thank you for your time. Best regads, Lukasz Spaleniak -- spalek on zigzag dot pl GCM dpu s: a--- C++ UL P+ L+++ E--- W+ N+ K- w O- M V- PGP t--- 5 X+ R- tv-- b DI- D- G e-- h! r y+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Conntrack problem, machines freeze
Hello, I have simple linux router with three fastethernet cards (intel , e100 driver). About two months ago it started hanging. It's completly freezing machine (no ooops. First of all when it's booting few messages like this appears on screen: NF_IP_ASSERT: ip_conntrack_core.c:1128(ip_conntrack_alter_reply) I suppose it's showing before firewall script load rules (simple nat). After that somtimes it's working very long, sometimes it's freezing after few seconds. One time I've logged this message before it freezes: kernel: LIST_DELETE: ip_conntrack_core.c:302 `ct-tuplehash [IP_CT_DIR_REPLY]'(decb6084) not in ip_conntrack_hash[hr]. Components that has been already replaced: - computer hardware (twice to a new one) - fast ethernet cards (tried with intel, realtek and 3com) - fresh system (debian sarge) - switches Router and switches are connected to UPS (dedicated, also replaced). This is a vanilla kernel 2.4.31, problem also exist with kernels: 2.4.30, 2.4.29. I tried also with grsecuriry(hoping it could help) patch, but it wasn't. If you have any idea what I can try to fix please let me know. Thank you for your time. Best regads, Lukasz Spaleniak -- spalek on zigzag dot pl GCM dpu s: a--- C++ UL P+ L+++ E--- W+ N+ K- w O- M V- PGP t--- 5 X+ R- tv-- b DI- D- G e-- h! r y+ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re[2]: kernel oops, fast ethernet bridge, 2.4.31
On Fri, 22 Jul 2005 15:13:33 + (UTC) Joy Leima <[EMAIL PROTECTED]> wrote: > Lukasz, > > I think I have a fix for you. Verify for me that it is the same > problem. Send a large UDP packet through the bridge. I believe the > problem is the ip_fragment code is not taking into account the VLAN > header that needs to be added to the packet when it gets fragmented > on the way out. > > Just send the large UDP packet through the bridge. I use ttcp. If > it panics then I can send you the fix. There are further changed to > ip_output.c Hello Joy, This is exactly this situation which you described. Could you be so kind to send me this patch ? Best regards, Lukasz Spaleniak -- lspaleniak on wroc zigzag pl GCM dpu s: a--- C++ UL P+ L+++ E--- W+ N+ K- w O- M V- PGP t--- 5 X+ R- tv-- b DI- D- G e-- h! r y+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re[2]: kernel oops, fast ethernet bridge, 2.4.31
On Fri, 22 Jul 2005 15:13:33 + (UTC) Joy Leima [EMAIL PROTECTED] wrote: Lukasz, I think I have a fix for you. Verify for me that it is the same problem. Send a large UDP packet through the bridge. I believe the problem is the ip_fragment code is not taking into account the VLAN header that needs to be added to the packet when it gets fragmented on the way out. Just send the large UDP packet through the bridge. I use ttcp. If it panics then I can send you the fix. There are further changed to ip_output.c Hello Joy, This is exactly this situation which you described. Could you be so kind to send me this patch ? Best regards, Lukasz Spaleniak -- lspaleniak on wroc zigzag pl GCM dpu s: a--- C++ UL P+ L+++ E--- W+ N+ K- w O- M V- PGP t--- 5 X+ R- tv-- b DI- D- G e-- h! r y+ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re[2]: kernel oops, fast ethernet bridge, 2.4.31
On Wednesday, July 20, 2005, 9:44:57 PM, Willy Tarreau wrote: > Hello, Hello Willy, > just some basic questions : > - did your configuration change before the oopses started ? (eg: new > matches, etc...) One new machine appears but it generates small traffic rate (by now it's almost unused). > - did the traffic change recently (protocols, data rate) ? eg: new > applications on the network, etc... No - firewall is bridging IPv4 only. There was no dramatic topology change. Those VLANs which are going through this firewall were untouched. > - is it possible that it's being targetted by an attack where it is > installed (unfiltered internet, holiday employees who like to play > with the network, etc...) ? I don't think so that managed IP of firewall was targetet, maybe machines behid firewall but problem appears on eth2 interface which is: internet <-trunk-> eth1(firewall/iptables)eth2<-trunk->(switch ports) <-> servers So it's after iptables ... > I really find it strange that it suddenly started oopsing if nothing > changed. At least it should have been oopsing from day one. It is strange to me too. There is no dependency when it happens. Sometimes traffic is small, sometimes it's normal. Packet rates are around ~2000-3000 pkt/sec - so not so high. Regards, Lukasz -- lspaleniak on wroc zigzag pl GCM dpu s: a--- C++ UL P+ L+++ E--- W+ N+ K- w O- M V- PGP t--- 5 X+ R- tv-- b DI- D- G e-- h! r y+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
kernel oops, fast ethernet bridge, 2.4.31
Hello, I have bridge firewall (linux box) with three fast ethernet cards (one rtl8139 for management and two e100 for bridge). It is running 2.4.31 kernel and iptables v1.2.11. It works ok about one month. Few weeks ago It started ooopsing. First thought was hardware, but it was replaced with a new one and problem still exist. I'm attaching ksymoops analysis of ooops message. I hope I'll help. Some facts: Traffic over this bridge is about ~30 MBit/sec and every frame is tagged with VID (802.1q). Problem exist also on 2.4.30 kernel. Kernel is patched with ebtables patch. Ooops completeley freezes machine, only hard reset takes effect. Nothing is placed into syslog. The ksymooops analisis is attached as text file. Anyone know this bug/problem ? Regards, Lukasz Spaleniak -- spalek on wroc zigzag pl GCM dpu s: a--- C++ UL P+ L+++ E--- W+ N+ K- w O- M V- PGP t--- 5 X+ R- tv-- b DI- D- G e-- h! r y+ lalala Description: Binary data
kernel oops, fast ethernet bridge, 2.4.31
Hello, I have bridge firewall (linux box) with three fast ethernet cards (one rtl8139 for management and two e100 for bridge). It is running 2.4.31 kernel and iptables v1.2.11. It works ok about one month. Few weeks ago It started ooopsing. First thought was hardware, but it was replaced with a new one and problem still exist. I'm attaching ksymoops analysis of ooops message. I hope I'll help. Some facts: Traffic over this bridge is about ~30 MBit/sec and every frame is tagged with VID (802.1q). Problem exist also on 2.4.30 kernel. Kernel is patched with ebtables patch. Ooops completeley freezes machine, only hard reset takes effect. Nothing is placed into syslog. The ksymooops analisis is attached as text file. Anyone know this bug/problem ? Regards, Lukasz Spaleniak -- spalek on wroc zigzag pl GCM dpu s: a--- C++ UL P+ L+++ E--- W+ N+ K- w O- M V- PGP t--- 5 X+ R- tv-- b DI- D- G e-- h! r y+ lalala Description: Binary data
Re[2]: kernel oops, fast ethernet bridge, 2.4.31
On Wednesday, July 20, 2005, 9:44:57 PM, Willy Tarreau wrote: Hello, Hello Willy, just some basic questions : - did your configuration change before the oopses started ? (eg: new matches, etc...) One new machine appears but it generates small traffic rate (by now it's almost unused). - did the traffic change recently (protocols, data rate) ? eg: new applications on the network, etc... No - firewall is bridging IPv4 only. There was no dramatic topology change. Those VLANs which are going through this firewall were untouched. - is it possible that it's being targetted by an attack where it is installed (unfiltered internet, holiday employees who like to play with the network, etc...) ? I don't think so that managed IP of firewall was targetet, maybe machines behid firewall but problem appears on eth2 interface which is: internet -trunk- eth1(firewall/iptables)eth2-trunk-(switch ports) - servers So it's after iptables ... I really find it strange that it suddenly started oopsing if nothing changed. At least it should have been oopsing from day one. It is strange to me too. There is no dependency when it happens. Sometimes traffic is small, sometimes it's normal. Packet rates are around ~2000-3000 pkt/sec - so not so high. Regards, Lukasz -- lspaleniak on wroc zigzag pl GCM dpu s: a--- C++ UL P+ L+++ E--- W+ N+ K- w O- M V- PGP t--- 5 X+ R- tv-- b DI- D- G e-- h! r y+ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/