mailing list archives
Re: Ncat EOF handling, one-connection listen mode branch
From: Daniel Roethlisberger <daniel () roe ch>
Date: Sun, 7 Jun 2009 00:18:34 +0200
Daniel Roethlisberger <daniel () roe ch> 2009-06-06:
David Fifield <david () bamsoftware com> 2009-06-06:
On Thu, Jun 04, 2009 at 05:27:14PM -0600, David Fifield wrote:
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 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).
I made a branch that implements this.
This version explictly accepts only one client connection in listen
mode. In broker and exec mode, multiple connections are allowed as
Daniel, does this branch work in your use cases?
Yes, it does. Thanks for taking this issue up.
BTW, --ssl is completely broken for me now on OpenSSL 0.9.8e /
FreeBSD 7.2 (server side errors on connect). Known issue?
Sent through the nmap-dev mailing list
Archived at http://SecLists.Org