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 - k...@vsen.dk - http://blog.klavsen.info - Tlf.
61281200
"Those who do not understand Unix are condemned to reinvent it, poorly."
--Henry Spencer
