netdev - Re: TCP being hoodwinked into spurious retransmissions by lack of timestamps?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CABrhC0k5-x=qJgH4izXtRR=9+cLJh_emAy9Yt=+xrY6K5982Fg@mail.gmail.com>
Date:	Tue, 4 Mar 2014 14:14:44 -0500
From:	John Heffner <johnwheffner@...il.com>
To:	Rick Jones <rick.jones2@...com>
Cc:	Netdev <netdev@...r.kernel.org>
Subject: Re: TCP being hoodwinked into spurious retransmissions by lack of timestamps?

On Tue, Mar 4, 2014 at 1:50 PM, Rick Jones <rick.jones2@...com> wrote:
> On 03/03/2014 07:22 PM, John Heffner wrote:
>> If you look where things really go wrong, the receiver is sending
>> anomalous SACK blocks that will trigger the SACK renege handling path.
>>   Reneging triggers go-back-n behavior, so we see the spurious
>> retransmits from there on.
>
>
> Should those subsequent ACKs be clocking-out additional retransmissions like
> they appear to do? (Assuming I'm not projecting into the trace) Or is that
> an unavoidable consequence of there being no timestamps with which to tell
> which send was being ACKed?

It's possible that if they had timestamps, the ACKs for for original
transmits might not open up the window, thus preventing the
retransmits from going out.  But I'm not nearly familiar enough with
the details of the current retransmit machinery to know for sure.
Reneging like this (go-back-n before a timeout) is not a
commonly-exercised case, so I wouldn't be too surprised if the sender
isn't doing the smartest possible thing.


>> The most notable bad segment is this one:
>> 18:20:46.800063 IP 75.236.145.7.443 > 91.216.86.7.56064: Flags [.],
>> ack 3171368, win 32716, options [nop,nop,sack 1 {3171368:3177208}],
>> length 0
>> It contains a SACK block contiguous with the acked seqno.
>
>
> I've gone back through one of the other traces and found the same thing
> therein.
>
>
>> There is some other strangeness just before that, where the SACK
>> block shrinks then grows again.
>
>
> That would be this yes?
>
> 15:20:46.798816 IP 91.216.86.7.56064 > 75.236.145.7.443: Flags [.], seq
> 3660468:3661928, ack 4262, win 297, length 1460
> 15:20:46.799027 IP 75.236.145.7.443 > 91.216.86.7.56064: Flags [.], ack
> 3168256, win 32081, options [nop,nop,sack 1 {3171368:3172828}], length 0
> 15:20:46.799042 IP 91.216.86.7.56064 > 75.236.145.7.443: Flags [.], seq
> 3661928:3664848, ack 4262, win 297, length 2920
> 15:20:46.799465 IP 75.236.145.7.443 > 91.216.86.7.56064: Flags [.], ack
> 3169716, win 32241, options [nop,nop,sack 1 {3171368:3172828}], length 0
> 15:20:46.799479 IP 91.216.86.7.56064 > 75.236.145.7.443: Flags [.], seq
> 3664848:3666308, ack 4262, win 297, length 1460
> 15:20:46.799497 IP 75.236.145.7.443 > 91.216.86.7.56064: Flags [.], ack
> 3169716, win 32241, options [nop,nop,sack 1 {3171368:3174288}], length 0
> 15:20:46.799504 IP 75.236.145.7.443 > 91.216.86.7.56064: Flags [.], ack
> 3169716, win 32241, options [nop,nop,sack 1 {3171368:3175748}], length 0
> 15:20:46.799509 IP 91.216.86.7.56064 > 75.236.145.7.443: Flags [.], seq
> 3666308:3667768, ack 4262, win 297, length 1460
> 15:20:46.799773 IP 75.236.145.7.443 > 91.216.86.7.56064: Flags [.], ack
> 3171176, win 32491, options [nop,nop,sack 1 {3171368:3172828}], length 0
> 15:20:46.799787 IP 91.216.86.7.56064 > 75.236.145.7.443: Flags [.], seq
> 3667768:3669228, ack 4262, win 297, length 1460
> 15:20:46.800063 IP 75.236.145.7.443 > 91.216.86.7.56064: Flags [.], ack
> 3171368, win 32716, options [nop,nop,sack 1 {3171368:3177208}], length 0
> 15:20:46.800081 IP 91.216.86.7.56064 > 75.236.145.7.443: Flags [.], seq
> 3171368:3172828, ack 4262, win 297, length 1460
>
> Might that be packet-reordering in the other direction?  Sadly, I don't have
> good "both sides" traces as the receiving system doesn't seem to capture
> traffic terribly well.  I suppose TCP timestamps might have helped answer
> that question.

Regardless of any possible reordering, in this case we know something
odd is going on in the receiver because ACK advances at the same time
the SACK block shrinks.

  -John
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html