From owner-freebsd-transport@freebsd.org Tue Jan 5 08:05:51 2016 Return-Path: Delivered-To: freebsd-transport@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 A8509A616F9 for ; Tue, 5 Jan 2016 08:05:51 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 8D765135A for ; Tue, 5 Jan 2016 08:05:51 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: by mailman.ysv.freebsd.org (Postfix) id 8A8C1A616F7; Tue, 5 Jan 2016 08:05:51 +0000 (UTC) Delivered-To: transport@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 883A6A616F6; Tue, 5 Jan 2016 08:05:51 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: from mail.strugglingcoder.info (strugglingcoder.info [65.19.130.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.strugglingcoder.info", Issuer "mail.strugglingcoder.info" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7A3131358; Tue, 5 Jan 2016 08:05:51 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPA id 20858C8033; Mon, 4 Jan 2016 23:57:12 -0800 (PST) Date: Mon, 4 Jan 2016 23:57:12 -0800 From: hiren panchasara To: Sam Kumar Cc: transport@freebsd.org Subject: Re: TCP Stack: Challenge ACKs and Timestamps Message-ID: <20160105075712.GA6605@strugglingcoder.info> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="gBBFr7Ir9EOA20Yy" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-transport@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions of transport level network protocols in FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 08:05:51 -0000 --gBBFr7Ir9EOA20Yy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable bcc: current@ Moving the discussion to transport@. On 12/28/15 at 12:25P, Sam Kumar wrote: > Hello, > I am working with the code for the TCP Stack. I noticed that support for > Challenge Acks have been added since the latest release (10.2.0), and I > think I may have found a bug in how they relate to TCP timestamps. All li= ne > numbers below are those in commit e66e064c45687b5d294565dbd829b419848f799= 2. >=20 > Looking at tcp_input.c, at lines 1594 to 1604, I see code that expects a > timestamp to be in every segment during the session, if they were > negotiated when the connection was being established. > ( > https://github.com/freebsd/freebsd/blob/master/sys/netinet/tcp_input.c#L1= 595 > ) >=20 > Looking at tcp_input.c, at lines 2161 and 2188, I see that Challenge ACKs > are sent via calls to tcp_respond(). > ( > https://github.com/freebsd/freebsd/blob/master/sys/netinet/tcp_input.c#L2= 161 > and > https://github.com/freebsd/freebsd/blob/master/sys/netinet/tcp_input.c#L2= 188 > ) >=20 > Looking at tcp_subr.c, at line 978, I see that the segment sent by > tcp_respond() never contains TCP options. > (https://github.com/freebsd/freebsd/blob/master/sys/netinet/tcp_subr.c#L9= 78) >=20 > Therefore, it seems to me that Challenge ACKs will never contain any TCP > options. This violates the condition that once timestamps are negotiated, > they must be present in every segment. >=20 > Please let me know if I am mistaken, or if this is actually a bug. >=20 > Sam Kumar > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" --gBBFr7Ir9EOA20Yy Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJWi3dUXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lmeYH/2cIasO818MSJhrR1pR95t2K MmOtpO+nxCOW2qKPdJSkU2DFeYoJ/2qOne8Qi647IZQRFZox+gxOoIYy9PZn6ZKY 1GyWGUrxhdO8IGgP32RS4TfpI8mo2GFz+yoVs17ntWeEXKKCatVbuHMWlQIn3ZCW tR1lCBY7+bEpI8qPfUySoeBh4hbzmdJEnX9TmiHJlhtvC+NB4JYmL2DpriYPIYsz Duo91qFVnck9PiI5PAU0rzKFBhQJSOboN6AZkd/57ydz3kE6btqAphQ1QRBJvQlF t2MaF6JvRWLBFBhrj8T6xuzD/59ByvMy7GtJANKuWMLNad04xaAs0VUsbMVqYtI= =WYNc -----END PGP SIGNATURE----- --gBBFr7Ir9EOA20Yy-- From owner-freebsd-transport@freebsd.org Tue Jan 5 15:35:04 2016 Return-Path: Delivered-To: freebsd-transport@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 ED40BA63E71 for ; Tue, 5 Jan 2016 15:35:03 +0000 (UTC) (envelope-from jtl@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id A2B791F11 for ; Tue, 5 Jan 2016 15:35:03 +0000 (UTC) (envelope-from jtl@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id A06CEA63E70; Tue, 5 Jan 2016 15:35:03 +0000 (UTC) Delivered-To: transport@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 9FF6BA63E6F for ; Tue, 5 Jan 2016 15:35:03 +0000 (UTC) (envelope-from jtl@freebsd.org) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0145.outbound.protection.outlook.com [207.46.100.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 33A841F10 for ; Tue, 5 Jan 2016 15:35:02 +0000 (UTC) (envelope-from jtl@freebsd.org) Received: from CO2PR05CA012.namprd05.prod.outlook.com (10.141.241.140) by BN3PR0501MB1378.namprd05.prod.outlook.com (10.160.117.12) with Microsoft SMTP Server (TLS) id 15.1.361.13; Tue, 5 Jan 2016 14:01:26 +0000 Received: from BN1BFFO11FD043.protection.gbl (2a01:111:f400:7c10::1:149) by CO2PR05CA012.outlook.office365.com (2a01:111:e400:1429::12) with Microsoft SMTP Server (TLS) id 15.1.361.13 via Frontend Transport; Tue, 5 Jan 2016 14:01:26 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.19) smtp.mailfrom=freebsd.org; gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=freebsd.org; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning freebsd.org discourages use of 66.129.239.19 as permitted sender) Received: from p-emfe01b-sac.jnpr.net (66.129.239.19) by BN1BFFO11FD043.mail.protection.outlook.com (10.58.144.106) with Microsoft SMTP Server (TLS) id 15.1.355.15 via Frontend Transport; Tue, 5 Jan 2016 14:01:25 +0000 Received: from magenta.juniper.net (172.17.27.123) by p-emfe01b-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 5 Jan 2016 06:01:03 -0800 Received: from [172.29.37.27] ([172.29.37.27]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id u05E10D25412; Tue, 5 Jan 2016 06:01:01 -0800 (PST) (envelope-from jtl@freebsd.org) User-Agent: Microsoft-MacOutlook/14.5.9.151119 Date: Tue, 5 Jan 2016 09:00:58 -0500 Subject: Re: TCP Stack: Challenge ACKs and Timestamps From: "Jonathan T. Looney" Sender: Jonathan Looney To: Sam Kumar CC: Message-ID: Thread-Topic: TCP Stack: Challenge ACKs and Timestamps References: <20160105075712.GA6605@strugglingcoder.info> In-Reply-To: <20160105075712.GA6605@strugglingcoder.info> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11FD043; 1:L8u/WQnQZvWYkwZ+5YziI+LTkK1r0n5O9SnEZZbr1KUkS6IZot03JGh+K90ihrv5ZD0wQSBxKFHkWTA/I1NoaQMKOdbkHp/m4FEoM6EAdv/pM7lhFFdiFJXmKFa8aXTJv2XpkYUv4IiNiyuMEG/3k+09KnaXCYLGFpNrdRYYFWP/pAiNodioAi1MsOjnw/pTzlfEQQeWHdfGUquzbg3oNk+K7asrhQv3XJMoGrZGFanZ7AGPu9coK8AWkF6sbKb4tC+UXJv0PB30fiNuVVjTASrBlGGLtXesKnOIwtf0jgyVZCeMcc4F++kMl6aqwo0NVmzxYd+Cd7Qyt9xlrXhPEQ== X-Forefront-Antispam-Report: CIP:66.129.239.19; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(52044002)(479174004)(199003)(52604005)(24454002)(377454003)(189002)(6806005)(50466002)(1411001)(19580405001)(77096005)(15975445007)(50986999)(586003)(230700001)(97736004)(46406003)(81156007)(2950100001)(4001350100001)(54356999)(110136002)(189998001)(92566002)(86362001)(76176999)(106466001)(16796002)(69596002)(105596002)(36756003)(87936001)(1220700001)(1096002)(23726003)(5001960100002)(83506001)(11100500001)(47776003)(4326007)(19580395003)(42262002)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1378; H:p-emfe01b-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1378; 2:B3IEvm/igjSNwwqj9/kByZSfKO06wuvBUG+dxogNhfsbhdgh7PnOv8W2V5cqDs99VlJxzFS09LmQ8uaEu++qF8VMxH59B+GbzR4UgFm0hQWt19Jk1EJ1w1z0KWlMaatJMUNtr9wSVQO6ItF35UQjSg==; 3:SlH6Rs6MLSPydroWyLHvI3prtuc8Ov49MUwXnQxCuYrhkSHX544JuuMPcH7R1P9IjmA7vVKJlPPNFuJdnQDccRUsgtmeQnaCbsUOTjD2yXsuBf6Hw3eGtPtvgkzyC2OT26TPF7hB2LpcwaBGGGM/53wvfpYE5XCHQBeEgU5BX6KYxSbyIdjwWF9IWup7nrSnfKR3l8EHiequqT489p5E4ThasUF/TRN+DP1J//BhQQgYZd8knwM/4NY2WmPgXm5K2pytOSleWLhnL75b3+hd1w==; 25:syI5w7r+jIwSPYA4ud9jZPCdFkagVeia0Xb9IqdXKCIek+xqHonHMA/1bGykXgVKxJYqybdNu+GKTx3nLq/DKpfvWaIeTQtxX7L+kbyurlQ5uVUOMN/+BJQxHgn8D5VIksT8On3+EhTWRVKw4Zf6eYAHyICTb0obOIYl5piGKvgGbuuOs1HKtCXV+PeBcE1ytrOrmchqChLhjIiVB6opShXrPgDW7Np8540jMXOrV3NWNhaDmmSPiK1Xp9N6qxwDyH/Ko66sN/MvVo3Z9jNLnQ== X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(42134001)(42139001); SRVR:BN3PR0501MB1378; X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1378; 20:zYRqSNKzO66EVa8ZO9e3zTJGtZI/WZjK8XTH5q025P4ojJoXzRNDHxLvuHE7VsZW56u9UCwEL6Ua1G81N1woK9NlHUFAND+nEcOtdp5MobSbfWqUuih72W5hwosuNhp0SmGQf403lLjL9V3e43HxyfSvIyqjVEzm2nAxNI9iNKIm5Ha7/EK7okZyTz4FQ0dIwqRuVQZa2AejSlBFAGd86bIYxEPi7lXerH8ZpZgVfHb0ShW7j+l5EYermDkXJk/oeWbqt1dOMU1lAGX1JrIbtbiBOA3QlepsJzVV+i2C8DtZ3tbabmN8F56ApcvgwgS8f+CUsKE44RUe5DNFdgsBDKVqPfHVUBw9HhqaafDH/TxVerzN8Wv6G4Uxo1kjGBMyvG9UK+p1NdP3IdtWjPeNrC+7hFRRxBpF3UoKwZhndBIGDZrOdAB8Mv1sAo1OJOlpR2RD3UwpdibPtqKKMXo32BmUELPDALfACf0+uimSPcR5rnE5nScjbj4wYVkvsOy3; 4:Ho47iTcf9/1cyUpPB819eaCmdBeHYCPvSIRxYlibFJfWn2i+mx+R1L6Ndt5JcCOIOH2Z//Py2+dO48ipbQ9iqKAJUu9VSwHdwFq5FGDDOPUh13Y3AWplVO04yAyy27aJ7xZ0HbjinXNxSxTjSj73cDVoecU8N3RIYzL6hqwvYIKPvmhbGFogFClWL/eqtrva/NeQC7+RR+JnFxAh5KDnBc+WYJYXBMGLcIFEDiDavlreYH5+dy0pzpxvsaUVK4lrMHsmpulVyDOnS6t94ugmS+1Fo/eBDeygZ/AoNCFcvi4sAtAS25P7ON+bPjMKTQKIE0ulX8JYoNlG8iz0wagJ9aD9zKzba1qXrjD4Bb6NhgTXvdrZePW8SB63x+iYBLUz X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(10201501046)(3002001); SRVR:BN3PR0501MB1378; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1378; X-Forefront-PRVS: 0812095267 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR0501MB1378; 23:2f3zjzEZfrXRpmS+4uJLR4Ghrw34+dwwFw0z9lF?= =?us-ascii?Q?R93/SYmAt4QPv893ZwsaMWrCErGqu5jJYOs8UYzY7qkb4Ll8eJd76c8bMT3A?= =?us-ascii?Q?F5LJV9yJXtSSag+tiYsKM66vFyptqVyWruib8WDBR/fxbdIsNoIMlj+4C7qg?= =?us-ascii?Q?2RLwm+4cDExduQWZtsQk5PcYWCwywhnfRMdyoREUMb7wit5SVEtcWksfran4?= =?us-ascii?Q?YHJSz5DDtGZNfy5zdMmfJVGuWE2qX/Q15WVLihw5KvlpCTNNctAPJ62ZndRF?= =?us-ascii?Q?ZuhaLUEdSBcwrustWnbLkFNLxi5PGouUOvh5iqOXZR4uGtZgnSY8c4nmoR3k?= =?us-ascii?Q?ZifpFVrpmrHYlRDGmSA8Vt4thMSJdS0xTSZLyIWgZsdVImrTde3JD/d2O532?= =?us-ascii?Q?LCJH+Up8IHxCUt7mf240g4EvnFJQsba5WZ6ANM2RGQZPL38dfcklykYFqyZQ?= =?us-ascii?Q?cEdyxbqfGNg5SkTG4X9ZjESG6uDkbmGrebZ+/focrrjvqCz3n2PgGG2/C1EP?= =?us-ascii?Q?fbRB+n8nBDMlFgj01ZgNJKroe1Lq/kHbTtN5DNlv4pOtDzwmZsZv9TonKySn?= =?us-ascii?Q?1wstLkAWCKN3wmHQOyOtu0MDaE4NQsV5s+5EM3mAAkVv5yJdL6zlzWqdhbF4?= =?us-ascii?Q?64Y9ETmm3rHksmSogpkFw+eSrnGs7eOQLTc1aNNxzCw3Ry69JNCy8zycbfz1?= =?us-ascii?Q?kCh6uBRa9MJNgMhH5aS9/lz9/pTllJ1G8Vf00dIQodgfevKotVjWNSYtYLac?= =?us-ascii?Q?a4CNsJdFPHpvlZmO6hL5UQbDvCByxfPX+9ylA592voPHfH2UxaaRSO5BomIH?= =?us-ascii?Q?MjswfOjjY8AX0R2p1PctkwjscSY1bbdbbwdvjbXDenAtHavA6w/sn5kNFilD?= =?us-ascii?Q?LjtDC/YyWVkiYpIPA0QhLG3Tdjdo13jZUY7cuRq1Hn2rJrkVQnAyG0SIdjSi?= =?us-ascii?Q?fRnxuOl374586oitbZ640rq2zMzbiz4yILcwmAfocsDEfz62Jo7UCwr4ZKJa?= =?us-ascii?Q?yNhgj3d8YuLTY6XSucLkYVxdhHvhq5ACclMYMbBJhYt5Cdf9clg43DENizIu?= =?us-ascii?Q?pkHxjoXhoKSYzOo5P3gfvQgPa1r6U3WDKUQL57gNWhHHqIlpGpXic6Rh4Vgz?= =?us-ascii?Q?qRdansCwEDZfH9i/vOosaduNJeEjX+SMuVYcmzxQhjpCKcL3FWgbLaA4V1Nh?= =?us-ascii?Q?XePf8AZ2GU08ouCiecVoWglfxpmXxBFacegCk?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1378; 5:5oA6Fwzvz2O0Htv2XfgVwP7u5BAf/cNfWtuIgcG68GHTbt58btvjN0471+xCim+Lo7q8+YuW2cvkn1W9EimHg0fl0SIcmBblNHEaMm8uxMYu3ohq+7hiWYskhjLlnjzy+xFc9uK8w070mqR1HwdFLw==; 24:mTNwTA+SB+iLLUcwOfLTHzpkjiTBahmU7gxH6yA0/sl1M1Q8huNEs7iKD9Cv8yvLaO90UdV7DdMm34vFIZWVNV4YUBskJ+DfWLXnslieoEQ= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jan 2016 14:01:25.3286 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.19]; Helo=[p-emfe01b-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1378 X-BeenThere: freebsd-transport@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions of transport level network protocols in FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 15:35:04 -0000 Hi Sam, Thanks for bringing this to our attention! Comments in-line. On 1/5/16, 2:57 AM, "hiren panchasara" wrote: >bcc: current@ >Moving the discussion to transport@. > >On 12/28/15 at 12:25P, Sam Kumar wrote: >> Hello, >> I am working with the code for the TCP Stack. I noticed that support for >> Challenge Acks have been added since the latest release (10.2.0), and I >> think I may have found a bug in how they relate to TCP timestamps. All >>line >> numbers below are those in commit >>e66e064c45687b5d294565dbd829b419848f7992. >> >> Looking at tcp_input.c, at lines 1594 to 1604, I see code that expects a >> timestamp to be in every segment during the session, if they were >> negotiated when the connection was being established. >> ( >> >>https://github.com/freebsd/freebsd/blob/master/sys/netinet/tcp_input.c#L1 >>595 >> ) The code *expects* this, but doesn't *enforce* it. If a timestamp is missing, it logs a debug-level message, but still accepts the packet. I think this is reasonable behavior based on the text of RFC 1323, which (I believe) is what was current when this code was written. This is still allowed under RFC 7323. >> >> Looking at tcp_input.c, at lines 2161 and 2188, I see that Challenge >>ACKs >> are sent via calls to tcp_respond(). >> ( >> >>https://github.com/freebsd/freebsd/blob/master/sys/netinet/tcp_input.c#L2 >>161 >> and >> >>https://github.com/freebsd/freebsd/blob/master/sys/netinet/tcp_input.c#L2 >>188 >> ) >> >> Looking at tcp_subr.c, at line 978, I see that the segment sent by >> tcp_respond() never contains TCP options. >> >>(https://github.com/freebsd/freebsd/blob/master/sys/netinet/tcp_subr.c#L9 >>78) >> >> Therefore, it seems to me that Challenge ACKs will never contain any TCP >> options. This violates the condition that once timestamps are >>negotiated, >> they must be present in every segment. I believe your reading of the code is correct. And, I believe RFC 1323 would have allowed this. However, RFC 7323 (just released in September 2014) changes this: Once TSopt has been successfully negotiated, that is both and contain TSopt, the TSopt MUST be sent in every non- segment for the duration of the connection, and SHOULD be sent in an segment (see Section 5.2 for details). The TCP SHOULD remember this state by setting a flag, referred to as Snd.TS.OK, to one. If a non- segment is received without a TSopt, a TCP SHOULD silently drop the segment. A TCP MUST NOT abort a TCP connection because any segment lacks an expected TSopt. Based on this new requirement, it appears that our implementation does not comply. We have two options: A) Switch from using tcp_respond() to using tcp_output() with TF_ACKNOW. B) Fix tcp_respond() so it will add appropriate options. (In addition to the timestamp option, it might be important to add the signature option.) I think option B is probably easy enough to implement without adding all the overhead of tcp_output(). Unless someone objects, I can work on implementing this approach. Please feel free to open a PR to track this problem. Jonathan >> >> Please let me know if I am mistaken, or if this is actually a bug. >> >> Sam Kumar >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to >>"freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-transport@freebsd.org Fri Jan 8 21:46:08 2016 Return-Path: Delivered-To: freebsd-transport@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 75260A67230 for ; Fri, 8 Jan 2016 21:46:08 +0000 (UTC) (envelope-from samkumar99@gmail.com) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::22a]) (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 4C1E01DC0 for ; Fri, 8 Jan 2016 21:46:08 +0000 (UTC) (envelope-from samkumar99@gmail.com) Received: by mail-yk0-x22a.google.com with SMTP id x67so377393506ykd.2 for ; Fri, 08 Jan 2016 13:46:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=IQl/7jBMErzw8RMGRPRhvr8D9CW+zVdlJCk7EHsWWoM=; b=f9vFpr8gfiRRF4rNUK2VQMXagxNpjan059byKcgUi7KCdNalzarOQKyAc2TZYuAZv+ KIiUODK/SZYNQmlIRUZw48LSOztarqGC/U9IqLJjs2FrKt3JBoMt6xtPSq7xOEmLPFnM 8sttCa7ZAQuBmHGQzptyKLvDSwygBBycEOSe1qYwtAk9WP1y+xo+Hqw20jHO6sfTbAIS zrkxXywmb8/xOQ3vDBqajiZ9zwOZrWIfEHzOkqrpEkTf+oZQJiE+cFC2O2QK21iiKO+U 4f0knWXF/bSCdhVuj9GyQoMdISVBBgcsMwoehFR4bkRG/5ULiZ80StdoYUDnoNiQubvH HyiQ== X-Received: by 10.13.202.194 with SMTP id m185mr92955377ywd.280.1452289567524; Fri, 08 Jan 2016 13:46:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.16.138 with HTTP; Fri, 8 Jan 2016 13:45:48 -0800 (PST) From: Sam Kumar Date: Fri, 8 Jan 2016 13:45:48 -0800 Message-ID: Subject: TCP_HAVERCVDFIN To: freebsd-transport@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-transport@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions of transport level network protocols in FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 21:46:08 -0000 Hello, I am working with the code for the TCP Stack. I noticed that in tcp_fsm.h, there is a macro called TCP_HAVERCVDFIN. It is defined as follows: #define TCPS_HAVERCVDFIN(s) ((s) >= TCPS_TIME_WAIT) In "TCP/IP Illustrated, Volume 2" (by Wright and Stevens), the authors mention this. On page 807, they write: "... the name TCPS_HAVERCVDFIN is misleading. A FIN has also been received in the CLOSE_WAIT, CLOSING, and LAST_ACK states." However, I feel that there parts of the code that act as if TCPS_HAVERCVDFIN were defined as #define TCPS_HAVERCVDFIN(s) ((s) == TCPS_TIME_WAIT || (s) == TCPS_CLOSE_WAIT || (s) == TCPS_LAST_ACK || (s) == TCPS_CLOSING) Let me point out the parts of the code and comments in the code that appear to assume this: 1. In tcp_input.c, line 2499: /* * If this is the first time we've seen a * FIN from the remote, this is not a * duplicate and it needs to be processed * normally. This happens during a * simultaneous close. */ if ((thflags & TH_FIN) && (TCPS_HAVERCVDFIN(tp->t_state) == 0)) { tp->t_dupacks = 0; break; } The comment suggests that the body of the if statement should only be executed when processing the first FIN from the remote; however, due to the definition of TCPS_HAVERCVDFIN, it seems that it would be executed for duplicate FINs too. 2. In tcp_input.c, line 2922: if ((thflags & TH_URG) && th->th_urp && TCPS_HAVERCVDFIN(tp->t_state) == 0) { ... (I omitted some code here for clarity) /* * If this segment advances the known urgent pointer, * then mark the data stream. This should not happen * in CLOSE_WAIT, CLOSING, LAST_ACK or TIME_WAIT STATES since * a FIN has been received from the remote side. * In these states we ignore the URG. The comment suggests that URG is ignored if the TCP is in the CLOSE_WAIT, CLOSING, or LAST_ACK states, but I don't see any code enforcing this. If TCPS_HAVERCVDFIN were defined to include these states, then the code would be consistent with the comment. Wright and Stevens point this out (page 983): "The macro TCPS_HAVERCVDFIN is true only for the TIME_WAIT state, so the URG is processed in any other state. This is contrary to a comment appearing later in the code stating that the URG flag is ignored in the CLOSE_WAIT, CLOSING, LAST_ACK, or TIME_WAIT states." 3. In tcp_input.c, line 2993: /* * Process the segment text, merging it into the TCP sequencing queue, * and arranging for acknowledgment of receipt if necessary. * This process logically involves adjusting tp->rcv_wnd as data * is presented to the user (this happens in tcp_usrreq.c, * case PRU_RCVD). If a FIN has already been received on this * connection then we just ignore the text. */ if ((tlen || (thflags & TH_FIN)) && TCPS_HAVERCVDFIN(tp->t_state) == 0) { The comment indicates that the segment text is ignored if we already received a FIN, but this is only if the case if TCPS_HAVERCVDFIN is changed to include the CLOSE_WAIT, CLOSING, or LAST_ACK states. 4. In tcp_output.c, line 621: * Don't send an independent window update if a delayed * ACK is pending (it will get piggy-backed on it) or the * remote side already has done a half-close and won't send * more data. Skip this if the connection is in T/TCP * half-open state. */ if (recwin > 0 && !(tp->t_flags & TF_NEEDSYN) && !(tp->t_flags & TF_DELACK) && !TCPS_HAVERCVDFIN(tp->t_state)) { Due to the definition of TCPS_HAVERCVDFIN, a window update may be sent even if the connection peer has already sent a FIN (contrary to the comment). So it seems to me that TCPS_HAVERCVDFIN should be defined differently, to include the CLOSE_WAIT, CLOSING, or LAST_ACK states. However, there is one part of the code that appears to use the existing definition. See tcp_input.c, line 3062: if (TCPS_HAVERCVDFIN(tp->t_state) == 0) { socantrcvmore(so); /* * If connection is half-synchronized * (ie NEEDSYN flag on) then delay ACK, * so it may be piggybacked when SYN is sent. * Otherwise, since we received a FIN then no * more input can be expected, send ACK now. */ if (tp->t_flags & TF_NEEDSYN) tp->t_flags |= TF_DELACK; else tp->t_flags |= TF_ACKNOW; tp->rcv_nxt++; } If a duplicate FIN is received (because our ACK was lost), then we need to retransmit the ACK. I'm not sure if the above code in the if statement needs to be executed for that to happen (maybe someone could clarify that?) In summary I suspect that the TCPS_HAVERCVDFIN macro needs to be redefined, but I'm not sure whether that is actually the case. I wanted to open a discussion about this to explore whether this is a legitimate issue. From owner-freebsd-transport@freebsd.org Sat Jan 9 15:44:37 2016 Return-Path: Delivered-To: freebsd-transport@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 172A8A69874 for ; Sat, 9 Jan 2016 15:44:37 +0000 (UTC) (envelope-from jtl@freebsd.org) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0137.outbound.protection.outlook.com [157.56.111.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8483618C8 for ; Sat, 9 Jan 2016 15:44:35 +0000 (UTC) (envelope-from jtl@freebsd.org) Received: from BL2PR05CA0026.namprd05.prod.outlook.com (10.255.226.26) by DM2PR0501MB1390.namprd05.prod.outlook.com (10.161.224.12) with Microsoft SMTP Server (TLS) id 15.1.361.13; Sat, 9 Jan 2016 15:11:12 +0000 Received: from BL2FFO11OLC001.protection.gbl (2a01:111:f400:7c09::111) by BL2PR05CA0026.outlook.office365.com (2a01:111:e400:c04::26) with Microsoft SMTP Server (TLS) id 15.1.365.19 via Frontend Transport; Sat, 9 Jan 2016 15:11:12 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.19) smtp.mailfrom=freebsd.org; gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=freebsd.org; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning freebsd.org discourages use of 66.129.239.19 as permitted sender) Received: from p-emfe01b-sac.jnpr.net (66.129.239.19) by BL2FFO11OLC001.mail.protection.outlook.com (10.173.161.185) with Microsoft SMTP Server (TLS) id 15.1.355.15 via Frontend Transport; Sat, 9 Jan 2016 15:11:12 +0000 Received: from magenta.juniper.net (172.17.27.123) by p-emfe01b-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sat, 9 Jan 2016 07:11:11 -0800 Received: from [172.29.33.83] ([172.29.33.83]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id u09FB9D73532; Sat, 9 Jan 2016 07:11:09 -0800 (PST) (envelope-from jtl@freebsd.org) User-Agent: Microsoft-MacOutlook/14.5.9.151119 Date: Sat, 9 Jan 2016 10:11:07 -0500 Subject: Re: TCP_HAVERCVDFIN From: "Jonathan T. Looney" Sender: Jonathan Looney To: Sam Kumar CC: "freebsd-transport@freebsd.org" Message-ID: Thread-Topic: TCP_HAVERCVDFIN References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11OLC001; 1:PnkRbypQZrKQtf9B3RJWGQmAxwAx8BsSq7CfhnFHkXMhmlPYEAkg2GIzUaWYLC4rFRepdT1am+1BOwVZ7MSa5Y0CxD1gNx1exsZrgdx2PhGTUJD8ZTBK6xhuFDGjSlwQVA4wWkiWmgczwGXiLy3BAQUVv+YDj6FogAuIoQeBhz7j0N0Hs86N3urT5Y33IrvVVRFqgiH+aRrBWfxLgNXAe/FVzV0hP1sC4INF8KEnV8yIrZhjJmoV2y+3I/+8GZwFo9ykxvlnSD7dk2gK6rmHMVr5ohkshOecEZ8iSauv55bPDyNNZwGKW02LNYXhUEbAr6yzT2PNxYglzT+NWzLlsyB6m/NV6yi/iQqQSFkdbb8= X-Forefront-Antispam-Report: CIP:66.129.239.19; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(24454002)(377454003)(479174004)(52604005)(189002)(199003)(55674003)(11100500001)(92566002)(586003)(69596002)(19580395003)(19580405001)(47776003)(2906002)(87936001)(50986999)(6806005)(1220700001)(86362001)(23726003)(1096002)(16796002)(230700001)(4326007)(105596002)(189998001)(50466002)(1411001)(106466001)(77096005)(76176999)(2950100001)(561944003)(54356999)(4001350100001)(81156007)(97736004)(5001960100002)(110136002)(36756003)(83506001)(46406003)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0501MB1390; H:p-emfe01b-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB1390; 2:/FF6ytrvmayl3U5EKx1McUq9P1ykir3hcYGGi3M6R2WbvUFTso8BmhSiby/qls4Z3IbiPpeGiV43F3p1dluEebW3HKfws0PdvEXtkXHLnzt3BxPkI/d75SxUlYVXBrd2HY6EInsP9Ppz9g0TCHfE1g==; 3:uYwS6Al/xKG3456Ym/lzR0jb/yWq0Btkfw9v3cgrMBBftws0vEIXDBjCyqdpf5Tl4YJHpU6K3wlI4UbOHXrh/vZXpuoARU3To/GeaHGxBRzhKO5k4vZYTP+4VXGC6+NbjkZagoRzyP74Tr++PRZwfY8ZRZWDeQOOlKHWNv0xvqJWpyLVXlyvhVW0gm1tZN6JKXpbHX/MaAn2Y/ML1Hr9uRe8AcLurGHUbZOdu8RuwpY=; 25:8H0AjTuD2tn3Xhb6HIrEfO3eWhGFtiLuFHxgR7CHp/0d2efbiGIr0ypCUA8b7jEh9/t5kcSMR/S7AahkpUXEN6sOF8puAxRBFoAbw9vOyWZsfRmk8jV+DikjeCRnNeEuW9bO0KaLK8uGhOKdj5muolG9QClViXcHFIfQsJ+Ow+l080Yz3hjzJaIDusXRz7C8/G1kRvSTUWkeVldOms0biZc/xjh8S+4YQ3aYCjdfq+ny1vZk4XQ74nV8G2S44D68 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0501MB1390; X-MS-Office365-Filtering-Correlation-Id: 8e7e6982-0e47-47b9-cb97-08d319071cb0 X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB1390; 20:ynqdskAl/tSQvLsDaN5b8YTeJ7U9eMKrjTT1SbO31av09AiXw92lfM8Inisgzb4zNO2LUmUhKMuPJIUZPIK6LLtfStiqH8ExzpVlGf/QugShzGDPBQ1jkyLNtQGvImy9xdLsq7u5+8PYDfeRl5Mji4YTILBHMYh6fzLFXINDDBuP4+EWPH9EwjPNw8oKPFAvC3KeXTLoANUkXh1bxlM1OVtfwGz3r0xliuCXYlDi371ZAd3J21+K0iUncTVMVwvUv7V33EY0t/JGqinRvPe/bzs2mX4psSFyUGGBesN/JwC3gknQ95scO1ErolrOITobwZaBiowffp91C05Sx8qidR8FL2nUy+3cq+YWqDVsLVNG6jkRGuAuM9mXXd6TkxA+YvZQwIOQb62YSzWSdPlBuRdfNiuOqPUo+fkj63pDm+Ff+QLuRApfz47FfQLq4Un934V17r/94U/VrchY1hbbuYiYsTqNGvAHaWQj74QfnW6xYXw6uL3zvNlxcgqm1Kdy; 4:2DtX3zPln7fhBqSCwAuN9yRImyfaPMxp5QWBvkcKcwelKCTmsZacN15jpPiz1Pgh7OA0MaMt3O68ACWlcfpdjtg+GJYsc8hR8JPcpYzerOfpvAEzCAmWdTngr0syHll8/LdJmFHd9jL7EGzyo8n0a4jwO3/peq3irvnWvgTGBEBp5lWX1qgmt8zdXlMxydMSXzqSuTz9CSGRQIyuaHjK5o1hgCulELZKpBaJuXe67IiYeHRx6fu/6BVzNsaO+N/Kk7VzlbcOjosNGAnArpdTQ4qMXnUTzzbuuWGZ/UeGwCcnMjcLBlYoJNBkWCNC13tHGkhY7fTF+IjKaEyPsi77K7L/p7oWZu26zeL+z1PqfJyxGwc153D3lstQGguepJ8VOEXWluSqjVE1ORjHZ3T8Y28bRBXtiyqPqhoQJecXL56syIpCKfQnPlbP5vnMP6Cn X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(13018025)(8121501046)(5005006)(13015025)(13017025)(10201501046)(3002001); SRVR:DM2PR0501MB1390; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0501MB1390; X-Forefront-PRVS: 0816F1D86E X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM2PR0501MB1390; 23:nKbWDcw5O3ZAtXw75SBbU0QLdGe9S/FyaVDcsEB?= =?us-ascii?Q?UhwWzv2LMKud7Fzc3R0A54Tld3U34/wFgorKaOo+eKdKS1QpY2TL7X8AU2rv?= =?us-ascii?Q?R0LWDgMxfsumQ8O4QOSba8D4BhHhzH4T0nImyZkfiOHUfx/gmCMkPwYXQXUq?= =?us-ascii?Q?cgzIKbzatwt/9I7UKOetym12hmIoldNxO1CtB1GwnAZPzGnXuvK+CfZe8URT?= =?us-ascii?Q?P+/AgURRRQ/IlKI0NcnuxdimEPw3EWq0TlbYcRuCK2CTkAtM/9FU7JNRelgO?= =?us-ascii?Q?VU73xMuDFs2rCuVUthqqZmYcBcmCFvibUDwmGQSoiSeU8nOeCWydGzcViSA7?= =?us-ascii?Q?9iZVg/LPLAfpORtx2biZENtDCZS6QzAKmOUhlZvPJ6/bY4sEXReZStO955Ff?= =?us-ascii?Q?OU25geWqrwUB543pwLdnAn0JVdzgm+skhZcHBwy1eUxQAFfXj/BmR9k+slNy?= =?us-ascii?Q?u6XDu0OAZbR8FLUiBJcveoEcs5hmFudwp94c1BdsCu7CoeXclAZWQL5Vh3iN?= =?us-ascii?Q?UZkBX8PcOey6IVeXKCVug7/3tXcdXyxhEK18Voc65NjRYUB1fw1HjdocLkRy?= =?us-ascii?Q?e3KoxmU81KJvbUQhPQGxnU0dgE9CAZ1uIR5qJmeU4jgK8hSXbIRPTeLeJ/H6?= =?us-ascii?Q?exVkh5n9ldDb1YcESNXY1NQJUvFdHWtE3sjhzn3fUeQbSTBmbbH20dgKNb3e?= =?us-ascii?Q?WQ1CWtB5e/OWeJIzmIbiC78+cYEvHOwzh5ARHwu34QTjnyGJnmkAofCs1tPt?= =?us-ascii?Q?Ep3UNBtnFxCq27E7OtotQBvbRN/deuSMd/u/SDnqeVQcz/EWMSCXLMX2MiaW?= =?us-ascii?Q?wbHe9PzEk5JMAq3eLq/+rwQ4FIR0wQwCVO0W/k6E6V0EX8hGjlgAJbxDt6xz?= =?us-ascii?Q?JCDhhxdvveaZzhbo8BJ7d1+08RcEIhs3pzNDD6Xx/464AyAXCbbYzEl4P5Qz?= =?us-ascii?Q?wHNWZbqe+scMVGIAEvn/eEoe6ao0zuGO8/43w6XKDtOa9qkdGg3DS3yXwNjJ?= =?us-ascii?Q?aTFhvtl2Lh7doZ4ZVIzWURSDACTUSsjjydnSulmWpmR0Th0S1yO2ccRYVd/p?= =?us-ascii?Q?Ae6Z+oXl2xf71/fUA31TPDAejhxifXAmm4cNojJBH70HccFPcVP7MehTqlgW?= =?us-ascii?Q?oGQM5v0nG/d0u4GYKkL3qX5EToSIKWm4p+DGhFlLVZjysBOMoJYo3vh5+3n7?= =?us-ascii?Q?5wwBUSblA0acnFeo=3D?= X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB1390; 5:j4EIeBYNWX9h4GN/uYVjvlFOZJ7WPV273q3wttzOvbgRd+tuTg3KrAM1Z+HV+4E/f4IOQRx+JEBz487h1I4qRTpoTu4MYU0gonCxP9BLHPLOC++U3Bk+4k+IdX8XNbXqN16NozIVm4yV7tGm2eI4Uw==; 24:3aFdoo65NVzDszCPJD7hfHciPzpYWUcXu+BHfrIjHDa8wfQ6q0RySbWqUEj82UraNE9yPfRBw6Pmp3RznTsySZPamCmwhyLFSRQ5AmKwuBE= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jan 2016 15:11:12.2441 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.19]; Helo=[p-emfe01b-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0501MB1390 X-BeenThere: freebsd-transport@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions of transport level network protocols in FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jan 2016 15:44:37 -0000 On 1/8/16, 4:45 PM, "owner-freebsd-transport@freebsd.org on behalf of Sam Kumar" wrote: >I am working with the code for the TCP Stack. Thanks for choosing FreeBSD! :-) >In summary I suspect that the TCPS_HAVERCVDFIN macro needs to be >redefined, >but I'm not sure whether that is actually the case. I wanted to open a >discussion about this to explore whether this is a legitimate issue. In short, it appears you are correct that the macro name does not match the reality of what it checks. This is likely to cause a problem at some point, so it is legitimate to suggest it be fixed. However, this is non-trivial for at least several reasons: A) Changing this will require thoroughly testing all the impacted code. That requires both a thorough conformance-testing suite, as well as thorough performance tests (in case the change impacts performance). However, I don't think the FreeBSD project itself has such things at the moment. (gnn@ might have more to say on this topic. :-) ) B) Even if the code you reference made an erroneous assumption, others may have written other code that assumes the current behavior. Changing the current behavior to be "more correct" might impact other code in subtle ways. (Hence, the need for testing: see (A).) C) Even if we can fully qualify that *our* code works correctly after changing this, third parties may have extended our system in ways that rely on the current behavior. (Hence the need for testing. They "own" that to some extent. But, we owe them some duty to be careful about changing basic building blocks they may use.) D) Changing this may make it harder to port code from other OSs. For example, OpenBSD uses the same definition of TCPS_HAVERCVDFIN that we do. On the other hand, it looks like NetBSD updated theirs (17 years ago!) to something closer to what you suggest. So, porting code from other OSs may already be problematic. Because we now have some level of TCP stack modularity, we *should* be able to build a TCP module that does what you suggest and let people try it out while maintaining the option to fallback to the main stack if things go haywire. However, that is more complicated than I wish it were because it currently requires *copying* code rather than just compiling the same code a second time. I have a proposal to address that, but need to circulate it and get feedback. In the meantime, we can talk through some of these obstacles and see how we want to handle this. We can always define two macros (the old and new one) and change the macro usage from the old to the new one as we feel comfortable. If there is desire to proceed, I would recommend that as the way forward, assuming we can satisfy the testing concerns. Jonathan From owner-freebsd-transport@freebsd.org Sat Jan 9 15:51:18 2016 Return-Path: Delivered-To: freebsd-transport@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 1E82CA69DF3 for ; Sat, 9 Jan 2016 15:51:18 +0000 (UTC) (envelope-from p.m.sewell@googlemail.com) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (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 E9472132D; Sat, 9 Jan 2016 15:51:17 +0000 (UTC) (envelope-from p.m.sewell@googlemail.com) Received: by mail-io0-x229.google.com with SMTP id 1so266316411ion.1; Sat, 09 Jan 2016 07:51:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=cueRMwPBsOzi7SdADpNlj9VjxTsrlvukfDsFiOkCdIk=; b=x+TusiFzwFLaVQznvhMz/k2GafYcrCxb77Ign7gdyEkYnJYedXTSrM9Jvi4um/d5mP /vE/kFS9mRaJHI607uvOxJt2jgqtsYFjMywHWur6+tRAeDKg75hWjG9bOb1WfN4dZYT1 3WMCvv+yCMXqDuQYhZQGgbfzX8pAa8i00TWg1vd+XNBHovQ93e5FkyF3elm/0Zh6QFtb 65B7w7sixHNDzfUkKzsC7m/2WZuChRU1LcGCYsKc8LaL6NxCvuG8Or96Vr6w6HujOEuz PupjtFX+rSlfCoX7yXAqv+uxyJ6VfOgnj6463YZ6DtgPsvK9FiYDvgFqgfxcYPcO7Bcy HCQg== MIME-Version: 1.0 X-Received: by 10.107.7.22 with SMTP id 22mr52661662ioh.17.1452354677346; Sat, 09 Jan 2016 07:51:17 -0800 (PST) Reply-To: Peter.Sewell@cl.cam.ac.uk Sender: p.m.sewell@googlemail.com Received: by 10.64.69.3 with HTTP; Sat, 9 Jan 2016 07:51:17 -0800 (PST) In-Reply-To: References: Date: Sat, 9 Jan 2016 15:51:17 +0000 X-Google-Sender-Auth: FMpmmDYzmQJG15XLq9dk-v7mdGQ Message-ID: Subject: Re: TCP_HAVERCVDFIN From: Peter Sewell To: "Jonathan T. Looney" Cc: Sam Kumar , "freebsd-transport@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-transport@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions of transport level network protocols in FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jan 2016 15:51:18 -0000 I remember we found something odd about this in our Netsem formal TCP spec - see item 12 of the "Implementation anomalies" on p. 64 of: http://www.cl.cam.ac.uk/~pes20/Netsem/tr.pdf, pasted below. Peter 12. (Protocol bug) States in which we have received a FIN TCPS_HAVERCVDFIN(s) is defined as: In the BSD code, the macro #define TCPS_HAVERCVDFIN(s) ((s) >=3D TCPS_TIME_WAIT) Clearly, this set of states should also include CLOSE WAIT, LAST ACK and CLOSING, since we must have received a FIN segment to enter such a state. This macro is used three times in the code (in tcp_input.c), preventing the following from happening if we believe we have received a FIN : 1. Processing of urgent data (i.e. from segments with the URG flag set). 2. Processing normal data data, and arranging to ACK it. 3. Processing a FIN segment and performing the appropriate state changes. See deliver in =E2=88=97. Impact: A consequence of the first of the above is that it is possible (with suitably crafted segments) to generate a SIGURG signal from a socket after its connection has been closed. Data may also be received by a closing socket. Similarly, extra FIN s will be processed, causing an ACK to be emitted and an increment of the sequence number (of course this will only happen if the peer=E2=80=99s TCP stack is broken, or malicious). On 9 January 2016 at 15:11, Jonathan T. Looney wrote: > On 1/8/16, 4:45 PM, "owner-freebsd-transport@freebsd.org on behalf of Sam > Kumar" samkumar99@gmail.com> wrote: > >>I am working with the code for the TCP Stack. > > Thanks for choosing FreeBSD! :-) > > >>In summary I suspect that the TCPS_HAVERCVDFIN macro needs to be >>redefined, >>but I'm not sure whether that is actually the case. I wanted to open a >>discussion about this to explore whether this is a legitimate issue. > > In short, it appears you are correct that the macro name does not match > the reality of what it checks. This is likely to cause a problem at some > point, so it is legitimate to suggest it be fixed. > > However, this is non-trivial for at least several reasons: > > A) Changing this will require thoroughly testing all the impacted code. > That requires both a thorough conformance-testing suite, as well as > thorough performance tests (in case the change impacts performance). > However, I don't think the FreeBSD project itself has such things at the > moment. (gnn@ might have more to say on this topic. :-) ) > > B) Even if the code you reference made an erroneous assumption, others ma= y > have written other code that assumes the current behavior. Changing the > current behavior to be "more correct" might impact other code in subtle > ways. (Hence, the need for testing: see (A).) > > C) Even if we can fully qualify that *our* code works correctly after > changing this, third parties may have extended our system in ways that > rely on the current behavior. (Hence the need for testing. They "own" tha= t > to some extent. But, we owe them some duty to be careful about changing > basic building blocks they may use.) > > D) Changing this may make it harder to port code from other OSs. For > example, OpenBSD uses the same definition of TCPS_HAVERCVDFIN that we do. > On the other hand, it looks like NetBSD updated theirs (17 years ago!) to > something closer to what you suggest. So, porting code from other OSs may > already be problematic. > > Because we now have some level of TCP stack modularity, we *should* be > able to build a TCP module that does what you suggest and let people try > it out while maintaining the option to fallback to the main stack if > things go haywire. However, that is more complicated than I wish it were > because it currently requires *copying* code rather than just compiling > the same code a second time. I have a proposal to address that, but need > to circulate it and get feedback. > > In the meantime, we can talk through some of these obstacles and see how > we want to handle this. We can always define two macros (the old and new > one) and change the macro usage from the old to the new one as we feel > comfortable. If there is desire to proceed, I would recommend that as the > way forward, assuming we can satisfy the testing concerns. > > Jonathan > > > _______________________________________________ > freebsd-transport@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-transport > To unsubscribe, send any mail to "freebsd-transport-unsubscribe@freebsd.o= rg"