DHCP is a surprisingly fragile dance, and when it breaks, the whole network grinds to a halt.

Here’s how to watch the whole thing unfold with tcpdump, from the initial discovery to the final acknowledgment.

sudo tcpdump -i eth0 'udp port 67 or udp port 68' -v

This command tells tcpdump to listen on your network interface (eth0 in this case – change it to your actual interface) for any UDP traffic on ports 67 or 68, which are the standard ports for DHCP. The -v flag gives you more verbose output, which is crucial for deciphering the DHCP messages.

Let’s break down what you’ll see, message by message.

Discover

When a client (like a new laptop or a virtual machine) boots up and needs an IP address, it shouts into the network: "Hey, is there a DHCP server out there?" This is the DHCP Discover message.

You’ll see something like this:

14:35:01.123456 IP (tos 0x0, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328) 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Discover, length 300, xid: 0x12345678, Flags [none] (0x0000), secs: 0, HELLO-TIMEOUT (120s)
          Client-Ethernet-Address: aa:bb:cc:dd:ee:ff
          SIADDR: 0.0.0.0
          GIADDR: 0.0.0.0
          CHADDR: aa:bb:cc:dd:ee:ff
          Magic Cookie 0x63825363
          DHCP-Option: (255) End
  • 0.0.0.0.68 > 255.255.255.255.67: The client (source IP 0.0.0.0 because it doesn’t have one yet) is broadcasting to the DHCP server port (67) on the network broadcast address (255.255.255.255).
  • BOOTP/DHCP, Discover: This confirms it’s a DHCP Discover message.
  • Client-Ethernet-Address: aa:bb:cc:dd:ee:ff: This is the MAC address of the client that sent the request. This is how the DHCP server identifies the client.
  • GIADDR: 0.0.0.0: The Gateway IP Address is 0.0.0.0, meaning this discover is happening directly on the same subnet as the DHCP server, or there’s no relay agent involved.

Offer

A DHCP server that hears the Discover message and has an available IP address from its pool will respond with a DHCP Offer. It’s saying, "Okay, I have this IP address for you."

You’ll see something like:

14:35:01.234567 IP (tos 0x0, ttl 128, id 1234, offset 0, flags [none], proto UDP (17), length 310) 192.168.1.1.67 > 255.255.255.255.68: BOOTP/DHCP, Offer, length 282, xid: 0x12345678, secs: 12
          SIADDR: 192.168.1.1 (server IP)
          GIADDR: 0.0.0.0
          CHADDR: aa:bb:cc:dd:ee:ff
          Magic Cookie 0x63825363
          DHCP-Option: (53) DHCP Message Type: Offer (2)
          DHCP-Option: (1) Netmask: 255.255.255.0
          DHCP-Option: (51) Lease Time: 86400 (1 day)
          DHCP-Option: (3) Router: 192.168.1.1
          DHCP-Option: (6) DNS: 8.8.8.8, 8.8.4.4
          DHCP-Option: (255) End
  • 192.168.1.1.67 > 255.255.255.255.68: The DHCP server (its own IP is 192.168.1.1) is sending an Offer back to the client (using its MAC address, broadcast on port 68).
  • BOOTP/DHCP, Offer: This is the Offer message.
  • xid: 0x12345678: The transaction ID matches the Discover message, so the client knows this Offer is for it.
  • SIADDR: 192.168.1.1: The server’s IP address.
  • DHCP-Option: (1) Netmask: 255.255.255.0: The subnet mask.
  • DHCP-Option: (51) Lease Time: 86400: How long the IP address is valid for.
  • DHCP-Option: (3) Router: 192.168.1.1: The default gateway.
  • DHCP-Option: (6) DNS: 8.8.8.8, 8.8.4.4: The DNS servers the client should use.

A client might receive multiple Offers from different DHCP servers. It will pick one (usually the first one it receives) and proceed.

Request

Once the client accepts an Offer, it broadcasts a DHCP Request message. This tells the chosen DHCP server, "Yes, I want that IP address you offered," and it also informs other DHCP servers that it has accepted another offer and they can retract theirs.

You’ll see:

14:35:01.345678 IP (tos 0x0, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328) 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request, length 300, xid: 0x12345678, Flags [none] (0x0000), secs: 0, HELLO-TIMEOUT (120s)
          Client-Ethernet-Address: aa:bb:cc:dd:ee:ff
          Requested-IP-Address: 192.168.1.100
          SIADDR: 0.0.0.0
          GIADDR: 0.0.0.0
          CHADDR: aa:bb:cc:dd:ee:ff
          Magic Cookie 0x63825363
          DHCP-Option: (53) DHCP Message Type: Request (3)
          DHCP-Option: (50) Requested IP Address: 192.168.1.100
          DHCP-Option: (61) Client-ID: MAC AA:BB:CC:DD:EE:FF
          DHCP-Option: (255) End
  • 0.0.0.0.68 > 255.255.255.255.67: The client is broadcasting its request.
  • BOOTP/DHCP, Request: This is the Request message.
  • xid: 0x12345678: Again, the matching transaction ID.
  • Requested-IP-Address: 192.168.1.100: The specific IP address the client is requesting.
  • DHCP-Option: (50) Requested IP Address: 192.168.1.100: Explicitly states the requested IP.
  • DHCP-Option: (61) Client-ID: MAC AA:BB:CC:DD:EE:FF: The client’s MAC address, often sent as a Client-ID option for more robust identification.

ACK (Acknowledge)

Finally, the DHCP server that offered the IP address confirms the lease with a DHCP ACK (Acknowledge) message. This is the final confirmation that the client has been assigned the IP address, along with all the other configuration parameters.

You’ll see:

14:35:01.456789 IP (tos 0x0, ttl 128, id 4567, offset 0, flags [none], proto UDP (17), length 310) 192.168.1.1.67 > 255.255.255.255.68: BOOTP/DHCP, ACK, length 282, xid: 0x12345678, secs: 13
          SIADDR: 192.168.1.1 (server IP)
          GIADDR: 0.0.0.0
          CHADDR: aa:bb:cc:dd:ee:ff
          Magic Cookie 0x63825363
          DHCP-Option: (53) DHCP Message Type: ACK (5)
          DHCP-Option: (1) Netmask: 255.255.255.0
          DHCP-Option: (51) Lease Time: 86400 (1 day)
          DHCP-Option: (3) Router: 192.168.1.1
          DHCP-Option: (6) DNS: 8.8.8.8, 8.8.4.4
          DHCP-Option: (255) End
  • 192.168.1.1.67 > 255.255.255.255.68: The server sending the ACK.
  • BOOTP/DHCP, ACK: The acknowledgment message.
  • xid: 0x12345678: The matching transaction ID.
  • DHCP-Option: (53) DHCP Message Type: ACK (5): This is the final confirmation.

Once the client receives the ACK, it configures its network interface with the assigned IP address and other parameters. The DHCP transaction is complete.

The next step after successfully obtaining an IP address is usually for the client to test its connectivity, often by sending an ARP request for its newly assigned IP address to ensure no other host is already using it (this is part of the DAD - Duplicate Address Detection process, though DHCP itself doesn’t mandate this step, it’s a common client behavior).

Want structured learning?

Take the full Tcpdump course →