mailing list archives
Re: [PATCH] [Ncat] Fix EOF handling
From: David Fifield <david () bamsoftware com>
Date: Thu, 4 Jun 2009 17:27:14 -0600
On Tue, Jun 02, 2009 at 02:43:57PM -0700, Fyodor wrote:
On Mon, Jun 01, 2009 at 06:13:11PM -0600, David Fifield wrote:
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?
Of course we need --chat too (you were probably including that in
--broker) and we may want to keep the current behavior for UDP, unless
you want to quit after the first UDP packet is received. We could add
a multi-connection option for normal listen mode if anyone finds a use
case and asks for it.
I have attached a patch with one possible solution. Instead of allowing
only one connection, it allows multiple, but quits after the last one
I don't know, the more I think about it, the more I think that allowing
only one connection, and then quitting, in listen mode makes sense. That
makes it completely symmetrical with normal connect mode, where you make
one connection and hang on until the remote side closes it (or with
--send-only you can quit early on EOF from stdin).
If we limit it to one connection, then "ncat --listen" would be a mode
of operation quite distinct from "ncat --broker" (currently
ncat_listen.c and ncat_broker.c are very similar, so much so that I have
considered combining them). It would make sense to make --broker a peer
of --listen, not subsidiary to it, and deprecate the --broker --listen
option combination. Also "ncat --listen --exec", with its inetd-like
behavior, would be different code than ordinary "ncat --listen".
I looked through the Ncat guide to see what would be broken by this
change. I found:
ncat -l 5200 --hex-dump vscan.log > /dev/null
Used one listening Ncat to handle multiple connections from -sV.
ncat -l 9 --recv-only > /dev/null
TCP discard server; could be worked around.
yes "chargenchargenchargen" | ncat -l 19 --send-only
chargen server; could be worked around.
Maybe it's time to get rid of the listen mode/connect mode dichotomy. If
--listen is modified to accept only one client, that would leave at
least these "modes," different enough to be essentially separate
ncat # Connect mode. Includes --exec and proxy connections.
ncat --broker # Includes --chat.
ncat --listen --exec # Includes --sh-exec
ncat --listen --proxy-type http
The only difference now is that "ncat --listen" and "ncat --listen
--exec" are combined because they both handle multiple clients.
Sent through the nmap-dev mailing list
Archived at http://SecLists.Org