Re: [PATCH] "ncat -l --send-only" not sending only

[David Fifield <david () bamsoftware com>]

On Sat, Jun 27, 2009 at 08:08:37PM -0500, Kris Katterjohn wrote:
> I found (what I consider to be) an oddity in server-mode --send-only in Ncat.
>
> I was messing with TCP RX/TX queues on my Linux box earlier, for no real
> reason other than just to play around.  At one point I wanted to 1) have a
> server accept connections but not read any data, 2) have a client send a lot
> of data to that server, and 3) view netstat output to see the amount of data
> in the server's RX queue and in the client's TX queue.
>
> Looks like #1 and #2 are areas for Ncat to shine!
>
> I figured that -l --send-only will make the server do pretty much nothing but
> accept connections, since I won't be sending anything from it.
>
> It turns out that Ncat will actually read in the data, it just won't write it
> to stdout or log it.  That makes Ncat's option a bit of a misnomer since it
> does everything it normally would, except pass the data to the user--which is
> very different from sending only.
>
> I created one patch to simply make Ncat behave like Netcat6 (which I think it
> should do).  But I figured having a choice in the matter is a lot better
> (since I seem to often have opinions on how things should behave which are
> different than that of many list members), which lead me to my current patch
> (attached) against the dev branch.  With this patch, --send-only's behavior
> does not change; however, you can now use the new --send-only=force to make it
> actually only send (or more specifically, not receive).

I think that --send-only should work like the proposed
--send-only=force. It should do what its name suggests, and doing it
that way will probably simplify some code.

The only thing is that I'm pretty sure connect and broker modes work the
same way. Can you make another patch that makes --send-only work like
Netcat6, with changes for connect and broker modes too?

David Fifield

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org