Hello, On Wed, Jul 26, 2017 at 7:32 AM, Eric Dumazet <eric.duma...@gmail.com> wrote: > On Wed, 2017-07-26 at 15:42 +0200, Willy Tarreau wrote: >> On Wed, Jul 26, 2017 at 06:31:21AM -0700, Eric Dumazet wrote: >> > On Wed, 2017-07-26 at 14:18 +0200, Klavs Klavsen wrote: >> > > the 192.168.32.44 is a Centos 7 box. >> > >> > Could you grab a capture on this box, to see if the bogus packets are >> > sent by it, or later mangled by a middle box ? >> >> Given the huge difference between the window and the ranges of the >> values in the SACK field, I'm pretty sure there's a firewall doing >> some sequence numbers randomization in the middle, not aware of SACK >> and not converting these ones. I've had to disable such broken >> features more than once in field after similar observations! Probably >> that the Mac doesn't advertise SACK support and doesn't experience the >> problem. > > We need to check RFC if such invalid SACK blocks should be ignored (DUP > ACK would be processed and trigger fast retransmit anyway), or strongly > validated (as I suspect we currently do), leading to a total freeze.
quite some time ago this issue with sequence number randomizing middleboxes came already up (http://marc.info/?l=netfilter-devel&m=137691623129822&w=2). From what I remember, the RFC does not say that invalid SACK blocks should be strongly validated. So, trigger dup-ack retransmission seems fine. I had some patches at the time that ignored invalid sack-blocks and allowed fast-retransmit to happen thanks to the duplicate acks: https://patchwork.ozlabs.org/patch/268297/ https://patchwork.ozlabs.org/patch/268298/ Cheers, Christoph
