Home page logo
/

nmap-dev logo Nmap Development mailing list archives

Re: Ncat EOF handling, one-connection listen mode branch
From: Daniel Roethlisberger <daniel () roe ch>
Date: Sat, 6 Jun 2009 23:57:49 +0200

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.
      svn://svn.insecure.org/nmap-exp/david/nmap-listen

This version explictly accepts only one client connection in listen
mode. In broker and exec mode, multiple connections are allowed as
before.

Daniel, does this branch work in your use cases?

Yes, it does.  Thanks for taking this issue up.

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