Self-Hosted DHCP Debugging Tools: dhcping vs dhcpdump vs dhcp-probe

Introduction

When a client fails to obtain an IP address from your DHCP server, the troubleshooting surface is deceptively large: Is the server reachable? Is it responding? Is the response malformed? Are rogue DHCP servers interfering? Three specialized command-line tools — dhcping, dhcpdump, and dhcp-probe — each address a different layer of the DHCP diagnostic stack, from active probing to passive capture to network-wide discovery.

This guide compares these three diagnostic tools, providing practical workflows for resolving common DHCP issues in self-hosted environments.

Feature Comparison

dhcping — Active DHCP Server Health Check

dhcping sends a real DHCP request to a specific server and validates the response. It is the DHCP equivalent of a ping or HTTP health check — ideal for monitoring scripts, Nagios/Icinga plugins, and automated alerting.

Installation

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

# Debian/Ubuntu
sudo apt install dhcping

# RHEL/CentOS/Fedora (from EPEL)
sudo dnf install epel-release
sudo dnf install dhcping

# Arch Linux
sudo pacman -S dhcping

# Build from source
git clone https://github.com/bbonev/dhcping.git
cd dhcping && make && sudo make install

Usage Examples

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

# Check if a DHCP server responds
dhcping -s 192.168.1.1

# Send a specific request type (INFORM vs DISCOVER)
dhcping -s 192.168.1.1 -t inform

# Specify client MAC address for the request
dhcping -s 192.168.1.1 -c 00:11:22:33:44:55

# Set a timeout (in seconds)
dhcping -s 192.168.1.1 -t 5

# Request a specific IP address (DHCPREQUEST for an existing lease)
dhcping -s 192.168.1.1 -r 192.168.1.100

# Use in a monitoring script
if dhcping -s 192.168.1.1 -t 3 -q; then
    echo "DHCP server is healthy"
else
    echo "DHCP server is DOWN!"
    # Trigger alert
fi

Interpreting Exit Codes

dhcpdump — Passive DHCP Traffic Decoder

dhcpdump captures DHCP packets from the wire and decodes every field in a human-readable format. It leverages libpcap (the same library tcpdump uses) and displays the full contents of DHCP DISCOVER, OFFER, REQUEST, ACK, NAK, and other message types. Think of it as tcpdump specialized for DHCP — you see the raw conversation between client and server.

Installation

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# Debian/Ubuntu
sudo apt install dhcpdump

# RHEL/CentOS/Fedora (from EPEL)
sudo dnf install dhcpdump

# Arch Linux
sudo pacman -S dhcpdump

# Build from source
git clone https://github.com/dhcpdump-org/dhcpdump.git
cd dhcpdump && make && sudo make install

Usage Examples

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# Capture and decode all DHCP traffic on eth0
sudo dhcpdump -i eth0

# Filter by MAC address
sudo dhcpdump -i eth0 | grep -A20 "11:22:33:44:55:66"

# Capture client-server exchange during a lease renewal
# Terminal 1: Start capture
sudo dhcpdump -i eth0 -n

# Terminal 2: Trigger renewal
sudo dhclient -r eth0 && sudo dhclient eth0

Sample Output Analysis

A typical dhcpdump output shows the full DHCP conversation structure:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

  TIME: 2026-06-01 10:15:23.456
    IP: 0.0.0.0 (0:11:22:33:44:55) > 255.255.255.255 (ff:ff:ff:ff:ff:ff)
    OP: 1 (BOOTREQUEST)
  HTYPE: 1 (Ethernet)
   HLEN: 6
   HOPS: 0
    XID: a1b2c3d4
   FLAG: 0
 OPTION:  53 (  1) DHCP message type         5 (DHCPACK)
 OPTION:  54 (  4) Server identifier         192.168.1.1
 OPTION:  51 (  4) IP address leasetime      86400 (24h)
 OPTION:   1 (  4) Subnet mask                255.255.255.0
 OPTION:   3 (  4) Routers                    192.168.1.1
 OPTION:   6 (  8) DNS server                 8.8.8.8,1.1.1.1

This level of detail lets you verify that the correct DNS servers are being distributed, lease times match your policy, and no unexpected options are present.

dhcp-probe — Rogue DHCP Server Discovery

dhcp-probe broadcasts DHCPDISCOVER packets and collects responses from ALL DHCP servers on the network segment — not just the one you expect. It is the go-to tool for detecting unauthorized (rogue) DHCP servers that could be handing out incorrect IP addresses or intercepting traffic.

Installation

1
2
3
4
5
6

# Debian/Ubuntu
sudo apt install dhcp-probe

# Build from source (recommended for latest version)
git clone https://github.com/shuque/dhcp-probe.git
cd dhcp-probe && ./configure && make && sudo make install

Usage Examples

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# Scan for all DHCP servers on the network
sudo dhcp-probe -i eth0

# Verbose output showing full server responses
sudo dhcp-probe -v -i eth0

