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] [day] [month] [year] [list]

Message-ID: <CADVnQym=zutyx=WDtaTnGQ=chKNcf553P5sry+FXDoyQQRykww@mail.gmail.com>
Date:	Tue, 5 Aug 2014 11:43:01 -0400
From:	Neal Cardwell <ncardwell@...gle.com>
To:	Alexander.Steffen@...ineon.com
Cc:	Netdev <netdev@...r.kernel.org>,
	Stephen Hemminger <stephen@...workplumber.org>,
	Yuchung Cheng <ycheng@...gle.com>
Subject: Re: Fw: [Bug 81661] New: Network Performance Regression for large TCP
 transfers starting with v3.10

On Tue, Aug 5, 2014 at 10:52 AM,  <Alexander.Steffen@...ineon.com> wrote:
>> 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.

Great. Thanks!

>> 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?

OK, great. Yes, that's what I meant, but I didn't realize that those
two traces were
of the same event. In that case, it definitely seems like the problem
is that some
middlebox rewrote the receiver's SACK values, invalidating them, so the sender
was unable to recover except via a retransmission timeout to repair each hole.

neal
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html