For proper troubleshooting of DHCP traffic, it may sometimes be necessary to capture live data on your network. There are a lot of ways on how this is accomplished, so I won't go into too much detail on all the methods available, nor will I explain what DHCP does or how it works.

DHCP (Dynamic Host Configuration Protocol) is used for automatic configuration of a host's network settings, such as IP address, gateway, routing, and more. It works by sending broadcasts using IP/UDP on ports 67 (servers) and 68 (clients). For more information on DHCP, read the explanation on Wikipedia.

In order to capture DHCP traffic, we would then have to monitor packets specifically on port 67/udp and 68/udp. As there's no fixed IP address involved in the first stage of a request, we initially can't filter on IP, although we could filter on MAC address if needed.

Using tcpdump

One way of capturing DHCP traffic is by using tcpdump, probably the most used commandline-based network capturing tool.

tcpdump -i eth0 -nvv port 67 or port 68

The command above would capture all DHCP related traffic that arrives on the network interface eth0 of the linux host you're running the command on. If you need to use another interface, change the interface accordingly.

The capturing process will continue to run until it is interrupted with a Ctrl+C.

A lot of output will be produced and this will provide with some info on the DHCP traffic. But more than often, it's not very practical to view the output directly in the console. It would be better to capture the traffic, having it written to file, and then analyze it with more elaborate tools, such as Wireshark. This can also be done with tcpdump, but with slightly altered parameters:

tcpdump -i eth0 -s 2000 -w /tmp/output.pcap -nvv port 67 or port 68

The command above would dump all captured traffic to a file /tmp/output.pcap. We've adjusted the capture size to 2000 bytes to ensure the full packets are captured and written to the file.

When the capture is complete, you can then retrieve the output file and open it with Wireshark or another network analysis tool for further, in-depth analysis.

Using dhcpdump

Another tool usable for troubleshooting DHCP is dhcpdump. This tool was specifically designed for analysis of DHCP traffic and allow for a more direct live analysis of DHCP traffic. DHCP packets will be processed on the fly, and output to the console in a more human-readable format.

While less known/common than tcpdump, it is available in the software repositories of all major linux distros. Its usage is similar to that of tcpdump, making it a versatile, easy-to-use tool for troubleshooting DHCP.

To capture and analyze all DHCP traffic on network interface eth0, run this:

dhcpdump -i eth0

As with tcpdump, adjust the network interface accordingly if you need to monitor another than eth0.

dhcpdump also supports filtering. For instance, if you would only monitor DHCP traffic to/from hosts with a hardware (MAC) address beginning with 00:1a:50, you would run dhcpdump like so:

dhcpdump -i eth0 -h ^00:1a:50

Notice the ^ to indicate the beginning of the line, according to regular expression syntax.

Properly monitoring DHCP

Normally, you would run these commands on a DHCP server itself, but that may not always be possible, for instance, if you're running an appliance or a Windows DHCP server.

A DHCP "session" does not entirely consist of broadcasts. Once a the initial "discovery" has been done, the requesting client and DHCP server will communicate directly, so running the analysis on a host that is not the requesting client or the DHCP will only be able to monitor the broadcasts made by the client. In order to retrieve all data, you either have to figure out a way to run the capture on the requesting client or on the DHCP server itself. Or, if you have managed switches, you could configure them to forward all traffic (or if it can be differentiated on your switch: all DHCP traffic) to the port your "linux monitoring host" is connected to. How to do this, is beyond the scope of this article, and very much vendor-specific.