Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 155964 - e1000 NICs break ECN
Summary: e1000 NICs break ECN
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 3
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: David Miller
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2005-04-26 08:57 UTC by James Ralston
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-04-26 22:57:54 UTC

Attachments (Terms of Use)

Description James Ralston 2005-04-26 08:57:54 UTC
Description of problem:

While debugging an unrelated problem today, I noticed that one of my machines
was not negotiating ECN TCP connections.  That is, for an outgoing connection,
the initial TCP SYN packet didn't have the ECN/CWR bits set.  For an incoming
SYN/ECN/CWR packet, the reply packet was SYN/ACK instead of SYN/ACK/ECN.  This
was despite the fact that /proc/sys/net/ipv4/tcp_ecn was "1".

Another machine running the same kernel, with exactly the same RPMs installed,
and exactly the same /etc/sysctl.conf file, correctly attempted to negotiate ECN
TCP connections.  Another machine also running FC3 and the same kernel (but with
only a minimal set of RPMs) also worked correctly.

After much testing, the common thread seems to be this: the kernel fails to use
ECN if the TCP connection being initiated is sent/received on an "Intel Corp.
82540EM Gigabit Ethernet Controller (rev 02)" NIC using the e1000 driver.

(The "smoking gun" was being able to test a machine with two Ethernet interfaces
(eth0 = epic100; eth1 = e1000).  ECN on eth0 worked as expected but didn't work
on eth1.)

Version-Release number of selected component (if applicable):

I'm encountering these ECN problems under both kernel-2.6.10-1.770_FC3 and

How reproducible:

Take a FC3 machine that contains an "Intel Corp. 82540EM Gigabit Ethernet
Controller (rev 02)" NIC.  Make sure that /proc/sys/net/ipv4/tcp_ecn is "1". 
Either initiate a new outbound TCP connection, or initiate a new inbound TCP
connection from an ECN-enabled hosts.
Actual results:

The kernel will not attempt to negotiate ECN.

Expected results:

The kernel should attempt to negotiate ECN.

Additional info:

I ruled out the possibility that any of my iptables rules was using the ECN
--ecn-tcp-remove target to strip the ECN bits.

Comment 1 David Miller 2005-04-26 22:57:54 UTC
No ethernet chip supporting TSO (TCP Segmentation Offload) supports
ECN.  If you want ECN back, disable TSO on the device by executing
the command:

bash# ethtool -K eth0 tso off

See the ethtool man page for more details.

Comment 2 James Ralston 2005-04-29 21:03:05 UTC
Ok, understood; thanks.

Has the kernel only recently started supporting TSO?  Or has TSO support been
present for a while, but I just didn't notice it?

Is there any good reason why NIC manufacturers couldn't support ECN in TSO, or
have they simply not bothered?

Comment 3 David Miller 2005-04-29 21:11:43 UTC
TSO is present in all 2.6.x kernels.

ECN isn't supported properly because the TSO driver interface the
hw guys are building against is specified against Microsoft and it
doesn't consider ECN bits at all.

Comment 4 James Ralston 2005-04-29 23:27:41 UTC
That's unfortunate, but given that Microsoft doesn't seem to care about ECN at
all (in either software or hardware), it makes sense.  Thanks for the info.

Note You need to log in before you can comment on or make changes to this bug.