Re: kernel 2.4.18 -> 2.4.20 subtle upgrade problem
On Mon, Apr 14, 2003 at 08:25:30PM -0400, Andy Hurt wrote:
> # Automatically generated make config: don't edit
> >Any help would be appreciated. It might be interesting to see if those
> >of you running the 2.4.20 kernel have a similar problem.
> Aye; I, too, had activated 'Explicit Congestion Notification' in menuconfig.
> Try this as root:
> echo "0" > /proc/sys/net/ipv4/tcp_ecn
> If you can then get to the aforementioned sites after doing so, tcp_ecn the
> culprit ;-\
Thank you for the solution Andy.
Indeed, TCP Explicit Congestion Notification support was the culprit.
As I mentioned previously, my config template was the 2.4.18-bf2.4
$ fgrep INET_ECN /boot/config-2.4.18-bf2.4
$ fgrep INET_ECN /boot/config-2.4.18-gat.05
$ fgrep INET_ECN /boot/config-2.4.20-gat.05
The default is CONFIG_INET_ECN=n for both kernel source packages.
This points to the hazards of blindly copying a config file from a
kernel that currently "works" to your
/path/to/new/kernel-source-x.y.z/.config file. In this case, the
CONFIG_INET_ECN_DISABLED option was dropped in 2.4.20. ECN support was
compiled into both kernels, and in 2.4.18 it was disabled, but in 2.4.20
it was not.
The menuconfig help for TCP Explicit Congestion Notification explains
that it increases network performance by reducing the number of dropped
packets. However, many extant "broken firewalls" block "ECN-enabled
The site to which I could not connect runs Novell BorderManager (version
 If I had actually read the menuconfig help for TCP Explicit
Congestion Notification, perhaps I would have known how to disable it at
runtime or even elected not to compile support for it into the kernel in
the first place.