(In reply to comment #0)
> Description of problem:
> ncat many times terminates the TCP or STCP transaction before all data were sent.
> Typically in a client/server connection only one side send all data, then
> immediately call for connection close, what is all right, but the other side
> accept the connection and do not send its data prior to closure, what is not
> correct.
> Moreover, this used to work on RHEL-6 as expected, so this can be considered
> as regression.

For TCP, this is true, but nc in RHEL-6 does NOT support SCTP at all!

> Additional info:
> Note, the issue is not on client side only as it might looks like, I've seen
> also a trace where the client sent the data and the server not (I think it
> was for sctp).

Described issue can be fixed for TCP connections. But in case of SCTP connection this
is more complicated. In fact ncat's behaviour can NOT be the same for TCP and SCTP.
The problem is that SCTP's design does NOT provide half-closed connection as TCP does.

So in case of TCP (after fix):
If server reads EOF from STDIN it calls shutdown(<socket_fd>, SHUT_WR). This will cause
client to read EOF from socket and indicate that no more data are coming from
the server. But the connection still remains half-opened. This means client
can still send some data to server. After client reads EOF from STDIN it also
calls shutdown(<socket_fd>, SHUT_WR). This will cause the client to close the connection.
The same applies if you switch server with client.

In case of SCTP (current behaviour):
If server reads EOF from STDIN it calls shutdown(<socket_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.

In the current implementation client will "think" that it can still send some data
to server. But writing to the socket will FAIL since the connection was closed.
It will result into a "broken pipe" error and causes client to crash.
The same applies if you switch server with client.


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

1. -----------------------------------------------------------
If server reads EOF from STDIN it will NOT call shutdown(<socket_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(<socket_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.


There needs to be some more discussion about what should be the proper ncat's behaviour
for SCTP. I will forward this message to the upstream devel mailing-list.

I will also prepare a scratch build with fixed TCP behaviour for you to test.

Created attachment 694300 [details]
Patch to fix TCP issue based on latest upstream SVN

Patch sent to upstream

Created attachment 694979 [details]
Patch for Ncat's testsuite to reflect changes in behaviour

Patch sent to upstream.

This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.