bugzilla-daemon@bugzilla.netfilter.org
2006-Mar-17 20:07 UTC
[Bug 443] 2.6 kernel failing in NAT with significant outbound traffic
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=443 ------- Additional Comments From nothingel@hotmail.com 2006-03-17 20:07 MET ------- sorry for the delay...I'll check this out hopefully first of next week. -- Configure bugmail: https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
bugzilla-daemon@bugzilla.netfilter.org
2006-Mar-17 20:07 UTC
[Bug 443] 2.6 kernel failing in NAT with significant outbound traffic
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=443 ------- Additional Comments From nothingel@hotmail.com 2006-03-17 20:07 MET ------- sorry for the delay...I'll check this out hopefully first of next week. -- Configure bugmail: https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
bugzilla-daemon@bugzilla.netfilter.org
2006-Mar-20 23:40 UTC
[Bug 443] 2.6 kernel failing in NAT with significant outbound traffic
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=443 ------- Additional Comments From nothingel@hotmail.com 2006-03-20 23:39 MET ------- Created an attachment (id=225) --> (https://bugzilla.netfilter.org/bugzilla/attachment.cgi?id=225&action=view) capture from linux gateway -- Configure bugmail: https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
bugzilla-daemon@bugzilla.netfilter.org
2006-Mar-20 23:40 UTC
[Bug 443] 2.6 kernel failing in NAT with significant outbound traffic
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=443 ------- Additional Comments From nothingel@hotmail.com 2006-03-20 23:39 MET ------- Created an attachment (id=225) --> (https://bugzilla.netfilter.org/bugzilla/attachment.cgi?id=225&action=view) capture from linux gateway -- Configure bugmail: https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
bugzilla-daemon@bugzilla.netfilter.org
2006-Mar-20 23:41 UTC
[Bug 443] 2.6 kernel failing in NAT with significant outbound traffic
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=443 ------- Additional Comments From nothingel@hotmail.com 2006-03-20 23:41 MET ------- the previous attachment represents "tcpdump -Snn" (as requested). The test was using kernel 2.6.16n and "liberal" option set to "0" The following message was logged: Mar 20 17:16:20 erntsonv-dt kernel: ip_ct_tcp: ACK is over the upper bound (ACKed data not seen yet) IN= OUT= SRC=80.140.102.163 DST=172.30.38.33 LEN=64 TOS=0x00 PREC=0x20 TTL=61 ID=26007 DF PROTO=TCP SPT=21189 DPT=39199 SEQ=1040427439 ACK=1295128653 WINDOW=62928 RES=0x00 ACK URGP=0 OPT (0101080A1AA9CCF0E53F38220101050A7AE6D0B87AE6D610) -- Configure bugmail: https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
bugzilla-daemon@bugzilla.netfilter.org
2006-Mar-20 23:42 UTC
[Bug 443] 2.6 kernel failing in NAT with significant outbound traffic
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=443 ------- Additional Comments From nothingel@hotmail.com 2006-03-20 23:41 MET ------- the previous attachment represents "tcpdump -Snn" (as requested). The test was using kernel 2.6.16n and "liberal" option set to "0" The following message was logged: Mar 20 17:16:20 erntsonv-dt kernel: ip_ct_tcp: ACK is over the upper bound (ACKed data not seen yet) IN= OUT= SRC=80.140.102.163 DST=172.30.38.33 LEN=64 TOS=0x00 PREC=0x20 TTL=61 ID=26007 DF PROTO=TCP SPT=21189 DPT=39199 SEQ=1040427439 ACK=1295128653 WINDOW=62928 RES=0x00 ACK URGP=0 OPT (0101080A1AA9CCF0E53F38220101050A7AE6D0B87AE6D610) -- Configure bugmail: https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
bugzilla-daemon@bugzilla.netfilter.org
2006-Apr-09 18:14 UTC
[Bug 443] 2.6 kernel failing in NAT with significant outbound traffic
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=443 netfilter@linuxace.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kadlec@netfilter.org ------- Additional Comments From netfilter@linuxace.com 2006-04-09 18:14 MET ------- I've looked at the trace and can't see any reason why the TCP window tracking code considers the ACK to be invalid. Perhaps Jozsef has some ideas? -- Configure bugmail: https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
bugzilla-daemon@bugzilla.netfilter.org
2006-Apr-09 18:14 UTC
[Bug 443] 2.6 kernel failing in NAT with significant outbound traffic
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=443 netfilter@linuxace.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kadlec@netfilter.org ------- Additional Comments From netfilter@linuxace.com 2006-04-09 18:14 MET ------- I've looked at the trace and can't see any reason why the TCP window tracking code considers the ACK to be invalid. Perhaps Jozsef has some ideas? -- Configure bugmail: https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
bugzilla-daemon@bugzilla.netfilter.org
2006-Apr-09 18:14 UTC
[Bug 443] 2.6 kernel failing in NAT with significant outbound traffic
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=443 netfilter@linuxace.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kadlec@netfilter.org ------- Additional Comments From netfilter@linuxace.com 2006-04-09 18:14 MET ------- I've looked at the trace and can't see any reason why the TCP window tracking code considers the ACK to be invalid. Perhaps Jozsef has some ideas? -- Configure bugmail: https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You reported the bug, or are watching the reporter.
bugzilla-daemon@bugzilla.netfilter.org
2006-Apr-10 12:06 UTC
[Bug 443] 2.6 kernel failing in NAT with significant outbound traffic
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=443 ------- Additional Comments From kadlec@netfilter.org 2006-04-10 12:06 MET ------- The packet in question is 17:16:20.626142 IP 80.140.102.163.21189 > 172.30.38.33.39199: . ack 1295128653 win 62928 <nop,nop,timestamp 447335664 3846125602,nop,nop, sack sack 1 {2061947064:2061948432}> There must be a gear between the client and the server which munges the TCP sequence numbers: it processes the ACK fields but fails to do so in the SACK option field. Check it by disabling ip_conntrack_tcp_be_liberal on the firewall and disabling SACK on the server. [Actually, you are in a SACK hole: it is better if you disable SACK on all of your machines as it is non-functional.] We should correct the message produced by netfilter in order to make easier to spot such problems: ip_ct_tcp: (S)ACK is over the upper bound -- Configure bugmail: https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
bugzilla-daemon@bugzilla.netfilter.org
2006-Apr-10 12:06 UTC
[Bug 443] 2.6 kernel failing in NAT with significant outbound traffic
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=443 ------- Additional Comments From kadlec@netfilter.org 2006-04-10 12:06 MET ------- The packet in question is 17:16:20.626142 IP 80.140.102.163.21189 > 172.30.38.33.39199: . ack 1295128653 win 62928 <nop,nop,timestamp 447335664 3846125602,nop,nop, sack sack 1 {2061947064:2061948432}> There must be a gear between the client and the server which munges the TCP sequence numbers: it processes the ACK fields but fails to do so in the SACK option field. Check it by disabling ip_conntrack_tcp_be_liberal on the firewall and disabling SACK on the server. [Actually, you are in a SACK hole: it is better if you disable SACK on all of your machines as it is non-functional.] We should correct the message produced by netfilter in order to make easier to spot such problems: ip_ct_tcp: (S)ACK is over the upper bound -- Configure bugmail: https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You reported the bug, or are watching the reporter.
bugzilla-daemon@bugzilla.netfilter.org
2006-Apr-10 12:06 UTC
[Bug 443] 2.6 kernel failing in NAT with significant outbound traffic
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=443 ------- Additional Comments From kadlec@netfilter.org 2006-04-10 12:06 MET ------- The packet in question is 17:16:20.626142 IP 80.140.102.163.21189 > 172.30.38.33.39199: . ack 1295128653 win 62928 <nop,nop,timestamp 447335664 3846125602,nop,nop, sack sack 1 {2061947064:2061948432}> There must be a gear between the client and the server which munges the TCP sequence numbers: it processes the ACK fields but fails to do so in the SACK option field. Check it by disabling ip_conntrack_tcp_be_liberal on the firewall and disabling SACK on the server. [Actually, you are in a SACK hole: it is better if you disable SACK on all of your machines as it is non-functional.] We should correct the message produced by netfilter in order to make easier to spot such problems: ip_ct_tcp: (S)ACK is over the upper bound -- Configure bugmail: https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
bugzilla-daemon@bugzilla.netfilter.org
2006-Apr-10 15:49 UTC
[Bug 443] 2.6 kernel failing in NAT with significant outbound traffic
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=443 ------- Additional Comments From nothingel@hotmail.com 2006-04-10 15:49 MET ------- I'm a little unsure exactly what you'd like to me to? Keep in mind that I cannot alter the upstream routers/firewalls. -- Configure bugmail: https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
bugzilla-daemon@bugzilla.netfilter.org
2006-Apr-10 15:49 UTC
[Bug 443] 2.6 kernel failing in NAT with significant outbound traffic
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=443 ------- Additional Comments From nothingel@hotmail.com 2006-04-10 15:49 MET ------- I'm a little unsure exactly what you'd like to me to? Keep in mind that I cannot alter the upstream routers/firewalls. -- Configure bugmail: https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
bugzilla-daemon@bugzilla.netfilter.org
2006-Apr-10 15:49 UTC
[Bug 443] 2.6 kernel failing in NAT with significant outbound traffic
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=443 ------- Additional Comments From nothingel@hotmail.com 2006-04-10 15:49 MET ------- I'm a little unsure exactly what you'd like to me to? Keep in mind that I cannot alter the upstream routers/firewalls. -- Configure bugmail: https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
bugzilla-daemon@bugzilla.netfilter.org
2006-Apr-10 16:09 UTC
[Bug 443] 2.6 kernel failing in NAT with significant outbound traffic
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=443 ------- Additional Comments From kadlec@netfilter.org 2006-04-10 16:09 MET ------- Please check that the assumption is correct by executing ## on your firewall machine echo 0 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal ## on your client machine echo 0 > /proc/sys/net/ipv4/tcp_sack and then try to trigger the problem. If it still persists, then my assumption is false. If it's true, then you have got two possibilities: - disable TCP window tracking in conntrack in the firewall: echo 1 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal - or disable SACK support on all of your machines behind the firewall: echo 0 > /proc/sys/net/ipv4/tcp_sack The first one is easier but the second one is a more correct solution: as you cannot use SACK, do not advertise it. -- Configure bugmail: https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
bugzilla-daemon@bugzilla.netfilter.org
2006-Apr-10 16:09 UTC
[Bug 443] 2.6 kernel failing in NAT with significant outbound traffic
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=443 ------- Additional Comments From kadlec@netfilter.org 2006-04-10 16:09 MET ------- Please check that the assumption is correct by executing ## on your firewall machine echo 0 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal ## on your client machine echo 0 > /proc/sys/net/ipv4/tcp_sack and then try to trigger the problem. If it still persists, then my assumption is false. If it's true, then you have got two possibilities: - disable TCP window tracking in conntrack in the firewall: echo 1 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal - or disable SACK support on all of your machines behind the firewall: echo 0 > /proc/sys/net/ipv4/tcp_sack The first one is easier but the second one is a more correct solution: as you cannot use SACK, do not advertise it. -- Configure bugmail: https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You reported the bug, or are watching the reporter.
bugzilla-daemon@bugzilla.netfilter.org
2006-Apr-10 16:09 UTC
[Bug 443] 2.6 kernel failing in NAT with significant outbound traffic
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=443 ------- Additional Comments From kadlec@netfilter.org 2006-04-10 16:09 MET ------- Please check that the assumption is correct by executing ## on your firewall machine echo 0 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal ## on your client machine echo 0 > /proc/sys/net/ipv4/tcp_sack and then try to trigger the problem. If it still persists, then my assumption is false. If it's true, then you have got two possibilities: - disable TCP window tracking in conntrack in the firewall: echo 1 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal - or disable SACK support on all of your machines behind the firewall: echo 0 > /proc/sys/net/ipv4/tcp_sack The first one is easier but the second one is a more correct solution: as you cannot use SACK, do not advertise it. -- Configure bugmail: https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
bugzilla-daemon@bugzilla.netfilter.org
2006-Apr-10 18:06 UTC
[Bug 443] 2.6 kernel failing in NAT with significant outbound traffic
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=443 ------- Additional Comments From netfilter@linuxace.com 2006-04-10 18:06 MET ------- Thanks for looking Jozsef - I did miss the sack packet (scrolled off the right side of the screen :). But the ip_ct_tcp log is complaining about ACK=1295128653, which did come in before the sack packet: 17:16:20.597035 IP 80.140.102.163.21189 > 172.30.38.33.39199: . ack 1295128653 win 62928 <nop,nop,timestamp 447335661 3846125602> So shouldn't this ack have adjusted things properly? Or does the logging need to be updated so it complains about the sack option ack instead of the 'main' ack? -- Configure bugmail: https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
bugzilla-daemon@bugzilla.netfilter.org
2006-Apr-10 18:06 UTC
[Bug 443] 2.6 kernel failing in NAT with significant outbound traffic
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=443 ------- Additional Comments From netfilter@linuxace.com 2006-04-10 18:06 MET ------- Thanks for looking Jozsef - I did miss the sack packet (scrolled off the right side of the screen :). But the ip_ct_tcp log is complaining about ACK=1295128653, which did come in before the sack packet: 17:16:20.597035 IP 80.140.102.163.21189 > 172.30.38.33.39199: . ack 1295128653 win 62928 <nop,nop,timestamp 447335661 3846125602> So shouldn't this ack have adjusted things properly? Or does the logging need to be updated so it complains about the sack option ack instead of the 'main' ack? -- Configure bugmail: https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
bugzilla-daemon@bugzilla.netfilter.org
2006-Apr-10 18:06 UTC
[Bug 443] 2.6 kernel failing in NAT with significant outbound traffic
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=443 ------- Additional Comments From netfilter@linuxace.com 2006-04-10 18:06 MET ------- Thanks for looking Jozsef - I did miss the sack packet (scrolled off the right side of the screen :). But the ip_ct_tcp log is complaining about ACK=1295128653, which did come in before the sack packet: 17:16:20.597035 IP 80.140.102.163.21189 > 172.30.38.33.39199: . ack 1295128653 win 62928 <nop,nop,timestamp 447335661 3846125602> So shouldn't this ack have adjusted things properly? Or does the logging need to be updated so it complains about the sack option ack instead of the 'main' ack? -- Configure bugmail: https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You reported the bug, or are watching the reporter.
bugzilla-daemon@bugzilla.netfilter.org
2006-Apr-10 19:23 UTC
[Bug 443] 2.6 kernel failing in NAT with significant outbound traffic
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=443 ------- Additional Comments From kadlec@netfilter.org 2006-04-10 19:22 MET ------- No, it complains about the next packet from 80.140.102.163, with the SACK option. Look at the packet logged by netfilter: ... OPT (0101080A1AA9CCF0E53F38220101050A7AE6D0B87AE6D610) noop,noop,timestamp, noop,noop,sack As I wrote in my first comment we should log such packets as "(S)ACK is over the upper bound" and not simply as "ACK is over the upper bound". -- Configure bugmail: https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
bugzilla-daemon@bugzilla.netfilter.org
2006-Apr-10 19:23 UTC
[Bug 443] 2.6 kernel failing in NAT with significant outbound traffic
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=443 ------- Additional Comments From kadlec@netfilter.org 2006-04-10 19:22 MET ------- No, it complains about the next packet from 80.140.102.163, with the SACK option. Look at the packet logged by netfilter: ... OPT (0101080A1AA9CCF0E53F38220101050A7AE6D0B87AE6D610) noop,noop,timestamp, noop,noop,sack As I wrote in my first comment we should log such packets as "(S)ACK is over the upper bound" and not simply as "ACK is over the upper bound". -- Configure bugmail: https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
bugzilla-daemon@bugzilla.netfilter.org
2006-Apr-10 19:23 UTC
[Bug 443] 2.6 kernel failing in NAT with significant outbound traffic
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=443 ------- Additional Comments From kadlec@netfilter.org 2006-04-10 19:22 MET ------- No, it complains about the next packet from 80.140.102.163, with the SACK option. Look at the packet logged by netfilter: ... OPT (0101080A1AA9CCF0E53F38220101050A7AE6D0B87AE6D610) noop,noop,timestamp, noop,noop,sack As I wrote in my first comment we should log such packets as "(S)ACK is over the upper bound" and not simply as "ACK is over the upper bound". -- Configure bugmail: https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You reported the bug, or are watching the reporter.
bugzilla-daemon@bugzilla.netfilter.org
2006-Apr-11 22:31 UTC
[Bug 443] 2.6 kernel failing in NAT with significant outbound traffic
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=443 ------- Additional Comments From nothingel@hotmail.com 2006-04-11 22:31 MET ------- I did a "echo 0 > /proc/sys/net/ipv4/tcp_sack" on the client machine and the problem disappeared even with ip_conntrack_tcp_be_liberal set to "0". So, I believe the theory has been proven. Unfortunately, I cannot disable SACK on all client machines because some are windows-based (or can this be done on windows too?). Can this condition be detected and automatically compensated for? I'm concerned about others that might encounter this situation and "give up" and say "linux is broken". I only found ip_conntrack_tcp_be_liberal by going through the changelogs one-by-one until I found something that might explain why recent kernels were "broken" whereas older kernels "worked." For now, I will rely on ip_conntrack_tcp_be_liberal. I do NOT doubt that my site is fundamentally flawed but I am not in a position to do anything about it. -- Configure bugmail: https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
bugzilla-daemon@bugzilla.netfilter.org
2006-Apr-11 22:31 UTC
[Bug 443] 2.6 kernel failing in NAT with significant outbound traffic
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=443 ------- Additional Comments From nothingel@hotmail.com 2006-04-11 22:31 MET ------- I did a "echo 0 > /proc/sys/net/ipv4/tcp_sack" on the client machine and the problem disappeared even with ip_conntrack_tcp_be_liberal set to "0". So, I believe the theory has been proven. Unfortunately, I cannot disable SACK on all client machines because some are windows-based (or can this be done on windows too?). Can this condition be detected and automatically compensated for? I'm concerned about others that might encounter this situation and "give up" and say "linux is broken". I only found ip_conntrack_tcp_be_liberal by going through the changelogs one-by-one until I found something that might explain why recent kernels were "broken" whereas older kernels "worked." For now, I will rely on ip_conntrack_tcp_be_liberal. I do NOT doubt that my site is fundamentally flawed but I am not in a position to do anything about it. -- Configure bugmail: https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
bugzilla-daemon@bugzilla.netfilter.org
2006-Apr-11 22:31 UTC
[Bug 443] 2.6 kernel failing in NAT with significant outbound traffic
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=443 ------- Additional Comments From nothingel@hotmail.com 2006-04-11 22:31 MET ------- I did a "echo 0 > /proc/sys/net/ipv4/tcp_sack" on the client machine and the problem disappeared even with ip_conntrack_tcp_be_liberal set to "0". So, I believe the theory has been proven. Unfortunately, I cannot disable SACK on all client machines because some are windows-based (or can this be done on windows too?). Can this condition be detected and automatically compensated for? I'm concerned about others that might encounter this situation and "give up" and say "linux is broken". I only found ip_conntrack_tcp_be_liberal by going through the changelogs one-by-one until I found something that might explain why recent kernels were "broken" whereas older kernels "worked." For now, I will rely on ip_conntrack_tcp_be_liberal. I do NOT doubt that my site is fundamentally flawed but I am not in a position to do anything about it. -- Configure bugmail: https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
bugzilla-daemon@bugzilla.netfilter.org
2006-Apr-12 02:09 UTC
[Bug 443] 2.6 kernel failing in NAT with significant outbound traffic
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=443 netfilter@linuxace.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From netfilter@linuxace.com 2006-04-12 02:09 MET ------- "Can this condition be detected and automatically compensated for? " The TCP window tracking code is a protection mechanism. Automatically compensating for broken TCP stacks would completely defeat the purpose of using it in the first place. Closing bug...no netfilter problem here. -- Configure bugmail: https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
bugzilla-daemon@bugzilla.netfilter.org
2006-Apr-12 02:09 UTC
[Bug 443] 2.6 kernel failing in NAT with significant outbound traffic
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=443 netfilter@linuxace.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From netfilter@linuxace.com 2006-04-12 02:09 MET ------- "Can this condition be detected and automatically compensated for? " The TCP window tracking code is a protection mechanism. Automatically compensating for broken TCP stacks would completely defeat the purpose of using it in the first place. Closing bug...no netfilter problem here. -- Configure bugmail: https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
bugzilla-daemon@bugzilla.netfilter.org
2006-Apr-12 02:09 UTC
[Bug 443] 2.6 kernel failing in NAT with significant outbound traffic
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=443 netfilter@linuxace.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From netfilter@linuxace.com 2006-04-12 02:09 MET ------- "Can this condition be detected and automatically compensated for? " The TCP window tracking code is a protection mechanism. Automatically compensating for broken TCP stacks would completely defeat the purpose of using it in the first place. Closing bug...no netfilter problem here. -- Configure bugmail: https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You reported the bug, or are watching the reporter.
bugzilla-daemon@bugzilla.netfilter.org
2006-Apr-12 11:12 UTC
[Bug 443] 2.6 kernel failing in NAT with significant outbound traffic
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=443 ------- Additional Comments From kadlec@netfilter.org 2006-04-12 11:12 MET ------- To be precise, your site is not flawed but the device somewhere in the uplink. We cannot compensate the bug in conntrack besides the already existing 'ip_conntrack_tcp_be_liberal' flag. But it'd be not hard to write a new TCPOPTSTRIP target which could be used in the mangle table to remove the SACK-permitted option from your outgoing TCP SYN packets. Thus there were no need to disable SACK in all of your machines, one-by-one. -- Configure bugmail: https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You reported the bug, or are watching the reporter.
bugzilla-daemon@bugzilla.netfilter.org
2006-Apr-12 11:12 UTC
[Bug 443] 2.6 kernel failing in NAT with significant outbound traffic
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=443 ------- Additional Comments From kadlec@netfilter.org 2006-04-12 11:12 MET ------- To be precise, your site is not flawed but the device somewhere in the uplink. We cannot compensate the bug in conntrack besides the already existing 'ip_conntrack_tcp_be_liberal' flag. But it'd be not hard to write a new TCPOPTSTRIP target which could be used in the mangle table to remove the SACK-permitted option from your outgoing TCP SYN packets. Thus there were no need to disable SACK in all of your machines, one-by-one. -- Configure bugmail: https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
bugzilla-daemon@bugzilla.netfilter.org
2006-Apr-12 11:12 UTC
[Bug 443] 2.6 kernel failing in NAT with significant outbound traffic
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=443 ------- Additional Comments From kadlec@netfilter.org 2006-04-12 11:12 MET ------- To be precise, your site is not flawed but the device somewhere in the uplink. We cannot compensate the bug in conntrack besides the already existing 'ip_conntrack_tcp_be_liberal' flag. But it'd be not hard to write a new TCPOPTSTRIP target which could be used in the mangle table to remove the SACK-permitted option from your outgoing TCP SYN packets. Thus there were no need to disable SACK in all of your machines, one-by-one. -- Configure bugmail: https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
Possibly Parallel Threads
- [Bug 464] state match sometimes failes RELATED,ESTABLISHED matches
- [Bug 443] 2.6 kernel failing in NAT with significant outbound traffic
- [Bug 738] New: reading beyond buffer limits in nf_conntrack_proto_tcp.c::tcp_options()
- multi-path TCP performance
- speed-tuning samba?