netdev - RE: Fw: [Bug 81661] New: Network Performance Regression for large TCP transfers starting with v3.10

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: <E23079EBE6B5834E93E29FB5CC9C14930FD8DC0D@MUCSE502.eu.infineon.com>
Date:	Tue, 5 Aug 2014 14:52:58 +0000
From:	<Alexander.Steffen@...ineon.com>
To:	<ncardwell@...gle.com>
CC:	<netdev@...r.kernel.org>, <stephen@...workplumber.org>,
	<ycheng@...gle.com>
Subject: RE: Fw: [Bug 81661] New: Network Performance Regression for large
 TCP transfers starting with v3.10

> The  capture-bad-site1 trace seems to be a sender-side trace that
> shows SACK blocks with sequence numbers that are 613M bytes ahead of
> what has actually been sent, suggesting perhaps a middlebox is
> rewriting sequence numbers, but not SACK options, or vice versa.

It seems plausible that the network equipment somewhere tampers with the data passing through. I've asked our network experts to check the configuration again, specifically with regard to this suggestion.

> Would you be able to reproduce the capture-bad-site2 case but take a
> sender-side tcpdump trace?

capture-bad-site1 and capture-bad-site2 are already traces for the same events, taken simultaneously at the sending (site1) and the receiving (site2) end. Or is this not what you meant?

Thanks for your help
Alexander