I have found 2.6-test10.1.95, at least, has ECN turned on. This was breaking many websites for me. Many firewalls are known to have issues with ECN. One example is at least some PIX firewalls. Sadly it seems to more corporate the site, the more likely it is to break.
Workarounds:
echo 0 > /proc/sys/net/ipv4/tcp_ecn
net.ipv4.tcp_ecn = 0 in /etc/sysctl.conf
Fix:
Recompile kernel without ECN support
P.S. arjanv Please Fix!
On Tue, Nov 25, 2003 at 08:12:46PM -0800, Nathan G. Grennan wrote: [snip]
Workarounds:
echo 0 > /proc/sys/net/ipv4/tcp_ecn
net.ipv4.tcp_ecn = 0 in /etc/sysctl.conf
Fix:
Recompile kernel without ECN support
P.S. arjanv Please Fix!
I'd argue that the /etc/sysctl.conf line is the real "fix", insofar as disabling ECN at all can be considered a "fix" and not a "workaround". Then people have the option of editing /etc/sysctl.conf to re-enable ECN, without having to recompile the kernel.
(Mandrake has been doing this since one of their 8.x releases, BTW.)
-Barry K. Nathan barryn@pobox.com
On Tue, Nov 25, 2003 at 08:12:46PM -0800, Nathan G. Grennan wrote:
I have found 2.6-test10.1.95, at least, has ECN turned on. This was breaking many websites for me. Many firewalls are known to have issues with ECN. One example is at least some PIX firewalls. Sadly it seems to more corporate the site, the more likely it is to break.
the sysadmins of those sites need to upgrade their firmware to be compliant with internet standards (and iirc the broken firmware is also superceded by a series of security upgrades which all have this bug fixed as well)
On Wed, 2003-11-26 at 01:29, Arjan van de Ven wrote:
the sysadmins of those sites need to upgrade their firmware to be compliant with internet standards (and iirc the broken firmware is also superceded by a series of security upgrades which all have this bug fixed as well)
I understand it is a standard, but in this case I take a pragmatist approach instead of a idealist. Past kernels don't have this on by default, and mysteriously breaking many sites is very bad whatever the reason. Another example is that you can set your smtp server to be very strict to RFC, but do most people want to ignore legitimate mail, no.
At the very least put a warning in your readme.txt. I and I am sure many others would prefer it set back to disabled by default. If you plan to leave it this way in future official releases, at the bare minimum it should be in the release notes, if not option in the installer/firstboot with a warning.
Three sites in two days is bad, and I am sure the list would grow. I know in the past when I had tried ECN I was cut off from a site I do business with, but now that site works just fine with it.
I will try e-mailing the webmasters of these sites to get them to talk to their network or security administrators about the issue.
On Tue, 2003-11-25 at 22:19, Barry K. Nathan wrote:
I'd argue that the /etc/sysctl.conf line is the real "fix", insofar as disabling ECN at all can be considered a "fix" and not a "workaround". Then people have the option of editing /etc/sysctl.conf to re-enable ECN, without having to recompile the kernel.
This could be argued, but the main problem with it is not every newbie knows about it. Even though I knew about it from the past it took me a few days to put two and two together. Ideally you could enable ECN support, but change the default from enabled to disabled.
As far as I know there isn't even a large gain from it. So if it is a small gain for a big loss of functionality by default, I say disable by default.
(Mandrake has been doing this since one of their 8.x releases, BTW.)
Another reason not to use Mandrake. The last time I tried them was in the 8.x series and I found it too buggy.
On Wed, 26 Nov 2003, Nathan G. Grennan wrote:
On Tue, 2003-11-25 at 22:19, Barry K. Nathan wrote:
I'd argue that the /etc/sysctl.conf line is the real "fix", insofar as disabling ECN at all can be considered a "fix" and not a "workaround". Then people have the option of editing /etc/sysctl.conf to re-enable ECN, without having to recompile the kernel.
This could be argued, but the main problem with it is not every newbie knows about it. Even though I knew about it from the past it took me a few days to put two and two together. Ideally you could enable ECN support, but change the default from enabled to disabled.
You are using test kernels. You are supposed to know what you are doing. If you are going to test you should test everything possible. Newbies are not supposed to be using test kernels if they do then the problems are on them.
As far as I know there isn't even a large gain from it. So if it is a small gain for a big loss of functionality by default, I say disable by default.
Maybe in production but not in test. Otherwise it will never get tested.
.....Tom
On Wed, 2003-11-26 at 01:29, Arjan van de Ven wrote:
On Tue, Nov 25, 2003 at 08:12:46PM -0800, Nathan G. Grennan wrote:
I have found 2.6-test10.1.95, at least, has ECN turned on. This was breaking many websites for me. Many firewalls are known to have issues with ECN. One example is at least some PIX firewalls. Sadly it seems to more corporate the site, the more likely it is to break.
the sysadmins of those sites need to upgrade their firmware to be compliant with internet standards (and iirc the broken firmware is also superceded by a series of security upgrades which all have this bug fixed as well)
The sad state of firewall vendors is shown by the fact that you can't even connect to any of Wells Fargo's online banking with ECN enabled.
I know that in the past a timeout ECN failover has been considered, but the performance hit would be too large. Are there any thoughts about a rule based system for making ECN exceptions on outgoing connections?
Alternatively it could also be moved into userspace as a socket option.
-Kit
On 2003-11-26 at 10:29:53+0100 Arjan van de Ven arjanv@redhat.com wrote:
the sysadmins of those [broken] sites need to upgrade their firmware to be compliant with internet standards
Unfortunately, there's only one thing that can make that happen universally, and it hasn't happened yet. :(
Until then, most sites that are stupid enough to implement broken firewalls in the first place will smugly ignore anyone who tries to tell them that their firewalls are broken, thinking that they've just deflected a "security hack" by someone trying to convince them to "let their guard down". Been there; done that.
On 2003-12-04 at 10:22:40-0800 Kit Knox kit@rootshell.com wrote:
I know that in the past a timeout ECN failover has been considered, but the performance hit would be too large. Are there any thoughts about a rule based system for making ECN exceptions on outgoing connections?
/sbin/iptables -t mangle -A POSTROUTING -p tcp -d example.com -j ECN --ecn-tcp-remove
I forget the exact version of iptables in which the ECN target first appears, but it's supported on RHL9 and RHEL3 as well. (RHL80 doesn't have it.)