Is there a list of sites that require ECN to be disabled?

Today I solved a problem wherein a website refused to respond. It
turned out to be a problem with ECN (Explicit Congestion
Notification). When I disabled ECN for that site, it immediately
started working.

Now we seek a list of sites that are known to require ECN to be
disabled, but Google is not providing any help. Does anyone know if
such a list exists and is kept current?

If there is no list, then there will be because I intend to create
one. Since I have no experience with web pages that a user can alter,
any guidance you can provide with respect to how this should be set up
will be sincerely appreciated. In particular, a user should be able
to indicate that a site now works that previously didn't, but (s)he
shouldn't be able to remove the site from the list. Additions to the
list need to be possible, into an area "untested", until it is
confirmed that ECN is indeed the culprit.

ECN is not (or at least is not enabled) in the standard Linux 2.4
kernel. It was added and turned on here, partly because problems
associated with ECN seem to have become very rare. (Either that or
very few _use_ ECN?) We would rather use an exception list than to
turn off ECN, but the absence of a "Bad Boy" list may force disabling
it, at least for a while.

This iptables line excepts the Bad Boy site. (Watch out for line
wrap. This is all one line.):
iptables -t mangle -A POSTROUTING -p tcp -d 12.5.136.100 -j ECN
--ecn-tcp-remove

63.169.44.100 is also ECN impaired.
--
buck

On Wed, 14 Mar 2007, in the Usenet newsgroup comp.os.linux.networking, in
article <(E-Mail Removed)>, buck wrote:

>Today I solved a problem wherein a website refused to respond. It
>turned out to be a problem with ECN (Explicit Congestion
>Notification). When I disabled ECN for that site, it immediately
>started working.

Someone with an old router running an old version of the O/S.

>Now we seek a list of sites that are known to require ECN to be
>disabled, but Google is not providing any help. Does anyone know if
>such a list exists and is kept current?

I don't know of any - the problem _should_ have gone away several years
ago. For example:

------------------------------
Bug ID: CSCds23698
Headline: PIX sends RSET in response to tcp connections with ECN bits
set
Product: PIX
Component: fw
Severity: 2 Status: R [Resolved]
Version Found: 5.1(1) Fixed-in Version: 5.1(2.206) 5.1(2.207)
5.2(1.200)
------------------------------

That was back in October 2000.

>ECN is not (or at least is not enabled) in the standard Linux 2.4
>kernel. It was added and turned on here, partly because problems
>associated with ECN seem to have become very rare. (Either that or
>very few _use_ ECN?)

You're pushing memory, but that feature was added in 2.4.0 back in...
well, 2.4.0 is dated Jan 4, 2001 but the problem was seen in the
summer of 2000. I see packets with ECN enabled constantly, so I suspect
you're seeing a rarity.

Old guy

On Thu, 15 Mar 2007 15:00:45 -0500, (E-Mail Removed)
(Moe Trin) wrote:

>On Wed, 14 Mar 2007, in the Usenet newsgroup comp.os.linux.networking, in
>article <(E-Mail Removed)>, buck wrote:
>
>>Today I solved a problem wherein a website refused to respond. It
>>turned out to be a problem with ECN (Explicit Congestion
>>Notification). When I disabled ECN for that site, it immediately
>>started working.
>
>Someone with an old router running an old version of the O/S.
>
>>Now we seek a list of sites that are known to require ECN to be
>>disabled, but Google is not providing any help. Does anyone know if
>>such a list exists and is kept current?
>
>I don't know of any - the problem _should_ have gone away several years
>ago. For example:
>
>------------------------------
>Bug ID: CSCds23698
>Headline: PIX sends RSET in response to tcp connections with ECN bits
>set
>Product: PIX
>Component: fw
>Severity: 2 Status: R [Resolved]
>Version Found: 5.1(1) Fixed-in Version: 5.1(2.206) 5.1(2.207)
>5.2(1.200)
>------------------------------
>
>That was back in October 2000.
>
>>ECN is not (or at least is not enabled) in the standard Linux 2.4
>>kernel. It was added and turned on here, partly because problems
>>associated with ECN seem to have become very rare. (Either that or
>>very few _use_ ECN?)
>
>You're pushing memory, but that feature was added in 2.4.0 back in...
>well, 2.4.0 is dated Jan 4, 2001 but the problem was seen in the
>summer of 2000. I see packets with ECN enabled constantly, so I suspect
>you're seeing a rarity.
>
> Old guy

