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

[David Fifield <david () bamsoftware com>]

On Fri, Feb 08, 2013 at 06:59:09AM -0500, Tomas Hozza wrote:
> 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.

#1 is the right answer. That is how Ncat worked for TCP before we added
in special-purpose shutdown code.

In your patch, please make an abstraction around shutdown, that calls
shutdown or not depending on whether TCP is being used. I'd rather not
have new conditionals near the EOF handling code.

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