Re: [PATCH] [Ncat] Fix EOF handling

[David Fifield <david () bamsoftware com>]

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

http://osdir.com/ml/os.apple.macports.user/2007-07/msg00072.html

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

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

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
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org