Bug 155964

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
kernel-2.6.11-1.14_FC3.

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.