Home page logo

nmap-dev logo Nmap Development mailing list archives

Re: [PATCH] [Ncat] Fix EOF handling
From: David Fifield <david () bamsoftware com>
Date: Sun, 7 Jun 2009 21:40:44 -0600

On Tue, Jun 02, 2009 at 01:45:49PM +0200, Daniel Roethlisberger wrote:
David Fifield <david () bamsoftware com> 2009-06-01:
On Sun, Apr 19, 2009 at 10:56:50PM +0200, Daniel Roethlisberger wrote:
David Fifield <david () bamsoftware com> 2009-04-19:
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

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.

This is fairly troubling. Having multiple simultaneous connections is
nice for --sh-exec and connection brokering, but I haven't thought of a
use for it in normal listen mode. If you're doing a file transfer for
example, and someone else starts sending a file to the server at the
same time, the contents of the files will be intermingled:
    ncat -l
    yes a | ncat localhost
    yes bb | ncat localhost
Plus it makes us potentially lose bytes at the end of a stream when
writing to a pipe. I don't mean to suggest this is the only solution,
just the first one I thought of, but what do you think about accepting
only one connection in listen mode without --broker and --exec?

I'd suggest to use your proposed defaults, but still provide
options to override those (e.g. -k --keep-open vs. -K
--no-keep-open or whatever else you like to name them).

That's a good idea. In svn://svn.insecure.org/nmap-exp/david/nmap-listen
I added -k/--keep-open like you suggested. -k doesn't conflict with any
nc or GNU Netcat options. However, I see that a Windows version of
Netcat uses -L ("listen harder") for much the same feature.


There was a request for -L in Ncat, and Kris pointed out that -l already
does that.


But because persistent connections cause some programs to lose the tail
end of transfers, we're thinking of making non-persistent the default. I
think the ncat-listen branch does what we need, but it remains to choose
the user interface. I like -k/--keep-open, but -L (and maybe --Listen?)
has the benefit of a precedent. Does anyone have a preference?

David Fifield

Sent through the nmap-dev mailing list
Archived at http://SecLists.Org

  By Date           By Thread  

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