Re: [PATCH] Ncat as a client should quit event loop on EOF only if recvonly

[Tomas Hozza <thozza () redhat com>]

----- Original Message -----
> On Fri, Feb 08, 2013 at 06:30:44AM -0500, Tomas Hozza wrote:
> > I just noticed, that the server behaviour is the same as for
> > client.
> > If server reads EOF from the socket it quits even if o.recvonly is
> > not set. Do you think that the server should be fixed, too? So that
> > it quits on reading EOF from socket only if o.recvonly is set.

I encountered several issues while trying to prepare patches for server/client.

The whole concept of keeping half-closed TCP connection opened seems to be
not very fortunate. I discovered that some firewalls are terminating half-closed
TCP connections by default after some timeout.

There are also other issues:
- Imagine server is using --keep-open or --broker. Client half-closed the connection,
  was running and receiving data for some time and then exited. Server will not
  know that the client exited unless it will try to write some data to the socket.
  This is a real issue when combined with --max-conns option. When already dead
  connections are preventing other clients from connecting to the server.

- One side has very limited ways how to check if the another side closed the connection
  and exited or just half-closed the connection. After I did some research I think
  the only way how to find out is to try to write some data to the socket. But this is
  very bad way. We don't want to just send some random data to the other side. (I tried
  also call send() with ZERO data length but on Linux this will not send any packet
  to the other side.

  I would welcome any ideas on this. If anybody knows any other way how to check
  if the other side just closed the socket and exited OR if it half-closed the socket
  and is still listening. (I don't think that for example TCP KEEPALIVE can be used for
  this because the default timeout is really long).

I didn't noticed any other issues that can not be solved without much pain.

> PASS Client closes stdout and keeps running after socket EOF (sctp)
> PASS Client closes stdout and keeps running after socket EOF (sctp ssl)
> FAIL Server closes stdout and keeps running after socket EOF (sctp)
> FAIL Server closes stdout and keeps running after socket EOF (sctp ssl)
This test makes no sense for SCTP since client can not keep running
after receiving EOF from socket since SCTP does not support half-closed
connections. [1]

> So yes, it looks like this is the last case that needs to be fixed,
> and
> we will welcome a patch.

I'm not able to prepare a "reasonable" patch without solving previously described issue
of distinguishing half-closed and fully closed socket without writing any data to it.


I think it is also good if I mention the original issue that was behind my intention
to fix the client behaviour.

Imagine the following scenario:
1. $ echo "SERVER send" | ./ncat -l 6666
2. $ echo "CLIENT send" | ./ncat localhost 6666

In some cases (around 10% of runs) client will quit the event loop after reading EOF
from the socket before it can send its own data. The WRITE event is already in the
event loop pool, but after client calls nsock_loop_quit() the WRITE event is deleted.
There seems to be some race condition or some timing issue. I was not able to idetify
the reasons for this behaviour when inspecting and debugging ncat. I'm including two
Ncat client outputs:

client-good - when client sends its data
client-bad - when client calls nsock_loop_quit() before sending its data to the server.

I was also thinking it might be easier to go back to the "old" client/server EOF behaviour
with two differences:

- Fix the Client to send its already read data to the server before it exits after reading
  EOF from the socket. I can imagine some new nsock function to call when using TCP - nsock_loop_finish()
  that would prevent any new event to be added to the event loop, but it would guarantee that
  already added events would be processed. After there are no more events to process the event
  loop would quit anyway.
- Fix client/server not to call shutdown(..., SHUT_WR) when using SCTP. [1]


Looking forward to some advices, ideas and opinions on these issues.

Thank you.
Regards,

Tomas Hozza


[1] http://seclists.org/nmap-dev/2013/q1/203
_______________________________________________
Sent through the dev mailing list
http://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/