TCP question: Is this simultaneous close handling broken?
Peter Wemm
peter at wemm.org
Tue Jan 7 20:10:25 UTC 2014
On 1/6/14, 3:23 PM, Peter Wemm wrote:
> 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 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.
It definitely looks like FreeBSD at fault. We've simply not acked their FIN
until they retransmitted it.
I've looked at the commit logs and I don't see anything obvious that stands
out to me for a fix for this. Most of the changes seem to be lock structure
changes than protocol fixes. I see things like ECN and other protocol
features being added as well.
Where should I look in the code?
--
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 246 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-net/attachments/20140107/dfbf5e75/attachment.sig>
More information about the freebsd-net
mailing list