Ncat: cerver/client should not call shutdown(<fd>, SHUT_WR) if SCTP is used.

[Tomas Hozza <thozza () redhat com>]

Hi.

There is a problem with the current Ncat's behaviour in case of using SCTP. The issue
is that SCTP's design does NOT provide half-closed connection as TCP does. 

If server reads EOF from STDIN it calls shutdown(<fd>, SHUT_WR). This will cause
client to read EOF from socket and indicate that no more data are coming from
the server. But moreover this call (and also just sending EOF to the client)
will trigger SCTP connection shutdown procedure initiated by the server. Client has
to proceed with the shutdown and no more data can be send through the socket
after receiving EOF. This procedure is handled by the kernel SCTP stack (on Linux).

In the current implementation if client calls shutdown(<fd>, SHUT_WR)
on reading EOF from STDIN, server will quit and the client keeps running.
The same happens if you switch client and server in the scenario.

I think that Ncat (server/client) should call shutdown(..., SHUT_WR) on the socket
only if o.sctp is not set.

There is still a question how should Ncat behave as a client/server for SCTP.

I see four possibilities of ncat's behaviour if SCTP is used:

1. -----------------------------------------------------------
If server reads EOF from STDIN it will NOT call shutdown(<fd>, SHUT_WR).
Server will not respond to any further input from STDIN. Bad thing about this is
that client will NOT "know" that no more data are coming from the server.
So now if client reads EOF from STDIN it can NOT call shutdown(<fd>, SHUT_WR),
too. It would cause the connection to close but there may be more data coming
from the server (at least client "thinks" this since it did not receive any EOF)!
So client will not respond to any further input from STDIN either. This will result
in client and server not responding to any input from STDIN and waiting for some
incoming data that will never come. It is kind of a deadlock.
The same applies if you switch server with client.

Pros: no data sent by client/server will be lost.
Cons: can result in kind of a deadlock.

2. -----------------------------------------------------------
If server reads EOF from STDIN it will exit the listening loop causing the connection
to close. If client reads EOF on STDIN it will just not respond to any further input
from STDIN, but will do nothing with the connection. Bad thing about this is that
data from client will be lost if server closes the connection before client sends them.

Pros: no data sent by server will be lost.
      can NOT result in a deadlock
Cons: data not sent by client before server closes the connection will be lost.

3. -----------------------------------------------------------
If server reads EOF on STDIN it will just not respond to any further input
from STDIN, but will do nothing with the connection. If client reads EOF on STDIN
it will close the connection. Bad thing about this is that data from server will
be lost if client closes the connection before server sends them.

Pros: no data sent by client will be lost.
      can NOT result in a deadlock
Cons: data not sent by server before client closes the connection will be lost.

4. -----------------------------------------------------------
If server reads EOF on STDIN it will exit the listening loop causing the connection
to close. If client reads EOF on STDIN it will close the connection. Bad thing about
this is that data from server(client) will be lost if client(server) closes the
connection before server(client) sends them.

Pros: can NOT result in a deadlock
Cons: data not sent by server(client) before client(server) closes the connection will be lost.


The scenario #1 makes the most sense to me. What do other people think? I can prepare a patch
for Ncat once there is an agreement on the correct behaviour.

Regards,

Tomas Hozza
_______________________________________________
Sent through the dev mailing list
http://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/