Home page logo
/

nmap-dev logo Nmap Development mailing list archives

Re: [PATCH] [Ncat] Fix EOF handling
From: Daniel Roethlisberger <daniel () roe ch>
Date: Sun, 19 Apr 2009 22:56:50 +0200

David Fifield <david () bamsoftware com> 2009-04-19:
On Sun, Apr 19, 2009 at 02:34:21PM +0200, Daniel Roethlisberger wrote:
bensonk () acm wwu edu <bensonk () acm wwu edu> 2009-04-18:
The standard netcat behavior as defined by the canonical
implementation by hobbit explicitly does not halt on EOF.
I would recommend reversing the option, and instead providing
an option like "-q N" in gentoo's netcat.  The "-q N" option
means "after EOF, exit after N seconds". 

I think that, in general, usefulness should supercede history.

I fail to see a use case for keeping running after EOF on the
client side.  If I want Ncat to keep receiving data, I just make
sure not to close Ncat's stdin.  By closing Ncat's stdin (^D on a
tty or close() on the fd in a shell pipe) I signal Ncat that I'm
done.  This is the Unix way of handling standard input/output,
and is what I expect from command line utilities to adhere to, in
order to be useful in constructing larger command pipes.

I have been annoyed that Ncat doesn't quit on EOF from stdin sometimes
too. I had to add a note recommending ctrl+C to
http://nmap.org/ncat/guide/ncat-file-transfer.html. It's not as easy as
with a pipe, though, because pipes are one-way and Ncat can both read
and write its socket.

Do you have a use case that is better served by a -q timer than
proper EOF handling?

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?

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.

It looks like we can't have the default behavior be compatible
with all the other Netcats.

I agree.

Ncat used to have documented a non-functional option --disable-eof-Exit.
It sounds like it was meant to do what the -k option would do. If we go
that route I like the name -k better.

http://seclists.org/nmap-dev/2009/q1/0149.html

David Fifield

-- 
Daniel Roethlisberger
http://daniel.roe.ch/

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


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault