Bug 2092 - Closed master TCP socket after failed connection handshake
Closed master TCP socket after failed connection handshake
Status: CONFIRMED
Product: dce
Classification: Unclassified
Component: other
unspecified
PC Linux
: P5 normal
Assigned To: Hajime Tazaki
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2015-04-09 12:13 EDT by Matías Richart
Modified: 2015-06-08 15:02 EDT (History)
1 user (show)

See Also:


Attachments
Test case (9.96 KB, patch)
2015-06-02 10:15 EDT, Matías Richart
Details | Diff
Patch (730 bytes, patch)
2015-06-02 10:15 EDT, Matías Richart
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Matías Richart 2015-04-09 12:13:05 EDT
In summary the bug consists in that, when using a socket in mode LISTEN (waiting for connection requests) if the packet with the SYN+ACK is lost for every retransmission attempt the master socket is closed. 

We trace the problem to the file tcp-socket.base.cc of ns3. What is happening is that ns3 when imitating a new connection, after the arrival of a SYN packet, it forks a new socket (see ProcessListen() and CompleteFork()) for that connection but in dce no socket is allocated yet. Only after the final ACK is received, the function ConnectionSucceeded is called, which makes dce to wakeup the Accept and then create a new dce socket.
Then if the connection fails, the function CloseAndNotify() is called. This function deallocates memory and invokes a close callback. This callback is used by dce to deallocate its sockets (see CloseSucces() in unix-stream-socket-fd), but as the associated socket is the master, the master is closed.

We make the CloseAndNotify not to invoke the callback if it was caused by a SYN+ACK failed retransmissions and it works, the master socket is not closed.
This patch is simple but we are not sure if it is the best solution. It appears to be a problem of dce and not of ns3.
Comment 1 Hajime Tazaki 2015-05-26 06:25:49 EDT
Thanks for the report.

Is it possible to provide 1) a patch (you're not sure), and 2) a minimum reproducible simulation scenario of the issue.
Comment 2 Matías Richart 2015-06-02 10:14:19 EDT
(In reply to Hajime Tazaki from comment #1)
> Thanks for the report.
> 
> Is it possible to provide 1) a patch (you're not sure), and 2) a minimum
> reproducible simulation scenario of the issue.

Hi Hajime.
I attach an example as a patch. It is a simple wireless scenario where I move nodes so as to be able to receive the SYN packet but not the other packets of the three-way handshake.
The applications consist on a client and a server, where the server makes a select and then an accept.
The problem is, as I said in the report, that the master socket is closed when the connection fail and then the select unblocks and the accept fails.

I also attach the patch. It is a patch in ns3 and not in dce.
Comment 3 Matías Richart 2015-06-02 10:15:22 EDT
Created attachment 2056 [details]
Test case
Comment 4 Matías Richart 2015-06-02 10:15:43 EDT
Created attachment 2057 [details]
Patch
Comment 5 Hajime Tazaki 2015-06-07 20:29:10 EDT
(In reply to Matías Richart from comment #2)
> (In reply to Hajime Tazaki from comment #1)
> > Thanks for the report.
> > 
> > Is it possible to provide 1) a patch (you're not sure), and 2) a minimum
> > reproducible simulation scenario of the issue.
> 
> Hi Hajime.
> I attach an example as a patch. It is a simple wireless scenario where I
> move nodes so as to be able to receive the SYN packet but not the other
> packets of the three-way handshake.
> The applications consist on a client and a server, where the server makes a
> select and then an accept.
> The problem is, as I said in the report, that the master socket is closed
> when the connection fail and then the select unblocks and the accept fails.
> 
> I also attach the patch. It is a patch in ns3 and not in dce.

Thanks. I will look at and try the script and patch.

Do you think it'll not happen only with ns-3 scenario (without dce) ?
if yes, it would be nice to have a pure ns-3 script (example/test-case) to reproduce this issue.
Comment 6 Matías Richart 2015-06-08 15:02:55 EDT
(In reply to Hajime Tazaki from comment #5)
> (In reply to Matías Richart from comment #2)
> > (In reply to Hajime Tazaki from comment #1)
> > > Thanks for the report.
> > > 
> > > Is it possible to provide 1) a patch (you're not sure), and 2) a minimum
> > > reproducible simulation scenario of the issue.
> > 
> > Hi Hajime.
> > I attach an example as a patch. It is a simple wireless scenario where I
> > move nodes so as to be able to receive the SYN packet but not the other
> > packets of the three-way handshake.
> > The applications consist on a client and a server, where the server makes a
> > select and then an accept.
> > The problem is, as I said in the report, that the master socket is closed
> > when the connection fail and then the select unblocks and the accept fails.
> > 
> > I also attach the patch. It is a patch in ns3 and not in dce.
> 
> Thanks. I will look at and try the script and patch.
> 
> Do you think it'll not happen only with ns-3 scenario (without dce) ?
> if yes, it would be nice to have a pure ns-3 script (example/test-case) to
> reproduce this issue.

It only happens with dce. The problem is that the dce socket has not been created at this time but the ns3 socket has. So when the socket is closed, it generates the dce master socket to be closed.

If you don't want to change anything in ns3 perhaps a better solution is to change in dce when the socket is created. For example, creating it when the function ConnectionRequest is called, I haven't study this option.