Skip to first unread message
richard
Jul 20, 2017, 11:05:05 AM7/20/17
to ns-3-users
Hi all,
I am experiencing a weird situation (not sure yet if it is a bug or application related). I will try to explain in a very simplified way what I am testing so I do not need to post my code also.
I have a sender using send-bulk-app and a receiver using packet-sink.
When the sender sends FIN, and the receiver (packet-sink) replies FIN,ACK and this packet gets lost, the receiver will retransmit the FIN, however the receiver will ignore that packet (so no RST) making the sender retransmit the FIN forever which floods the network.
Is that a known issue? Is it due to a bad implemented bulk and sink apps? Could it be a TCP bug?
Regards,
Richard
I am experiencing a weird situation (not sure yet if it is a bug or application related). I will try to explain in a very simplified way what I am testing so I do not need to post my code also.
I have a sender using send-bulk-app and a receiver using packet-sink.
When the sender sends FIN, and the receiver (packet-sink) replies FIN,ACK and this packet gets lost, the receiver will retransmit the FIN, however the receiver will ignore that packet (so no RST) making the sender retransmit the FIN forever which floods the network.
Is that a known issue? Is it due to a bad implemented bulk and sink apps? Could it be a TCP bug?
Regards,
Richard
richard
Jul 20, 2017, 11:06:37 AM7/20/17
to ns-3-users
Mistake in the title : TCP: When [FIN ACK] (server side) gets lost sender retries forever
richard
Jul 20, 2017, 1:13:07 PM7/20/17
to ns-3-users
I attach the pcap file of the sender and receiver as well as an output with the applications and TcpSocketBase debugging enabled at ALL level. If you look for FIN in the file you will go to the first FIN the sender sends and where the problem starts.
richard
Jul 21, 2017, 7:47:09 AM7/21/17
to ns-3-users
I just tried the same example with ns3-dev and the bug (if it is a bug) remains.
mn
Jul 25, 2017, 5:14:10 AM7/25/17
to ns-3-users
can you attach the code ? then i will be able to debug the code
Joerg
Mar 28, 2020, 4:47:53 PM3/28/20
to ns-3-users
Dear ns-3 experts,
I've also observed a behavior which leads to endless sending of FIN packets, because the ACK response got lost (packet nr. 7 in the attached Wireshark screenshot). I was able to create a minimum working example based on tcp-bulk-send, see diff file.Tested today on ns-3-dev commit b98955f20a5ff44b855c9a925c28b2b486bcae6a.
What I saw in the debugger:
I did neither check RFCs nor any other implementations. In other pcap traces, ACKs are retransmitted and a RST is sent after a specified number of FIN retransmission. There is also a related but rather old post about this problem which points to bugzilla.
Best regards
Joerg
I've also observed a behavior which leads to endless sending of FIN packets, because the ACK response got lost (packet nr. 7 in the attached Wireshark screenshot). I was able to create a minimum working example based on tcp-bulk-send, see diff file.
./waf --run "tcp-bulk-send --tracing=true --maxBytes=123What I saw in the debugger:
/*
###CLIENT### ###SERVER###
Closes socket, sends FIN without data ---> Receives FIN, changes from ESTABLISHED to CLOSE_WAIT
ACK gets lost <-x- //respond with FIN,ACK
Retransmit FIN ---> TcpSocketBase::DoForwardUp() calls TcpSocketBase::ProcessWait()
which does not trigger a retransmission
Retransmit FIN ---> ...
Retransmit FIN continues forever, ---> ...
because non-data packet does not have
something like m_dataRetrCount
(TcpSocketBase::ReTxTimeout() Line 3453)
*/I did neither check RFCs nor any other implementations. In other pcap traces, ACKs are retransmitted and a RST is sent after a specified number of FIN retransmission. There is also a related but rather old post about this problem which points to bugzilla.
Best regards
Joerg
Joerg
Jun 16, 2020, 3:05:04 AM6/16/20
to ns-3-users
Thanks Tom!
Reply all
Reply to author
Forward
0 new messages