Re: [NSE] Changes to dhcp-discover and dhcp.lua

[Daniel Miller <bonsaiviking () gmail com>]

On 12/27/2011 12:51 PM, Patrik Karlsson wrote:
> Hi list,
>
> I noticed some problems with the dhcp-discover script while working on some
> other stuff.
> I tested the script against a bunch of different DHCP servers and noticed
> that I wasn't getting any results.
> The problem was most likely introduced when we re-wrote a bunch of scripts
> to use the unconnected socket code.
> What happens is that the script first sends a unicast DHCPDISCOVER request
> to the server, the server then allocates an IP and sends the response back
> to that new IP.
> The script previously used pcap to pick up that response, as it was not
> addressed to the host running the script.
> When we incorrectly replaced that pcap-code with a listening socket the
> script no longer sees the response.
>
> A while back I implemented a similar script that gets the same information
> by using a broadcast request (broadcast-dhcp-discover) instead of unicast.
> So, instead of putting the old pcap code back in I changed the code to send
> a DHCPINFORM request instead.
> The upside of this change is:
> * it doesn't suffer from the problem that it doesn't see the response
> * it doesn't allocate a new IP for the client
> * it gets the same information as the DHCPDISCOVER request does
>
> The downside is that it doesn't work against all DHCP server
> implementation, according to the old script documentation.
> I've committed this change and some bug fixes and code cleanup in the DHCP
> library as r27661.
> What I would also like to suggest is that we break out the DoS
> functionality in the script to a separate script, maybe dhcp-dos?
> This way we could remove the script from the intrusive category, which
> would be a good thing in my opinion.
>
> Cheers,
> Patrik
I absolutely agree with separating the DoS function into another script. 
Running anything that mentions DoS in my environment brings the wrath of 
management down on me. I would also like to throw in my vote for 
re-supporting as many variations as possible. I think that getting 
information of all kinds from a network is one of Nmap's strengths.

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