Troubleshoot DHCPv4 Lease Failures with Wireshark

Wireshark can show where a DHCPv4 address assignment stops: at the client, relay, server, or return path. This guide follows the common Discover, Offer, Request, ACK exchange. It focuses on DHCPv4; DHCPv6 uses different messages and ports.

Capture only an authorized test

Lease renewal can briefly interrupt network access, and packet captures expose MAC addresses, client identifiers, hostnames, and internal addressing. Use a lab or approved client, save captures according to your retention policy, and remove or protect them when the investigation is complete.

01

Choose the Right Capture Point

Plan the Capture

Start on the test client’s access VLAN, before a relay forwards the request. If the request crosses a DHCP relay, a second capture on the server-side segment helps compare what entered and left the relay. Confirm the selected Wi-Fi or Ethernet interface is the one carrying the test traffic.

Optional capture filter for DHCPv4:
udp port 67 or udp port 68

Display filter after capture:
dhcp

❯ Illustrative Output (Results Vary)

Use the broad display filter first; tighten it only after confirming the capture point.

---

02

Capture a Controlled Lease Request

Reproduce

Start capturing, then let a lab client acquire or renew a lease. For a Windows test client, replace Ethernet with the exact adapter name. Do not renew a production adapter if losing its current connection would interrupt important work.

ipconfig /renew "Ethernet"
ipconfig /all

❯ Illustrative Output (Results Vary)

The capture should include the client's DHCP request and any replies visible at this point in the network.

Not every renewal uses the full DORA sequence

A client renewing an existing lease can send a unicast request to its current server. A fresh acquisition more commonly shows the full Discover, Offer, Request, ACK exchange. Interpret the packets you captured; do not treat a missing Discover as proof of a fault if the client is renewing.

---

03

Filter and Group the DHCPv4 Messages

Display Filters

The current Wireshark DHCPv4 dissector uses the dhcp protocol filter. DHCP message type is option 53, exposed as dhcp.option.dhcp. Follow one client hardware address and transaction ID so packets from other clients do not get mixed into the sequence.

dhcp

dhcp.option.dhcp == 1 || dhcp.option.dhcp == 2 ||
dhcp.option.dhcp == 3 || dhcp.option.dhcp == 5

dhcp.hw.mac_addr == aa:bb:cc:dd:ee:ff

❯ Illustrative Output (Results Vary)

1 = Discover   2 = Offer   3 = Request   5 = ACK
Inspect each packet's DHCP Message Type and Transaction ID in Packet Details.

---

04

Trace the Exchange in Time Order

DORA Sequence

Read the Packet List in timestamp order and confirm the client and server messages belong to the same transaction. An Offer may come from more than one server. The Request identifies the selected server; the ACK completes a successful lease assignment.

Client  -> DHCPDISCOVER -> broadcast / relay
Server  -> DHCPOFFER   -> client / relay
Client  -> DHCPREQUEST -> selected server / relay
Server  -> DHCPACK     -> client / relay

❯ Illustrative Output (Results Vary)

Expected for a new lease: Discover, Offer, Request, ACK.
Also note DHCPNAK, duplicate offers, retransmissions, and long response gaps.

---

05

Locate the Missing Message or Wrong Path

Triage

Compare captures at the client and server sides of a relay when available. For relayed requests, inspect the relay agent address (giaddr) and any relay-agent information option. The server uses the relay context to choose a scope; a mismatch can send the request to the wrong scope.

No Discover at client VLAN  -> confirm client action, interface, and capture point.
Discover, no Offer          -> inspect relay path, server logs, scope capacity, and policy.
Offer at server, not client -> compare relay return path, VLAN, and filtering.
Request, no ACK             -> inspect selected server, scope/policy, and server logs.
ACK with wrong settings     -> inspect options 1 (mask), 3 (router), 6 (DNS), 51 (lease).

❯ Illustrative Output (Results Vary)

Use packet evidence from both sides of the relay to distinguish a missing request from a missing reply.

---

06

Confirm the Client's Final Configuration

Validate

Stop the capture, check the client’s assigned address, gateway, DNS servers, and lease, then test the intended application path. Record which exchange packet was missing and the point where you last observed it. A successful ACK proves the DHCP exchange completed, not that a gateway or DNS server is reachable.

ipconfig /all

❯ Illustrative Output (Results Vary)

The lease, subnet mask, default gateway, DNS servers, and lease timing match the intended scope.

Upstream references

Use Wireshark’s current DHCP display filter reference and display filter manual. The Wireshark User’s Guide documents capture and display filters.