From owner-freebsd-net@FreeBSD.ORG Tue Mar 11 17:58:49 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4E6E5440 for ; Tue, 11 Mar 2014 17:58:49 +0000 (UTC) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 19546663 for ; Tue, 11 Mar 2014 17:58:49 +0000 (UTC) Received: by mail-ob0-f177.google.com with SMTP id wo20so8513586obc.22 for ; Tue, 11 Mar 2014 10:58:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=4ilOenvPPQA83erPFjWqB4xZBvvlaBt642FBa8Fm/tI=; b=hOlr9FX5ojJM/tuWfupjFbdXwomnL4PiGpiXtfAysImUecvcNpTBJvTnobQZwdi6yf aqGG20yr1KEG8W73C6jd3C+N6pCD2FR2gVJ8atuq1jtvXGO8mdY7SvONMMIHaqZRaxh6 oJFPnE4ne1pwpsPRZuGdyru12XXZXN/ZtCyYN89+mggxRIU0KzEr0oaDyhGZP47syv8q uD9Jp0hMKUBbblwZaiKZnldrazodZqSA9P6zgjZeKnbDwxdW9HeJrA2EdXsGVt2Ex0aU PFVzwOE3b2m3egpdGFD/SD8Tsox/QA/z+psNQzMX5UrC6+BpDrVAVUNii2dgOWd+SWyV sBzA== MIME-Version: 1.0 X-Received: by 10.60.39.129 with SMTP id p1mr2844661oek.54.1394560728413; Tue, 11 Mar 2014 10:58:48 -0700 (PDT) Received: by 10.182.74.4 with HTTP; Tue, 11 Mar 2014 10:58:48 -0700 (PDT) Date: Tue, 11 Mar 2014 10:58:48 -0700 Message-ID: Subject: socket receive buffer size & window updates From: Vijay Singh To: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 11 Mar 2014 17:58:49 -0000 The socket option handler currently doesn't prevent connecting or connected sockets from changing their receive buffer sizes. In particular, I ran into a an application that sets the receive buffer size lower than what it originally was. In tcp_output(), if no data is being sent, there is code that is trying to decide if a window update is needed. If the socket receive buffer size was reduced after a larger window was already advertized, or perhaps even when there is data in the receive buffer, it seems to me that the computation in 592 could go -ve, and be interpreted as a large window update. I was led to this issue after observing in packet traces that duplicate FINs were being sent on close. I tracked it down to this check. Should this be changed to a check like such? if (adv >= oldwin) adv -= oldwin; else adv = 0; 586 long adv ; 587 int oldwin; 588 589 adv = min (recwin, (long)TCP_MAXWIN << tp ->rcv_scale); 590 if (SEQ_GT (tp ->rcv_adv, tp ->rcv_nxt )) { 591 oldwin = (tp ->rcv_adv - tp ->rcv_nxt ); 592 adv -= oldwin; 593 } else 594 oldwin = 0; -vijay