From owner-freebsd-net@freebsd.org Mon Mar 7 12:56:19 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 3D4E39DBFB8 for ; Mon, 7 Mar 2016 12:56:19 +0000 (UTC) (envelope-from hoomanfazaeli@gmail.com) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 BFCA518E for ; Mon, 7 Mar 2016 12:56:18 +0000 (UTC) (envelope-from hoomanfazaeli@gmail.com) Received: by mail-wm0-x234.google.com with SMTP id l68so69294723wml.1 for ; Mon, 07 Mar 2016 04:56:18 -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; bh=nnSK71ZbaXTIogCPjNViz5Hja4duueo3Y8AZ7ELS8kk=; b=U8t9pyYGcdDw+BbW8aStV10VifxgaYPIzhJUbLEV3pUz9acdItpED5S1ugYORR/Cde Y4BV4kVOtTTHv6CAsB42MP6O/SkVxzAeifU1xLYgCpUPq1VturCKZxdhlWwSyO1YOBBS pdpupGMYTudUu4PsLYBRWQEENTIPXX++x8ZVfLURZt6b6Qai2KpG5KddLmRGIUB4M5RO /THO8XLaW01Rv2V9J/TWpWyXW9QZc8LE0NchM5dyNcgdxX7uFCK2fXq2zsrsgmrfPS5O 3S+36lcqhWhBVLXQylgDjwbc7GeII8uNYKHdzxpTIm29n0n/09YHSDJ4om01mS5JHEo4 bWTQ== 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; bh=nnSK71ZbaXTIogCPjNViz5Hja4duueo3Y8AZ7ELS8kk=; b=O4gLthkcXgU/tVB5+lBEdHT2/mINoS4nNl5qARUMryz6yQpLVWkMjg1Gb2XUtQc3Qs d5nU7ai1O7hjd4pJCSsz1Hh5tIFHaG9Xv1vLgEnSO2ozzxoEa+ryNwobQuNBgX6/s+4i AWGAMHPU4aNLEh1mmBVmYZbCbMLLD1RqWyPFakx2RxYM8FAmdrefEbTFmQMIXiIg2ovU ee+UW6GMYbkMh86Zj/FN+MquY09DdCQSKFyRNA0GG/OkaftrvICcQBwZnr/iyK30Qhq5 kkbUGvJst2JJO1avyYgDmWJv05lvlVfoKdIjsxUMegChlkCuinIqQ2Ust5kuURTaf670 +6dw== X-Gm-Message-State: AD7BkJIyHNQOJq2aHPqVsRYHNIE/Wa4nGfOZlgARo0Bdnkv40SDC60gyFR4Yn8ATGB+u3g== X-Received: by 10.194.76.72 with SMTP id i8mr22561669wjw.117.1457355376429; Mon, 07 Mar 2016 04:56:16 -0800 (PST) Received: from [192.168.2.30] ([2.176.177.244]) by smtp.googlemail.com with ESMTPSA id g3sm17861539wjw.31.2016.03.07.04.56.13 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 07 Mar 2016 04:56:15 -0800 (PST) Message-ID: <56DD7A6A.3070108@gmail.com> Date: Mon, 07 Mar 2016 16:26:10 +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: tcp window scaling + syn cookies problem 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 12:56:19 -0000 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. -- Best regards Hooman Fazaeli