Re: Receiving broadcasts in Nsock

[David Fifield <david () bamsoftware com>]

On Fri, Oct 01, 2010 at 09:48:14AM +0200, Patrik Karlsson wrote:
> On 1 okt 2010, at 00.32, David Fifield wrote:
>
> > On Thu, Sep 30, 2010 at 11:22:18PM +0200, Patrik Karlsson wrote:
> > > 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.
>
> I didn't think of this.
>
> > 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()
>
> That looks way better!
>
> > 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.
>
> That makes perfect sense and would also make the unconnected socket code very similar to the connected code, which is 
> good.
> If you need help and can give me a few pointers I might be able to help implementing this.

So far I have implemented recvfrom functionality.  Check out
svn://svn.insecure.org/nmap-exp/david/nmap-unconnected.  There's a
prerule script called broadcast.nse that receives a UDP broadcast. I'm
testing it with the command

nping --udp -p 67 255.255.255.255 -c 0 --data-length 20

You have to run Nmap as root to be able to bind.

> I've had a quick look at the code and guess that the nse_nsock_udata could be used by the setup function to store the 
> the family and protocol parameters?

You just pass this information when you create the socket; after that
the OS kernel keeps track of it.

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