netfilter buglog - Mar 2006 - [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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.