Re: TCP SACK issue, hung connection, tcpdump included

[Willy Tarreau <w@1wt.eu>]

On Sun, Jul 29, 2007 at 11:26:00AM +0300, Ilpo Järvinen wrote:
> On Sun, 29 Jul 2007, Willy Tarreau wrote:
> 
> > On Sun, Jul 29, 2007 at 06:59:26AM +0100, Darryl L. Miles wrote:
> > > CLIENT = Linux 2.6.20.1-smp [Customer build]
> > > SERVER = Linux 2.6.9-55.ELsmp [Red Hat Enterprise Linux AS release 4 
> > > (Nahant Update 5)]
> > > 
> > > The problems start around time index 09:21:39.860302 when the CLIENT issues 
> > > a TCP packet with SACK option set (seemingly for a data segment which has 
> > > already been seen) from that point on the connection hangs.
> 
> ...That's DSACK and it's being correctly sent. To me, it seems unlikely to 
> be the cause for this breakage...
> 
> > Where was the capture taken ? on CLIENT or on SERVER (I suspect client from
> > the timers) ? 
> 
> ...I would guess the same based on SYN timestamps (and from the DSACK 
> timestamps)...
> 
> > A possible, but very unlikely reason would be an MTU limitation
> > somewhere, because the segment which never gets correctly ACKed is also the
> > largest one in this trace.
> 
> Limitation for 48 byte segments? You have to be kidding... :-) But yes,
> it seems that one of the directions is dropping packets for some reason 
> though I would not assume MTU limitation... Or did you mean some other 
> segment?

No, I was talking about the 1448 bytes segments. But in fact I don't
believe it much because the SACKs are always retransmitted just afterwards.

BTW, some information are missing. It would have been better if the trace
had been read with tcpdump -Svv. We would have got seq numbers and ttl.
Also, we do not know if there's a firewall between both sides. Sometimes,
some IDS identify attacks in crypted traffic and kill connections. It
might have been the case here, with the connection closed one way on an
intermediate firewall.

Regards,
Willy