Is there an official way to detect an existing DHCP server?

I'm planning a new feature on our product to support a LAN. Since the installation will be done by relatively non-technical people (it's for boats) I was thinking it would be useful to automatically detect whether we needed to provide a DHCP server or not, depending on one was already on the network. Is there an official way of checking whether there's already a DHCP server (or more than one) on the network?

We use Embedded Linux on the product.

Solution 1:

fedora seems to have the following package in the repos "dhcp_probe"

Description : dhcp_probe attempts to discover DHCP and BootP servers on a directly-attached Ethernet network. A network administrator can use this tool to locate unauthorized DHCP and BootP servers.

Looks like the man dhcp_probe has some good pointers for DHCP discovery strategy that might be worth a look, even if you decided to go for crafting the packets yourself.

PACKET FLAVORS
No single request packet is likely to provoke a response from every possible BootP and DHCP server. Some servers may only response to either BootP, or DHCP, but not both. Some servers may be configured to only respond to a small set of known clients. Some DHCP servers will only provide leases to a small set of known clients, but may be willing to respond (negatively) to unknown clients that request a lease renewal on an inappropriate IP address. Therefore, dhcp_probe actually sends not one, but five different flavor request packets, in the hopes of provoking responses from a wider variety of unknown servers.

$ rpm -qil dhcp_probe
Name        : dhcp_probe
Version     : 1.3.0
Release     : 8.fc15
Architecture: x86_64
Install Date: Mon 30 Apr 2012 12:20:46 AM BST
Group       : System Environment/Daemons
Size        : 133600
License     : GPLv2+ and MIT
Signature   : RSA/SHA256, Thu 28 Jul 2011 11:45:40 AM BST, Key ID 067f00b6a82ba4b7
Source RPM  : dhcp_probe-1.3.0-8.fc15.src.rpm
Build Date  : Tue 08 Feb 2011 01:58:57 PM GMT
Build Host  : x86-18.phx2.fedoraproject.org
Relocations : (not relocatable)
Packager    : Fedora Project
Vendor      : Fedora Project
URL         : http://www.net.princeton.edu/software/dhcp_probe/
Summary     : Tool for discover DHCP and BootP servers
Description :
dhcp_probe attempts to discover DHCP and BootP servers on a directly-attached
Ethernet network. A network administrator can use this tool to locate
unauthorized DHCP and BootP servers.
/etc/dhcp_probe.cf
/etc/rc.d/init.d/dhcp_probe
/usr/sbin/dhcp_probe
/usr/share/doc/dhcp_probe-1.3.0
/usr/share/doc/dhcp_probe-1.3.0/AUTHORS
/usr/share/doc/dhcp_probe-1.3.0/COPYING
/usr/share/doc/dhcp_probe-1.3.0/COPYING.GPL
/usr/share/doc/dhcp_probe-1.3.0/COPYING.LIB
/usr/share/doc/dhcp_probe-1.3.0/NEWS
/usr/share/doc/dhcp_probe-1.3.0/README
/usr/share/doc/dhcp_probe-1.3.0/TODO
/usr/share/man/man5/dhcp_probe.cf.5.gz
/usr/share/man/man8/dhcp_probe.8.gz

Solution 2:

Let's not confuse the word "official" with the concept of "generally accepted method".

One generally accepted method would be to issue a DHCPDiscover packet and look for a response.

Solution 3:

If you have "dhcpcd" installed, you can use the "-T" flag, to get the "test" mode, which just echoes the settings, but does not actually set the IP address and the gateway.

dhcpcd -T

and the output:

emily ~ # dhcpcd -T wlan0
dhcpcd[6205]: version 5.2.12 starting
dhcpcd[6205]: wlan0: broadcasting for a lease
dhcpcd[6205]: wlan0: offered 192.168.2.194 from 192.168.2.1
interface=wlan0
pid=6205
reason=TEST
skip_hooks=lookup-hostname
new_broadcast_address=192.168.2.255
new_dhcp_lease_time=86400
new_dhcp_message_type=2
new_dhcp_server_identifier=192.168.2.1
new_domain_name_servers='192.168.2.1 193.189.160.13 193.189.160.23'
new_ip_address=192.168.2.194
new_network_number=192.168.2.0
new_routers=192.168.2.1
new_subnet_cidr=24
new_subnet_mask=255.255.255.0

Solution 4:

You could do your own DHCPDISCOVER to see if anything out there is configured to answer, but if the DHCP server is locked down to specifics MACS you may not get a response.

You could in theory do a UDP port scan for UDP67 and UDP68, but I'm not so sure that's a great idea as it's more likely to get flagged as possibly malicious behavior.

Generally speaking, products that are not network equipment should not be offering DHCP. It makes an actual sysadmin's job harder, especially if it has a tendency to turn on by default if it loses its settings.

That's one thing that always drove me batty about the old crappy Hawking Ethernet to USB "print server" converter boxes.