Re: Receiving broadcasts in Nsock

[David Fifield <david () bamsoftware com>]

On Tue, Sep 21, 2010 at 08:38:51PM +0200, Patrik Karlsson wrote:
> 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:
> > > > 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.
>
> 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?

I think that works for sending but not for receiving. A recv or recvfrom
call wouldn't provide enough information (address family and protocol)
to allocate a socket on the fly. I tried implementing this today and ran
into exactly this problem.

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