2026-06-02

DHCP Failure PCAP Analysis: Discover, Offer, Request, ACK, NAK, and No IP Address Problems

How to troubleshoot DHCP failure, no IP address, DHCP Discover without Offer, DHCP NAK, relay problems, VLAN issues, and packet capture evidence.

“Network not connected” and a self-assigned 169.254 address hide several distinct DHCP failures. Follow the client from Discover through Offer, Request, ACK or NAK, checking transaction IDs, broadcast domains, relay fields, requested address, and server identity; “DHCP Discover, no Offer” is different from a server that explicitly sends a DHCP NAK. The PCAP can show which messages reached the capture point, but an absent reply cannot identify a switch, relay, firewall, or exhausted scope without evidence from that component.

DHCP is easy to understand when the four-message flow is visible. It is hard to guess when only the client error is visible. PCAP Surgery helps isolate the DHCP exchange while preserving broadcast traffic, relay fields, options, and timing.

Healthy DHCP flow

A typical IPv4 DHCP flow:

Client -> Broadcast: DHCP Discover
Server -> Client/Broadcast: DHCP Offer
Client -> Broadcast: DHCP Request
Server -> Client/Broadcast: DHCP ACK

If the client receives ACK, it can configure IP address, subnet mask, router, DNS, lease time, and other options.

Discover but no Offer

If the capture shows Discover messages but no Offer, likely causes include:

DHCP server unreachable.
VLAN mismatch.
Relay not configured.
Switch port isolation.
DHCP snooping policy.
Server scope exhausted.
Firewall blocks broadcast/relay traffic.
Client is on the wrong network.

Capture location matters. If you capture on the client and see Discover leave but no Offer return, you still need to know whether the server received it.

Offer but no Request

If Offer appears but the client never sends Request, the client may reject the offer due to options, wrong network, duplicate address detection, or client policy.

Inspect:

Offered IP.
Server identifier.
Subnet mask.
Router option.
Lease time.
Vendor-specific options.

NAK

DHCP NAK means the server rejects the client's requested address or lease state. This often happens after moving between networks or VLANs.

Look for:

Client requests old IP.
Server sends NAK.
Client restarts discovery.
Repeated NAK loop.

The fix may be normal lease renewal behavior, but repeated NAKs indicate configuration or network mismatch.

Relay and VLAN problems

In routed networks, DHCP relay forwards client requests to a server. The giaddr field and relay information options matter. If relay is missing or wrong, the server may not know which scope to use.

Preserve DHCP options when trimming a capture. Removing them destroys the evidence.

Checklist

Use this workflow:

Capture from link-up or device boot.
Filter DHCP/BOOTP traffic.
Determine which messages appear: Discover, Offer, Request, ACK, NAK.
Inspect transaction IDs.
Check offered address and options.
Check server identifier.
Check relay fields and VLAN context.
Look for repeated retries and timing.
Compare client-side and server-side captures if needed.
Preserve full DHCP options.

Final diagnosis

DHCP failure is not just "no IP." The packet evidence shows whether the client asked, server answered, client accepted, server acknowledged, server rejected, or relay/VLAN prevented the exchange.

PCAP Surgery helps reduce noisy boot captures into the exact DHCP sequence needed to prove why the device did not get an address.

Read a DHCP failure PCAP as a state transition, not a packet list

The same client symptom—no address or a 169.254 address—can appear at several different positions in the DHCP state machine. The diagnostic value of a PCAP comes from identifying the last successful transition and the first missing or contradictory one. A capture with a Discover and no Offer is materially different from an Offer that the client never requests, an ACK that never reaches the client, or a NAK loop after the client moves networks.

Last verified event	Next event expected	What absence or contradiction suggests	Evidence needed before naming a cause
Link becomes available	Client sends Discover	Client service, adapter, or capture placement issue	Link/adapter context and a capture beginning before the attempt.
Discover reaches capture point	Offer returns	Server path, relay, scope, VLAN, policy, or return-path issue	A second capture or logs on the relay/server-side boundary.
Offer reaches client	Client sends Request	Client rejected or did not process the offer	Offered options, requested address, client event context, and transaction ID.
Request is visible	ACK or NAK returns	Server decision, relay return path, or response loss	Server identifier, requested IP, giaddr/options, and a server-side view if possible.
ACK reaches client	Client configures address	Local stack, duplicate detection, policy, or later network issue	Client event logs and configuration state; DHCP alone may be healthy.
NAK reaches client	New Discover begins	Old lease/request does not match current network or policy	Requested IP, server scope, VLAN/relay context, and retry pattern.

