Re: Receiving broadcasts in Nsock

[David Fifield <david () bamsoftware com>]

On Thu, Sep 30, 2010 at 11:22:18PM +0200, Patrik Karlsson wrote:
> On 30 sep 2010, at 19.55, David Fifield wrote:
>
> > 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.
>
> What prevents those two pieces of information be passed as parameters to the function just like the sockaddr 
> structure is in recvfrom?
> Sorry that I'm not seeing something *really* obvious here.

The sockaddr pointer in recvfrom is an output parameter, not an input
parameter. If you've created a socket with AF_INET, and pass recvfrom a
sockaddr with AF_INET6, it will be overwritten with AF_INET (and the
rest of the sender address) when something is received.

I think I misunderstood you earlier. Of course we can provide functions
that take extra parameters to provide the missing information needed to
create the socket. The functions would check if a socket has been
allocated, and if not, would create it.  Every call would have to
provide the family and protocol just in case the socket needs to be
created. In NSE it would look like this:

s = nmap.new_socket()
status, data, remote = s:recvfrom("ipv4", "udp")
...
status, data, remote = s:recvfrom("ipv4", "udp")

It would either have to be illegal to do a later call with mismatched
parameters (like recvfrom("ipv4", "udp") followed by
recvfrom("ipv6", "udp")), or the functions would have to close and
re-open the socket when that happens.

What I had in mind is to declare the address family and protocol once,
making socket creation explicit. Like this:

s = nmap.new_socket()
s:setup("ipv4", "udp")
status, data, remote = s:recvfrom()
...
status, data, remove = s:recvfrom()

In the same way you use s:connect to make a connected socket, you would
use s:setup to make an unconnected socket. Compare the above to the
typical connected usage:

s = nmap.new_socket()
s:connect("1.2.3.4", 123, "udp")
status, data = s:receive()
...
status, data = s:receive()

I also want to try just using recvfrom all the time internally, so that
the s:recvfrom lines in the second example can be replaced with ordinary
s:receive.

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