Re: Receiving broadcasts in Nsock

[David Fifield <david () bamsoftware com>]

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.
   
In short, Nsock does almost everything you want with its
always-connected sockets, which enable a simple API. But there are a few
operations where we want an unconnected socket; i.e., you want to peek
through the Nsock abstraction a little more. Making Nsock fit the
demands of Berkeley sockets could require an API change.

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