Nmap Development mailing list archives
Re: Receiving broadcasts in Nsock
From: David Fifield <david () bamsoftware com>
Date: Thu, 30 Sep 2010 16:32:37 -0600
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/
Current thread:
- Re: Adding new NSE discovered targets to Nmap, (continued)
- Re: Adding new NSE discovered targets to Nmap Patrik Karlsson (Aug 15)
- Re: Adding new NSE discovered targets to Nmap Ron (Aug 15)
- Receiving broadcasts in Nsock David Fifield (Aug 16)
- Re: Receiving broadcasts in Nsock Patrik Karlsson (Aug 16)
- Re: Receiving broadcasts in Nsock Patrik Karlsson (Aug 16)
- Re: Receiving broadcasts in Nsock David Fifield (Sep 17)
- Re: Receiving broadcasts in Nsock David Fifield (Sep 19)
- Re: Receiving broadcasts in Nsock Patrik Karlsson (Sep 21)
- Re: Receiving broadcasts in Nsock David Fifield (Sep 30)
- Re: Receiving broadcasts in Nsock Patrik Karlsson (Sep 30)
- Re: Receiving broadcasts in Nsock David Fifield (Sep 30)
- Re: Adding new NSE discovered targets to Nmap Djalal Harouni (Aug 12)
- Re: Adding new NSE discovered targets to Nmap Djalal Harouni (Aug 31)
- Re: Adding new NSE discovered targets to Nmap David Fifield (Sep 06)
- Re: Adding new NSE discovered targets to Nmap Djalal Harouni (Sep 10)