Date: Tue, 07 Jan 2014 14:40:06 -0800 From: Peter Wemm <peter@wemm.org> To: freebsd-net@freebsd.org Subject: Re: TCP question: Is this simultaneous close handling broken? Message-ID: <52CC8246.7080609@wemm.org> In-Reply-To: <52CC5F2E.5030201@wemm.org> References: <52CB3AE9.3030107@wemm.org> <52CC5F2E.5030201@wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --THfFN3Oi0mROUh9xOcrEIPcW0LnguJ57W Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 1/7/14, 12:10 PM, Peter Wemm wrote: > On 1/6/14, 3:23 PM, Peter Wemm wrote: >> We've hit a weird problem at work when dealing with simultaneous close= s. >> In this particular case, it's a FreeBSD-7.4 machine talking some rando= m >> Linux host. >> >> There is a client/server protocol in use, and both ends are doing a cl= ose >> at the same time. It might be a shutdown, I haven't seen all the code= yet. > [..] >> A packet capture, with relative timestamps: >> >> 000050 freebsd.28411 > linux.14001: F 6486:6486(0) ack 232 >> 000031 linux.14001 > freebsd.28411: F 232:232(0) ack 6486 >> 000333 linux.14001 > freebsd.28411: . ack 6487 >> [200ms retransmit timer fires on linux] >> 200490 linux.14001 > freebsd.28411: F 232:232(0) ack 6487 >> 000011 freebsd.28411 > linux.14001: . ack 233 > [..] >> What am I looking at? Who's at fault? It looks like we're failing to= >> recognize the ack for our fin. >=20 > It definitely looks like FreeBSD at fault. We've simply not acked thei= r FIN > until they retransmitted it. >=20 > I've looked at the commit logs and I don't see anything obvious that st= ands > out to me for a fix for this. Most of the changes seem to be lock stru= cture > changes than protocol fixes. I see things like ECN and other protocol > features being added as well. >=20 > Where should I look in the code? It turns out it's fixed in HEAD. ------------------------------------------------------------------------ r258821 | eadler | 2013-12-01 19:11:25 -0800 (Sun, 01 Dec 2013) | 14 line= s In a situation where: - The remote host sends a FIN - in an ACK for a sequence number for which an ACK has already been received - There is still unacked data on route to the remote host - The packet does not contain a window update The packet may be dropped without processing the FIN flag. PR: kern/99188 Submitted by: Staffan Ulfberg <staffan@ulfberg.se> Discussed with: andre MFC after: never ------------------------------------------------------------------------ The bug in question is from Date: Mon, 19 Jun 2006 23:45:05 +0200 (CEST) This is the exact situation we hit. --=20 Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6F= JV UTF-8: for when a ' just won\342\200\231t do. --THfFN3Oi0mROUh9xOcrEIPcW0LnguJ57W Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLMgkYACgkQFRKuUnJ3cX/KuQCfV6gHtCN58vr6A+fpUsVPJ7YL jWIAn0itVXvDRhEGCH+zrsX5XO9rJNq/ =aWiN -----END PGP SIGNATURE----- --THfFN3Oi0mROUh9xOcrEIPcW0LnguJ57W--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?52CC8246.7080609>