On Fri, 2005-01-28 at 23:37:37 +0100, Daniel Hartmeier proclaimed... > Look closely at the TCP flags part of those two packets, they are not > identical. > > The first one has SWE set, that means it's SYN with the ECN bits ECE and > CWR set. You must have enabled ECN on the client, check > > # sysctl net.inet.tcp.ecn > > When ECN is enabled, a host will try to negotiate ECN for outgoing TCP > connections. That is, it sets the flags SWE in the initial SYN. If the > reply is a RST, it doesn't know for sure whether the peer is not > accepting connections on the port at all or whether it just doesn't > understand ECN and sent the RST because of the WE flags. Hence, the host > will automatically try again without the ECN bits. Because of this > automatic retry you get a delayed 'connection refused' error only after > the second RST is received. This is a normal effect of ECN support.
D'oh! Yep, I've been using it for some testing but didn't think much of it (though the SWE caught my eye as something I haven't seen before). > The external client seems to have ECN support not enabled in the first > place, so it begins with a plain SYN and aborts on the first RST. > > That should explain it entirely, unless sysctl doesn't agree with the > theory :) Everything agrees, many thanks! - Eric
