Re: ncat udp

[David Fifield <david () bamsoftware com>]

On Thu, Mar 26, 2009 at 11:54:57AM +0100, Marius Sturm wrote:
> thanks for your comments. I followed your suggestions and the patch
> looks much cleaner now.

Thanks a lot! It works great. The --exec and --sh-exec options now work
in UDP mode like they do in TCP mode. The server accepts multiple
concurrent connections and forks off a handler for each of them. I
removed all the while loops from the examples in
http://nmap.org/ncat/guide/ncat-simple-services.html.

Now that we allow multiple connections, could you implement the
--max-conns option in ncat_listen_udp? It just involves updating and
checking the conn_count variable like in ncat_listen_tcp.

The only remaining difference is UDP is listen mode without an exec
option. That still only accepts one client. Making that work like TCP
mode will be more difficult because we will have to maintain a list of
connected clients and somehow decide when to remove a client from the
list.

> Only two points, should the ncat client be terminated after receiving a
> datagram like in tcp mode?

No, because the server may have more than one datagram to send:

ncat -l --udp --sh-exec "echo one; sleep 1; echo two"

I think it's okay to leave clients hanging; that's just the nature of
UDP.

> And, should --send-only/--recv-only effect the --exec option?

Hmm, I hadn't thought of that. The diagnostic service examples use those
options but they don't actually have an effect with an executed command.
With TCP (maybe UDP too?) we could shutdown one direction of the socket
before handing it to the subprogram. However --send-only and --recv-only
don't work like that in other parts of Ncat. --send-only actually does
recv data, it just doesn't write it to standard output. Likewise
--recv-only reads from standard input, it just doesn't send what it
reads. I don't know if that's the correct behavior or not.

David Fifield

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