Begin forwarded message:
Date: Fri, 12 Dec 2003 09:18:33 -0800
Subject: [Bugme-new] [Bug 1675] New: TCP occasionally ignores a FIN, requiring
Summary: TCP occasionally ignores a FIN, requiring a retransmit
Kernel Version: 2.4.20-18.9, 2.4.22
Distribution: Redhat 9
Hardware Environment: Dual Intel Xeon Server, with Intel Corp. 82546EB Gigabit
Software Environment: Linux, symptom provoked using small NetPIPE test
If a FIN is delivered to the Linux TCP stack close (within around 10us) to the
is sending a FIN|ACK, it does not acknowledge the received FIN. The other node
required to retransmit the FIN, which is then correctly acknowledged.
I can supply an ethereal trace to illustrate this.
I suspect it is a race in the state change of the TCP connection, although I
an obvious candidate for it in the source - it seems to correctly implement the
Because it seems to only involve FINs, and the stack resolves it with a
this problem would not normally be visible. As a result this is an annoyance
than a serious problem, but having spent a week convincing myself that it is a
Linux, I'm quite interested to find what's wrong.
I have tested it on 2.4.20 (with hyperthread enabled) and 2.4.22 (with
disabled) kernels. Both are SMP kernels, which could be the cause of the race.
Steps to reproduce:
I am provoking the symptom using a different TCP stack on the remote node,
itself running on a proprietary high performance network, bridged onto the
the linux node is on. Because the problem is so sensitive to the timing of the
of the FIN packet it will be hard to reproduce on another setup. The traffic
generated by a simple NetPIPE test:
NPtcp -p 0 -i -l 64 -n 10 -u 64 -h <hostname>
I'm happy to try any fixes that are suggested on this setup to see if it does
the problem. Also, let me know any questions you have to help track it down.
ethereal trace is the best way to see what the problem is.
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.