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
| ||
|
Message-ID: <alpine.LNX.2.00.1005161204380.3517@pentagram.it.hurts.ca> Date: Sun, 16 May 2010 12:08:16 -0400 (EDT) From: Michael Smith <michael@...ts.ca> To: Ilpo Järvinen <ilpo.jarvinen@...sinki.fi> cc: Netdev <netdev@...r.kernel.org> Subject: Re: Weird TCP retransmit behaviour in recent kernels On Sun, 16 May 2010, Ilpo Järvinen wrote: > On Fri, 14 May 2010, Michael Smith wrote: >> It seems like when consecutive packets are lost, the SLES11 >> server retransmits the first packet when the timeout fires. The client >> ACKs, but the server doesn't retransmit the next lost packet; instead, >> it sends a couple more new packets, which don't get ACKed. > This is where your problem is, they should get acked in a _compliant_ > network (with duplicate ACKs). > Some have seen similar phenomena, every time it has been fault in some > middlebox/peer that does not do what it should. You can disable frto > using tcp_frto sysctl if you like, however, I disagree with you as I'm > pretty sure there is some broken middlebox in the network (which is trying > to be too intelligent). Thanks - tcp_frto=0 works around the problem here. The network in the middle is provided by a number of other parties, so I can try to point them in the right direction, but unless Microsoft turns on FRTO by default sometime soon, I doubt they will have time to care. :) Mike
Powered by blists - more mailing lists