On Wed, Jul 26, 2017 at 07:32:12AM -0700, Eric Dumazet 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.
RFC2883 #4.3 talks about interaction with PAWS and only suggests that since the sequence numbers can wrap the sender should be aware that a reported segment can in fact relate to a value within the prior seq number space before cycling, but that they don't expect any side effect. So that more or less means to me "you should consider that some of these segments might be old, meaningless and should be ignored". But as you can see the recommendation lacks a bit of strength given that no issue was expected in such a situation. Willy
