Re: kernel 2.4.18 -> 2.4.20 subtle upgrade problem
Graeme Tank wrote:
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
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.
:-) I understand the eagerness . . . .
I set mine to 'Y' so I would have the option of actually figuring-out exactly
what this function is (still waiting for enlightenment).
If I have a held "Connecting . . .", which I rarely do, I echo "0" > to see
Enjoy your new kernel!