The table is also a guard against an overconfident finding. Seeing no Offer on a laptop capture proves that no Offer reached that laptop capture point. It does not independently prove that a DHCP server has no free addresses, that a switch dropped the broadcast, or that a relay was never configured. Each of those may be plausible; only additional evidence distinguishes them.

A DHCP capture workflow that survives escalation

Capture from before the attempt. Start before cable connection, Wi-Fi association, device boot, or lease renewal. A trace that begins after the initial Discover often turns a normal retry into a misleading first event.
Preserve the client identity. Record the MAC address, client identifier if present, interface, VLAN/SSID context, and device time. DHCP is broadcast-heavy; without identity it is easy to follow another device's transaction.
Group packets by transaction ID. The xid ties Discover, Offer, Request, and ACK/NAK together. Reused or overlapping traffic from several clients can otherwise make a healthy exchange look like a broken one.
Keep the options. Requested address, server identifier, subnet mask, router, DNS, lease time, Option 82 relay information, and vendor/class identifiers can be the actual reason a server selects, rejects, or misroutes a request. Trimming packet payloads destroys that evidence.
Measure retries and time. Count retransmissions, note the interval between them, and separate a slow answer from no answer. A client may retry because it did not see a reply even though a server emitted one elsewhere in the network.
Add a second observation point when needed. Capture near the relay, server, or routed boundary only after the client-side trace states the question. For example: “Did the Discover with this xid leave VLAN 120?” is a testable question; “Why does DHCP not work?” is not.

PCAP Surgery is useful when a boot capture contains ARP, DNS, service discovery, and application traffic in addition to DHCP. The goal is to preserve a bounded evidence window: the relevant DHCP transaction, its options, timing, and enough adjacent network context to explain the capture point. The capture scope guide explains how to define that window, and the PCAP evidence preservation guide explains why time and packet order must remain trustworthy during export.

Common DHCP patterns and the next test

Discover is sent repeatedly and no Offer appears

Check whether the capture is on the client, a switch span, or a routed segment. On the client, the immediate evidence is simply that no Offer returned. Inspect VLAN assignment, DHCP snooping or port policy, relay configuration, scope reachability, and server logs with the transaction ID and client MAC. If a relay is involved, giaddr and relay information options help prove which scope the server should select.

Offer appears, but the client does not request it

Do not assume the server is correct merely because it made an Offer. Compare the offered address, server identifier, subnet mask, router, lease duration, and any required vendor options with a working client on the same intended network. The client may reject an offer, have local policy constraints, or be reacting to a duplicate-address or adapter condition outside the DHCP packets themselves.

Request receives a NAK after a network move

A NAK can be a normal correction when a device asks to renew an address valid on a previous VLAN or site. The important distinction is whether the client restarts discovery and obtains a correct lease, or whether it enters a repeating NAK/no-address loop. Preserve the old requested IP, the current relay/VLAN context, and the server identifier rather than writing only “DHCP server rejected client.”

ACK exists, but the device still reports no network

The DHCP exchange may be successful. Confirm that the ACK reaches the client and contains the expected configuration, then move the investigation to client application, duplicate address detection, route/DNS use, or a later connectivity failure. A clean DHCP ACK should not be discarded, but it should not be stretched into proof that every network service is healthy.

Questions support teams should answer in a DHCP case

Which side needs to provide the next evidence?

Let the last observed state decide. If the client saw only Discover, the network or server side needs to account for the request. If the server emitted an ACK that the client never saw, the return path or capture position becomes important. If the client received an ACK, the client/device side should explain why it did not configure or use it. This keeps escalation targeted and avoids asking every team for every log.

Is a DHCP NAK always a configuration error?

No. It can be a normal instruction to abandon an old lease after a network change. It becomes a problem when it repeats unexpectedly, points to the wrong scope, or prevents the client from obtaining a new lease. The sequence after the NAK is as important as the NAK itself.

How much of the PCAP should we share?

Share the minimum window that includes the client action, the complete relevant DHCP transaction, the surrounding retry timing, and required relay/options. Retain the original evidence according to your incident process. A small, complete case is easier for another team to review than an unbounded boot capture with the critical packets buried inside it.

The final diagnosis should name the observable boundary first—“Discover leaves client; no Offer returns,” “Offer is rejected before Request,” or “ACK reaches client but configuration does not complete”—and then list the next evidence needed for a root cause. That makes a DHCP no-IP report useful to network, server, and device teams without claiming more than the PCAP proves.

Related guides

Continue with the same-language pages below. They cover adjacent stages without changing the canonical owner of this topic: