Date: Mon, 06 Jan 2014 15:23:21 -0800 From: Peter Wemm <peter@wemm.org> To: freebsd-net@freebsd.org Subject: TCP question: Is this simultaneous close handling broken? Message-ID: <52CB3AE9.3030107@wemm.org>
next in thread | raw e-mail | index | archive | help
We've hit a weird problem at work when dealing with simultaneous closes. In this particular case, it's a FreeBSD-7.4 machine talking some random Linux host. There is a client/server protocol in use, and both ends are doing a close at the same time. It might be a shutdown, I haven't seen all the code yet. A convenient summary of how a simultaneous close is performed: "A simultaneous CLOSE by users at both ends of a connection causes FIN segments to be exchanged. When all segments preceding the FINs have been processed and acknowledged, each TCP can ACK the FIN it has received." 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 I am not familar with the finer details of edge cases of TCP/IP like this, but this looks a bit odd to me. What am I looking at? Who's at fault? It looks like we're failing to recognize the ack for our fin. The quote above from some google search result: http://www.freesoft.org/CIE/Course/Section4/11.htm Insight would be greatly appreciated... -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV UTF-8: for when a ' just won\342\200\231t do.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?52CB3AE9.3030107>