TCP question: Is this simultaneous close handling broken?

[Peter Wemm]

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 at wemm.org; peter at FreeBSD.org; peter at yahoo-inc.com; KI6FJV
UTF-8: for when a ' just won\342\200\231t do.