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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 4 Aug 2014 13:08:51 -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: Fwd: Fw: [Bug 81661] New: Network Performance Regression for large TCP transfers starting with v3.10 On Mon, Aug 4, 2014 at 12:05 PM, Stephen Hemminger <stephen@...workplumber.org> wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=81661 > > Bug ID: 81661 > Summary: Network Performance Regression for large TCP transfers > starting with v3.10 [sorry for re-send; fixing typo in e-mail address...] Hi Alexander, Thanks for the detailed report! We think we have a sense of what might be happening, but the traces are a little hard to interpret. 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. The capture-bad-site2 trace seems well-formed, but seems to be taken on the receiver side, which makes it difficult to interpret exactly what is going wrong on the sending side. Would you be able to reproduce the capture-bad-site2 case but take a sender-side tcpdump trace? Thanks! 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
Powered by blists - more mailing lists