# Scan a specific set of networks (CIDR notation)
sudo dhcp-probe -i eth0 -n 192.168.0.0/16,10.0.0.0/8

# Send multiple probes for reliability
sudo dhcp-probe -i eth0 -c 3

Sample Output

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

DHCP Probe running on interface eth0
Listening for responses...
Received response from 192.168.1.1 (authoritative)
  Server Identifier: 192.168.1.1
  Offered: 192.168.1.150
  Subnet Mask: 255.255.255.0
  Lease Time: 86400 seconds

Received response from 192.168.1.99 (rogue!)
  Server Identifier: 192.168.1.99
  Offered: 192.168.50.10
  Subnet Mask: 255.255.255.0
  !! WARNING: Unauthorized DHCP server detected !!

Diagnostic Workflow

Here is a systematic approach to DHCP troubleshooting combining all three tools:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

# Step 1: Discover all DHCP servers on the network
sudo dhcp-probe -i eth0 -v
# If you see servers you don't recognize → rogue DHCP server issue

# Step 2: Verify your intended server responds
dhcping -s 192.168.1.1 -t 5
# Exit code 0 → server is alive and responding correctly

# Step 3: Capture a full exchange to diagnose option issues
sudo dhcpdump -i eth0 &
sudo dhclient -r eth0 && sudo dhclient eth0
sleep 5 && sudo killall dhcpdump
# Inspect the output for incorrect DNS, gateway, or subnet mask

Why Self-Host Your DHCP Diagnostics

DHCP failures are network-stopping events — when clients cannot obtain IP addresses, everything from web browsing to SSH access fails. Cloud-based monitoring tools cannot help during a DHCP outage because they are unreachable. Having these diagnostic tools installed locally means you can troubleshoot even when the network is down.

For managing the DHCP server infrastructure itself, see our Kea DHCP server management guide. If DNS resolution is also affected, our DNS debugging tools comparison covers complementary DNS-level diagnostics. For IP address allocation tracking across your infrastructure, our IPAM comparison guide helps you maintain accurate records of address utilization.

Together, these tools provide complete DHCP visibility: server discovery (dhcp-probe), health monitoring (dhcping), and protocol-level debugging (dhcpdump).

FAQ

What is the difference between dhcping and simply pinging the DHCP server?

Pinging a DHCP server with ICMP only confirms that the host is alive at the IP layer — it does not verify that the DHCP service is running and responding correctly. The DHCP daemon could be crashed while the kernel still responds to pings. dhcping sends actual DHCP protocol messages and validates the response structure, providing application-layer health verification that a simple ICMP ping cannot.

Can dhcpdump capture DHCPv6 traffic?

Yes, most modern builds of dhcpdump support DHCPv6 capture. Use dhcpdump -i eth0 and it will automatically decode both DHCPv4 and DHCPv6 packets. DHCPv6 uses different message types (SOLICIT, ADVERTISE, REQUEST, REPLY instead of DISCOVER, OFFER, REQUEST, ACK) and uses multicast addresses (ff02::1:2) instead of IPv4 broadcast, but dhcpdump handles both transparently.

How do I run dhcpdump as a non-root user?

DHCP traffic uses privileged ports and raw sockets, so dhcpdump normally requires root. However, you can grant a specific user packet capture capabilities: sudo setcap cap_net_raw,cap_net_admin=eip /usr/sbin/dhcpdump. Alternatively, add your user to the pcap group if your distribution creates one. For systemd-based monitoring, create a service unit that runs dhcpdump as a dedicated unprivileged user with AmbientCapabilities=CAP_NET_RAW CAP_NET_ADMIN.

What should I do if dhcp-probe finds a rogue DHCP server?

First, identify the physical switch port by checking the MAC address against your switch’s MAC address table (show mac address-table on Cisco, bridge fdb show on Linux bridges). Disable the port immediately to contain the rogue server. Then investigate: is it a misconfigured consumer router someone plugged in, or a deliberate attack? For persistent monitoring, consider deploying dhcp-probe as a cron job or systemd timer that alerts on unexpected DHCP servers.

Why would I use all three tools instead of just Wireshark?

Wireshark is a full-featured GUI protocol analyzer, but it requires a graphical environment, is not scriptable for monitoring, and cannot actively probe DHCP servers. dhcping integrates with monitoring systems (Nagios, Icinga, Prometheus exporters) via exit codes. dhcpdump provides targeted DHCP-only output without the noise of filtering through full packet captures. dhcp-probe performs active discovery that passive capture alone cannot. For headless servers and automated monitoring, these three CLI tools are more practical than a GUI analyzer.

💰 想测试你的市场判断力？我用 Polymarket 做预测市场交易——这是全球最大的预测市场平台，从大选结果到 科技政策监管时间线，什么都可以押注。和赌博不同，这是真正的信息市场：你懂的信息越多，胜率越高。我靠预测 科技行业的发展趋势已经赚了不少。用我的邀请链接注册：Polymarket.com