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

[David Fifield <david () bamsoftware com>]

On Tue, Jun 30, 2009 at 05:27:52PM -0500, Kris Katterjohn wrote:
> David Fifield wrote:
> > On Sat, Jun 27, 2009 at 08:08:37PM -0500, Kris Katterjohn wrote:
> > > 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.
>
> Great!
>
> > 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?
>
> Connect-mode already wouldn't read from the socket if --send-only was used,
> but broker indeed had the same problem (I had just forgotten about it before).
>
> I've attached a patch to have --send-only cause Ncat to not read from the
> socket at all in plain listen and broker modes.

Looks good, please commit it.

> If you're curious, I put the checks for o.sendonly outside of the read_socket
> and read_and_broadcast functions because 1) there's only one invocation of
> them each so there isn't duplicated stuff and 2) while these read* functions
> do more than just read (e.g. broadcasts, etc), it just felt sorta awkward
> putting the checks inside.  It's not a big deal to do it either way though.

That's fine with me. The other things those functions do is dependent on
receiving something first, so there wouldn't be anything for them to do
even if the checks were inside.

David Fifield

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