netdev - Re: TCP fast retransmit issues

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]

Date:   Wed, 26 Jul 2017 16:25:29 +0200
From:   Klavs Klavsen <kl@...n.dk>
To:     Willy Tarreau <w@....eu>
Cc:     Eric Dumazet <eric.dumazet@...il.com>, netdev@...r.kernel.org
Subject: Re: TCP fast retransmit issues

Thank you very much guys for your insight.. its highly appreciated.

Next up for me, is waiting till the network guys come back from summer 
vacation, and convince them to sniff on the devices in between to 
pinpoint the culprit :)

Willy Tarreau skrev den 2017-07-26 16:18:
> On Wed, Jul 26, 2017 at 04:08:19PM +0200, Klavs Klavsen wrote:
>> Grabbed on both ends.
>> 
>> http://blog.klavsen.info/fast-retransmit-problem-junos-linux (updated 
>> to new
>> dump - from client scp'ing)
>> http://blog.klavsen.info/fast-retransmit-problem-junos-linux-receiving-side
>> (receiving host)
> 
> So bingo, Eric guessed right, the client's sequence numbers are 
> translated
> on their way to/from the server, but the SACK fields are not :
> 
> Server :
> 15:59:54.292867 IP (tos 0x8, ttl 64, id 15878, offset 0, flags [DF],
> proto TCP (6), length 64)
>     192.168.32.44.22 > 62.242.222.50.35002: Flags [.], cksum 0xfe2b
> (incorrect -> 0xce0e), seq 1568063538, ack 3903858556,
>     win 10965, options [nop,nop,TS val 529899820 ecr
> 774272020,nop,nop,sack 1 {3903859904:3903861252}], length 0
> 
> Client :
> 15:59:54.297388 IP (tos 0x8, ttl 56, id 15878, offset 0, flags [DF],
> proto TCP (6), length 64)
>     192.168.32.44.22 > 62.242.222.50.35002: Flags [.], cksum 0xbb2c
> (correct), seq 1568063538, ack 2684453645,
>     win 10965, options [nop,nop,TS val 529899820 ecr
> 774272020,nop,nop,sack 1 {3903859904:3903861252}], length 0
> 
> To there's very likely a broken firewall in the middle that is waiting 
> for
> a bug fix, or to have its feature disabled. Sometimes it can also 
> happen
> on firewalls performing some SYN proxying except that it would mangle 
> the
> server's sequence numbers instead of the client ones.
> 
> Willy

-- 
Regards,
Klavs Klavsen, GSEC - kl@...n.dk - http://blog.klavsen.info - Tlf. 
61281200

"Those who do not understand Unix are condemned to reinvent it, poorly."
   --Henry Spencer