Stuff I find on the web says that 2.4.20 had a bug that was fixed in
2.4.21 kernel versions - having to do with endianess (if I understand
correctly). We are comfortable that our kernel and iptables are OK.

Although this list has not been updated in almost a year, I did find
this "ECN Hall of Shame", and it does contain the Bad Boy I created an
exception for:
http://urchin.earth.li/cgi-bin/ecn.pl

which, after testing, is going to go up on our website because it does
not appear that urchin.earth.li will resume updates.

If anyone knows of a list that IS current, please let us know about
it!
--buck

On Thu, 15 Mar 2007, in the Usenet newsgroup comp.os.linux.networking, in
article <(E-Mail Removed)>, buck wrote:

>(Moe Trin) wrote:

>> buck wrote:

>>> When I disabled ECN for that site, it immediately started working.
>>
>>Someone with an old router running an old version of the O/S.

>>>ECN is not (or at least is not enabled) in the standard Linux 2.4
>>>kernel. It was added and turned on here, partly because problems
>>>associated with ECN seem to have become very rare. (Either that or
>>>very few _use_ ECN?)
>>
>>You're pushing memory, but that feature was added in 2.4.0 back in...
>>well, 2.4.0 is dated Jan 4, 2001 but the problem was seen in the
>>summer of 2000. I see packets with ECN enabled constantly, so I suspect
>>you're seeing a rarity.

>Stuff I find on the web says that 2.4.20 had a bug that was fixed in
>2.4.21 kernel versions - having to do with endianess (if I understand
>correctly). We are comfortable that our kernel and iptables are OK.

The ChangeLog-2.4.21 file isn't all that informative:

-rw-rw-r-- 1 536 536 97324 Jun 13 2003 ChangeLog-2.4.21

but I don't think the problem is on your end. The Cisco change notice
is talking about a problem that many systems had in 2000, relating to
the change to the ECN which wasn't formally adopted until RFC3168 in
September 2001. Router software before the adaptation would barf over
the unknown flags (it had originally been an experimental service from
RFC2481 in January 1999). Hey, it's only been five and a half years,
and you can't expect every router on the Internet to be updated this
quick, can you? ;-)

>Although this list has not been updated in almost a year, I did find
>this "ECN Hall of Shame", and it does contain the Bad Boy I created an
>exception for:
>http://urchin.earth.li/cgi-bin/ecn.pl

I've grabbed a copy at ~02:30 UTC on the 16th (today), and that has a
line that reads

Data was last processed: 2005-02-13, 13:19 GMT

and none of the dates in the file seem later than that.

Old guy

On Fri, 16 Mar 2007 10:05:39 -0500, (E-Mail Removed)
(Moe Trin) wrote:

>On Thu, 15 Mar 2007, in the Usenet newsgroup comp.os.linux.networking, in
>article <(E-Mail Removed)>, buck wrote:

big snip

>>http://urchin.earth.li/cgi-bin/ecn.pl
>
>I've grabbed a copy at ~02:30 UTC on the 16th (today), and that has a
>line that reads
>
> Data was last processed: 2005-02-13, 13:19 GMT
>
>and none of the dates in the file seem later than that.
>
> Old guy

Would you mind checking out
http://www.ride-to-arrive.org/

from the urchin list? Even after I put it into my exceptions, it
fails for me but it works from a non Linux (SonicWALL) router, so if
it also works for you I have a bit more troubleshooting to do...

Thanks!
--
buck

On Fri, 16 Mar 2007 15:09:49 -0700, buck <(E-Mail Removed)> wrote:
>
>Would you mind checking out
>http://www.ride-to-arrive.org/
>
>from the urchin list? Even after I put it into my exceptions, it
>fails for me but it works from a non Linux (SonicWALL) router, so if
>it also works for you I have a bit more troubleshooting to do...
>
>Thanks!

Never mind. I screwed up. It works when excepted correctly - meaning
that the IP excepted was old. Excepting the current IP
(195.11.203.196) causes the page to come up.

Sorry for any inconvenience.
--
buck