Re: Receiving broadcasts in Nsock

[David Fifield <david () bamsoftware com>]

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?

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