pjhtech Tools
Network tools · Network tools

DHCP DORA Troubleshooting: Discover, Offer, Request and ACK

For a new DHCPv4 lease, the familiar DORA exchange is Discover, Offer, Request and Acknowledgment. Troubleshoot the missing stage rather than treating every address failure as a broken DHCP server. Renewals and clients remembering a previous address can follow a different sequence, so not every valid transaction begins with Discover.

Scope: DHCPv4; DHCPv6 uses a different message exchange. Capture filters below apply to IPv4 DHCP.

What each message contributes #

StagePurposeIf the next stage is missing
DiscoverClient looks for a suitable serverTrace client VLAN, relay and server reachability
OfferServer proposes configurationConfirm the offer reaches the client
RequestClient requests the selected configurationInspect server decision and return path
ACKServer confirms the leaseInspect applied address, mask, gateway and DNS

An ACK is not proof that Internet access works. DHCP can successfully deliver an incorrect gateway or DNS setting. Separate obtaining configuration from using that configuration.

Capture the transaction #

Use this capture expression on an authorized client-facing observation point:

Capture the transaction
Network tools · Capture filter / Wireshark display-filter bar as labelled

Read-only
udp port 67 or udp port 68

Wireshark display filters for modern versions:

Capture the transaction
Network tools · Capture filter / Wireshark display-filter bar as labelled

Read-only
dhcp
Read-only
dhcp.option.dhcp == 1
Read-only
dhcp.option.dhcp == 2
Read-only
dhcp.option.dhcp == 3
Read-only
dhcp.option.dhcp == 5
Read-only
dhcp.option.dhcp == 6

The numeric filters select Discover, Offer, Request, ACK and NAK respectively. Correlate the transaction ID and client identity so simultaneous clients do not create a false sequence. Inspect the actual message fields, not just the source IP: a relay changes how traffic is carried between client and server.

Compare two observation points #

If the client sends Discover but the server never sees it, examine the VLAN and relay path. If the server sends Offer but the client never receives it, inspect the return path, filtering and switching controls. If the server sees the request but cannot allocate a lease, examine scope availability, exclusions, reservations and server logs. A capture on only one side cannot settle every branch.

For a routed client subnet, verify the relay information selects the intended scope and that replies can return. Avoid assuming that server-side UDP traffic looks identical to the client broadcast segment. If multiple offers appear, identify all responding servers before declaring one rogue; legitimate designs can include more than one server.

Preserve the failing transaction before releasing addresses or restarting services. Those actions can interrupt remote access and remove useful state. Finish by testing the assigned gateway, DNS and the user's application. Successful DORA resolves the lease-exchange question, not every connectivity question.

Sources

Documentation reviewed: 8 October 2026