Bugzilla – Bug 242
TCP does not send FIN on Socket->Close()
Last modified: 2008-09-07 19:46:27 EDT
This bug does not seem to affect the socket behavior as seen from the application, but someone inspecting the TCP packet trace will notice a FIN missing in one direction. This can be seen in the pcap output of tcp-large-transfer example. Upon looking at this example, there seem to be problems in various places. 1) the example does not ever stop the applications (in this case, the PacketSink) 2) however, if the tcp-large-transfer.cc has this added: apps.Start (Seconds (0.0)); + apps.Stop (Seconds (60.0)); it doesn't have any effect because PacketSink does not close the socket. PacketSink needs something like this in StopApplication(): { if (m_socket) { + m_socket->Close (); m_socket->SetRecvCallback (MakeNullCallback<void, Ptr<Socket> > ()); } } 3) however, even this does not remedy the problem. Stepping through the tcp-socket-impl.cc, upon Close(), the socket calls ProcessEvent() but it results in NO_ACT and no FIN is sent. The state of the socket being closed is LISTEN, which probably hints at the problem, since PacketSink is not a multitasking server.
Having fixed bug 244 makes the apps.Stop (Seconds (60.0)) fix do more towards getting the close down to work correctly. There are still some issues with the sequence numbers, i.e. I think the FINs should count as a byte such that the ack number on the other side gets bumped up in response to them. This isn't present in the GTNetS implementation.
(In reply to comment #1) > Having fixed bug 244 makes the apps.Stop (Seconds (60.0)) fix do more towards > getting the close down to work correctly. There are still some issues with the > sequence numbers, i.e. I think the FINs should count as a byte such that the > ack number on the other side gets bumped up in response to them. This isn't > present in the GTNetS implementation. > I was just going to roll the fix for it into the one for this bug. I really am reading this bug description as "TCP connection close down is not right".
Created attachment 208 [details] makes sure closedown FIN exchange is correct This fixes the issue, but I'm waiting to push because it is causing strange behavior in the tcp-errors example.
The TCP errors example already breaks TCP (i.e. it is a valid use of TCP which causes it to fail). This then is a separate issue. I suggest that we move forward by applying this patch, removing tcp-errors from ns-3-dev, and then filing another bug against the other issue with tcp-errors as a test case. If I don't receive any strong opposition within the next two days, this is how I will move forward.
Fixed in ns-3-dev 3643:7afa66c2b291 Traces updated in ns-3-dev-ref-traces 39:411b3c03731c