Re: [PATCH] [Ncat] Fix EOF handling

[David Fifield <david () bamsoftware com>]

On Sun, Apr 19, 2009 at 10:56:50PM +0200, Daniel Roethlisberger wrote:
> David Fifield <david () bamsoftware com> 2009-04-19:
> > In some cases quitting on EOF is the right behavior, as in your
> >     tar cvf - somedir | ncat server 1234
> > But in other cases, staying alive until the remote end closes the
> > connection is correct. Consider
> >     echo -e 'GET / HTTP/1.0\r\n\r\n' | ncat scanme.nmap.org 80
> > With current Ncat you get a web page printed to the screen, and Ncat
> > exits. With the EOF patch, you get nothing (and Ncat exits).
>
> Doh, what an oversight.  So looking only at the client side, we
> have two cases.  In one case, we want Ncat to quit on EOF on
> stdin, since communication is one-way.  In the other case, we
> want to wait for the server to close the connection before we
> quit, since we are interested in the response.  We should be able
> to differentiate the two cases based on the already existing
> --send-only switch.
>
> Would you agree with the following behaviour:
> - when using --send-only, Ncat should close the socket and quit
>   after EOF on stdin, and
> - when not using --send-only, Ncat should always wait on the
>   server to close the connection before quitting?

That sounds very reasonable.

> > So it's hard to pick a good default. The documentation at
> > http://nc110.sourceforge.net/ has not quitting on EOF as a feature:
> >     You may be asking "why not just use telnet to connect to
> >     arbitrary ports?" Valid question, and here are some reasons.
> >     Telnet has the "standard input EOF" problem, so one must
> >     introduce calculated delays in driving scripts to allow network
> >     output to finish.
> > Then there is a -w <secs> option to quit after some period of
> > inactivity.
> >
> > I don't have experience with earliers Netcats so I don't know what's
> > best. I guess my bias would be to leave connections running by default,
> > and add a switch to close on stdin EOF, the reason being that in case of
> > user error it's better to receive extra data than to potentially throw
> > data away.
>
> Current default behaviour actually seems to *loose* data on
> SIGINT because of buffering.  I tried sending an odd number of
> bytes to an Ncat listener piping into hexdump (hd).  The last few
> bytes never made it to hexdump after pressing Ctrl+C.  Same thing
> with other consumers such as tar.

I'll look into that. You're not at all obligated to do this, but it
would help if you could write a failing test for this in
test/ncat-test.pl. Then we can demonstrate when it's fixed and avoid
reintroducing it in the future.

David Fifield

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org