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

[David Fifield <david () bamsoftware com>]

On Mon, Feb 18, 2013 at 08:08:54AM -0500, Tomas Hozza wrote:
> ----- 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]

As it sounds like this is non-trivial, what I have done is made the
relevant tests XFAILS. This is how it looks now. I broke out the SCTP
tests with different behavior as you suggested.

XFAIL Client closes socket write and keeps running after stdin EOF (tcp)
XFAIL Client closes socket write and keeps running after stdin EOF (tcp ssl)
PASS --send-only client closes socket write and stops running after stdin EOF (tcp)
PASS --send-only client closes socket write and stops running after stdin EOF (tcp ssl)
PASS Server closes socket write and keeps running after stdin EOF (tcp)
PASS Server closes socket write and keeps running after stdin EOF (tcp ssl)
PASS --send-only server closes socket write and stops running after stdin EOF (tcp)
PASS --send-only server closes socket write and stops running after stdin EOF (tcp ssl)
PASS Client closes stdout and keeps running after socket EOF (tcp)
PASS Client closes stdout and keeps running after socket EOF (tcp ssl)
PASS Client closes stdout and stops running after socket EOF (sctp)
PASS Client closes stdout and stops running after socket EOF (sctp ssl)
PASS --recv-only client closes stdout and stops running after socket EOF (tcp)
PASS --recv-only client closes stdout and stops running after socket EOF (sctp)
PASS --recv-only client closes stdout and stops running after socket EOF (tcp ssl)
PASS --recv-only client closes stdout and stops running after socket EOF (sctp ssl)
XFAIL Server closes stdout and keeps running after socket EOF (tcp)
XFAIL Server closes stdout and keeps running after socket EOF (tcp ssl)
PASS Server closes stdout and stops running after socket EOF (sctp)
PASS Server closes stdout and stops running after socket EOF (sctp ssl)
PASS --recv-only server closes stdout and stops running after socket EOF (tcp)
PASS --recv-only server closes stdout and stops running after socket EOF (sctp)
PASS --recv-only server closes stdout and stops running after socket EOF (tcp ssl)
PASS --recv-only server closes stdout and stops running after socket EOF (sctp ssl)

> - 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.

I don't know if this really makes sense. I can see that the current
pending events, you might want to have completed before quitting. But
what if you're reading from an input file and would have queued 10
events, but only 5 of them are queued before you call nsock_loop_finish?
Wouldn't that be just as erroneous?

> - Fix client/server not to call shutdown(..., SHUT_WR) when using SCTP. [1]

I have done this.

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