Re: Receiving broadcasts in Nsock

[Patrik Karlsson <patrik () cqure net>]

On 20 sep 2010, at 07.07, David Fifield wrote:

> On Fri, Sep 17, 2010 at 08:42:28PM -0700, David Fifield wrote:
> > On Mon, Aug 16, 2010 at 03:33:59PM -0600, David Fifield wrote:
> > > On Sun, Aug 15, 2010 at 10:40:58PM +0200, Patrik Karlsson wrote:
> > > > On 13 aug 2010, at 17.40, Daniel Miller wrote:
> > > > So I looked into this a bit more as I was curios to test some new ideas out. 
> > > > I managed to make the setbroadcast call and have my NSE code send
> > > > broadcasts out.
> > > > However, I ran into some trouble as all UDP sockets are connected to
> > > > the destination address.
> > >
> > > I investigated this last year, and determined that the problem was that
> > > in Nsock, there is no way to create a socket without also connecting it.
> > > The underlying call to socket isn't made until nsock_connect_internal is
> > > called, which is later than when nsi_new is called. I posted an example
> > > that works in Python but not in NSE here:
> > >
> > > http://seclists.org/nmap-dev/2009/q4/105
> > >
> > > Normally you would do new_socket, bind, receive. This doesn't work in
> > > NSE because when you do the receive you don't have a real socket yet;
> > > creating a socket by doing a connect first somehow prevents the receive
> > > from working.
> > >
> > > My recommendation then was to create a real socket at the time of
> > > nsi_new.
> >
> > I started trying to implement this but ran into a problem. At the time
> > of nsi_new, we don't know the address family or protocol to pass to the
> > socket call. That only comes at the time of nsock_connect_tcp,
> > nsock_connect_udp, or similar. There's no corresponding nsi_new_tcp (for
> > example) which would allow us to declare the protocol in advance (and
> > even then there has to be a way to get the address family).
> >
> > Here are some ideas I've had:
> > 1. Force the address family and protocol to be declared when an iod is
> >   created. For example,
> >     nsi_new(pool, userdata, AF_INET, IPPROTO_TCP)
> >   or
> >     nsi_new_tcp(pool, userdata, AF_INET).
> >   Declaring the protocol in advance is not too bad, but I don't like
> >   having to do that with the address family. One of the nice things
> >   about Nsock is that you don't have to do that until you connect. This
> >   method does have the nice feature that every iod is guaranteed to
> >   have a socket, which unifies iods created with nsi_new and nsi_new2.
> > 2. Provide functions to create a socket on an iod without making a
> >   connection. For example,
> >     nsi_setup_tcp(AF_INET)
> >     nsi_setup_udp(AF_INET)
> >     nsi_setup_sctp(AF_INET)
> >   The various nsock_connect_* functions would call the appropriate
> >   setup function and then make a connection. This is less orthogonal
> >   than number 1. The tcp and sctp variants might not be necessary
> >   because you can't do much with one of those sockets that's not
> >   connected. NSE would provide a wrapper to these functions to allow
> >   you to say, "I want to be able to send and receive with this address
> >   family and protocol, but I don't want to make a connection."
> > 3. Keep the same API we have now, but transparently create a socket when
> >   the user tries to read or write on an unconnected socket. We might
> >   not always have the information needed to do this. If someone has
> >   done nsi_set_localaddr (socket:bind in NSE), we could get the
> >   information from that.
>
> Another option is to add a UDP-specific function call to create a socket
> on the iod without connecting it. This is ugly and non-orthogonal, but
> it also answers the only use case we're likely to have for a while.
>
> Does anyone have comments on these ideas?

The simplicity of socket programming in Nmap is one of the things I really like a lot.
So, if option number 3 would be doable I would definitely vote for that.

Seeing from the NSE side rather than from the nsock side which I'm less familiar with, something similar to the sendto 
function would probably need to be added.
If this would be the case, wouldn't adding a function like eg. sendto( host, port, protocol, data ) give you all the 
necessary information for option number 3?

//Patrik


> David Fifield
> _______________________________________________
> Sent through the nmap-dev mailing list
> http://cgi.insecure.org/mailman/listinfo/nmap-dev
> Archived at http://seclists.org/nmap-dev/

--
Patrik Karlsson
http://www.cqure.net
http://www.twitter.com/nevdull77





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