From owner-freebsd-net@FreeBSD.ORG Tue Apr 3 17:17:15 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F6291065673 for ; Tue, 3 Apr 2012 17:17:15 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id BE24E8FC0A for ; Tue, 3 Apr 2012 17:17:14 +0000 (UTC) Received: (qmail 26906 invoked from network); 3 Apr 2012 17:15:29 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 3 Apr 2012 17:15:29 -0000 Message-ID: <4F7B3098.3090901@freebsd.org> Date: Tue, 03 Apr 2012 19:17:12 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: darrenr@freebsd.org References: <4F75C1A3.4030401@freebsd.org> <4F75D9ED.7080707@freebsd.org> <4F780373.6030107@freebsd.org> <4F7AFEEF.60708@freebsd.org> <4F7B1981.1050009@freebsd.org> In-Reply-To: <4F7B1981.1050009@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD TCP ignores zero window size X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 17:17:15 -0000 On 03.04.2012 17:38, Darren Reed wrote: > On 3/04/2012 11:45 PM, Andre Oppermann wrote: >> It's the other way around. remote.ssh is sending old data >> which freebsd82.62922 has already ack'ed. The sessions seems >> to be de-synchronized, perhaps some middle box mucking with >> the segments trying to modulate something? > > I suspect that the ISP is dropping packets and/or applying > some other means of throttling the connection. So, yes. That doesn't explain it. The other side is retransmitting data we have already received and acknowledged! There is not nothing we can do on our side. That behavior is totally non-compliant. The zero-window is not involved in this as it would affect FreeBSD sending data, not the other end sending data. Can you try to find out what kind of middle-box is mucking TCP here on your side and the other side? It must be some device that actively touches the TCP session transiting through it. A router with active queue management (like WFQ or RED) is not enough to cause this behavior. What is the OS of your remote.ssh? -- Andre