From owner-freebsd-net@freebsd.org Mon Mar 7 14:32:34 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 670A7AC0A36 for ; Mon, 7 Mar 2016 14:32:34 +0000 (UTC) (envelope-from hoomanfazaeli@gmail.com) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E9CB4970 for ; Mon, 7 Mar 2016 14:32:33 +0000 (UTC) (envelope-from hoomanfazaeli@gmail.com) Received: by mail-wm0-x236.google.com with SMTP id n186so88723545wmn.1 for ; Mon, 07 Mar 2016 06:32:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to; bh=tE7Y4HgQ2cEwPS09znQ+gY4gZ6H9teGhyb5R5QHUCdM=; b=ClfpRsCTRScy2lJ02X43d58Sc52h2BAK/Kg8H1NhbMq750/r4L0yCpIMI5CvVWLwPv cDPS04MrFla4rGH5jhIT00nI3e943FGf4i8bHzDgscLmi/5bHk1gDzTCCtz1SSzeBf90 hZTsD9YQqTd9OWUNAO7wiWd8qvsQj9pu2yMXX61kkGDGh4oBQ23QZH/tCnOjsU79k6l2 lEdws2itAic0z7R/eBLLP5Q+ugTEEqPP1vDpUexbcC3b4RtJi3PxZrm9cXBoTqeo4Yqe jxp4Xj5Rzu4Lbw3QpGIt1hldqfF8dIT0cOij36RZgv+bHrZj6xzEvLSKM/txfGbvLCea 30PQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to; bh=tE7Y4HgQ2cEwPS09znQ+gY4gZ6H9teGhyb5R5QHUCdM=; b=jqSCnn3BX6mZNiFiulRxRQW2Zoxz2eciVKZRykmDe20oHyWe4JqYc61GP+lAKTYNBN 2CPU8f9aA10mjJafCsiUUNLlOxGvrvyumgmqNjJEF12OKGzUF/TnIOSkNUzk5ctrtjuQ xzE3y+XDUmZLD5dS1n/QcTolOvYEGiWptDuM+AZiRDslCGlEIOKz0Y9nv+NG1n7UYxyD KbIxb+hePFC/T62xqlXXTleXTIafx2HUTHO0xQxeurUotkzNSnlhruyi0Uhj0wspzZJU lf8UghkMToCNZZuKCQm6LE0rebqAbZcs9/y4ncONJg9Rzy2VW2VjDPvGw9NcDbXZ/Fun FQag== X-Gm-Message-State: AD7BkJLrg89mN0UpLp4gAXaQrXclW/2Q3Vbcp4bharZkHCBG3CMbPbXNr43w+WbPJVWNTw== X-Received: by 10.194.83.101 with SMTP id p5mr23121672wjy.141.1457361152127; Mon, 07 Mar 2016 06:32:32 -0800 (PST) Received: from [192.168.2.30] ([2.176.177.244]) by smtp.googlemail.com with ESMTPSA id hx10sm18215036wjb.25.2016.03.07.06.32.29 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 07 Mar 2016 06:32:31 -0800 (PST) Message-ID: <56DD90F8.60205@gmail.com> Date: Mon, 07 Mar 2016 18:02:24 +0330 From: Hooman Fazaeli User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: "freebsd-net@freebsd.org" Subject: Re: tcp window scaling + syn cookies problem References: <56DD7A6A.3070108@gmail.com> In-Reply-To: <56DD7A6A.3070108@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 14:32:34 -0000 On 2016-03-07 4:26 PM, Hooman Fazaeli wrote: > > Hi, > > In our network, Windows clients connect to internet via our custom developed transparent > tcp proxy (running on 7.3). Things work fine, except that _sometimes_ downloads from the > some windows clients become very slow. To debug the problem, we inspected a few packet traces and > found out that the problem happens because the proxy TCP stack forgets about client's window > scale factor, as illustrated in the following packet trace (it is for a download from > ftp.freebsd.org site. x.y.z.y is a windows 8): > > 1. 15:09:32.765713 IP (tos 0x0, ttl 63, id 16510, offset 0, flags [DF], proto TCP (6), length 52) > x.y.z.y.57430 > 96.47.72.72.80: S, cksum 0x8343 (correct), 1530161492:1530161492(0) win 8192 > > 2. 15:09:32.765729 IP (tos 0x0, ttl 64, id 55869, offset 0, flags [none], proto TCP (6), length 52) > 96.47.72.72.80 > x.y.z.y.57430: S, cksum 0xe2c0 (correct), 503882603:503882603(0) ack 1530161493 win 65535 > > 3. 15:09:32.766071 IP (tos 0x0, ttl 63, id 16511, offset 0, flags [DF], proto TCP (6), length 40) > x.y.z.y.57430 > 96.47.72.72.80: ., cksum 0x2192 (correct), ack 1 win 256 > > 4. 15:09:32.770074 IP (tos 0x0, ttl 63, id 16512, offset 0, flags [DF], proto TCP (6), length 408) > x.y.z.y.57430 > 96.47.72.72.80: P, cksum 0x259c (correct), 1:369(368) ack 1 win 256 > > 5. 15:09:32.869286 IP (tos 0x0, ttl 64, id 57834, offset 0, flags [none], proto TCP (6), length 40) > 96.47.72.72.80 > x.y.z.y.57430: ., cksum 0x2122 (correct), ack 369 win 65535 > > 6. 15:09:33.180983 IP (tos 0x0, ttl 64, id 64495, offset 0, flags [none], proto TCP (6), length 296) > 96.47.72.72.80 > x.y.z.y.57430: ., cksum 0xbd5a (correct), 1:257(256) ack 369 win 65535 > > 7. 15:09:33.231475 IP (tos 0x0, ttl 63, id 16513, offset 0, flags [DF], proto TCP (6), length 40) > x.y.z.y.57430 > 96.47.72.72.80: ., cksum 0x1f23 (correct), ack 257 win 255 > > 8. 15:09:33.231494 IP (tos 0x0, ttl 64, id 248, offset 0, flags [none], proto TCP (6), length 295) > 96.47.72.72.80 > x.y.z.y.57430: ., cksum 0xc9b6 (correct), 257:512(255) ack 369 win 65535 > > 9. 15:09:33.282256 IP (tos 0x0, ttl 63, id 16514, offset 0, flags [DF], proto TCP (6), length 40) > x.y.z.y.57430 > 96.47.72.72.80: ., cksum 0x1e25 (correct), ack 512 win 254 > > 10. 15:09:33.282279 IP (tos 0x0, ttl 64, id 1283, offset 0, flags [none], proto TCP (6), length 294) > 96.47.72.72.80 > x.y.z.y.57430: ., cksum 0x1e25 (correct), 512:766(254) ack 369 win 65535 > > 11. 15:09:33.333006 IP (tos 0x0, ttl 63, id 16515, offset 0, flags [DF], proto TCP (6), length 40) > x.y.z.y.57430 > 96.47.72.72.80: ., cksum 0x1d28 (correct), ack 766 win 253 > > 12. 15:09:33.333023 IP (tos 0x0, ttl 64, id 2520, offset 0, flags [none], proto TCP (6), length 293) > 96.47.72.72.80 > x.y.z.y.57430: ., cksum 0x1d28 (correct), 766:1019(253) ack 369 win 65535 > > 13. 15:09:33.383926 IP (tos 0x0, ttl 63, id 16516, offset 0, flags [DF], proto TCP (6), length 40) > x.y.z.y.57430 > 96.47.72.72.80: ., cksum 0x1c2c (correct), ack 1019 win 252 > > As can be seen, the client advertises a window scale factor of 8 and then correctly > sets packet's window size based on the advertised factor. But the proxy > seems to forget about client's scale factor and sends as much data as the > client's unscaled window size sent in a previous ACK. > > Now, setting 'net.inet.tcp.syncookies' to zero obviously seems to fix the problem > and the download speed becomes as expected. > > Is this bad interaction between window scaling and syn cookies > a known problem? Why it happens? Has it been fixed in later freebsd version? > > Thanks in advance. > A few minutes after posting, I found the following thread which describes an exact duplicate of our problem : https://lists.freebsd.org/pipermail/freebsd-net/2013-February/034519.html -- Best regards Hooman Fazaeli