DHCP DORA Visualizer

After a Wi-Fi client authenticates and finishes the 4-way handshake, it still has no IP address. DORA fixes that: the client broadcasts a Discover, a server Offers an address, the client Requests it, and the server Acknowledges. All four share one transaction ID (xid) so the client knows which reply belongs to which request. Press Play and watch the four messages.

Press ▶ Play to watch the full DORA exchange animate between the client and the DHCP server, or click Next → to step through one message at a time. Each step shows the BOOTP / option field names, what the xid and yiaddr values mean, and the exact failure signature for that message — from a Discover with no Offer to a NAK on Request.

The four DORA messages all carry the same 32-bit transaction ID (xid) in the BOOTP header at offset +4. That is how the client knows an Offer answers its Discover and not some other client's. In a busy capture, correlating by xid — not by MAC — is what lets you say with certainty whether a given Discover was answered.

This matters most when several clients sit behind one MAC (NAT, a Wi-Fi range extender, virtualized hosts): MAC alone cannot tell two simultaneous transactions apart, but the xid can. A Discover whose xid never appears in an Offer is an unanswered Discover, regardless of how many other Offers the same MAC received.

Broadcast flag. A client with no IP cannot receive a unicast reply, so it can set the BOOTP broadcast flag and the server broadcasts the Offer/Ack. Many clients leave the flag clear and accept a unicast reply anyway; behavior is OS-dependent.

Relay (giaddr). When the server is on another subnet, a relay agent (IP helper) sets giaddr and forwards. A Discover with no Offer on a relayed segment often means the helper address is wrong, not that the server is down.

Apple Rapid Commit. RFC 4039 collapses DORA to two messages (Discover + Ack) when both sides support option 80. A two-message exchange is not a failure — check for the Rapid Commit option before flagging a missing Offer/Request.

A user's device shows the Wi-Fi as connected — full bars, the padlock icon — yet nothing loads. People blame the Wi-Fi. The capture tells a different story.

The 802.11 association succeeded and the 4-way handshake completed, so the link layer is fine and frames are encrypted. But the join is not done until the device has an IP, and the capture shows the device broadcasting Discover after Discover with no Offer ever coming back. Layer 2 is healthy; layer 3 never started.

The Discover-with-no-Offer fingerprint points away from Wi-Fi entirely: a dead DHCP server, an exhausted pool, a wrong VLAN assignment, or a broken IP-helper on a relayed segment. The fix is on the wired side, not the AP.

When a device first joins a network it has no IP address, so it cannot send or receive normal traffic. DORA is the conversation that fixes that. The device shouts Discover to the whole segment ("any DHCP servers out there?"). A server answers with an Offer ("here is 192.168.1.100 for you"). The device replies Request ("I accept it") and the server finishes with an Ack ("confirmed, the lease is yours for 24 hours").

The first message is a broadcast because the device does not yet know who the server is, or even its own address. The Discover is sent from 0.0.0.0 to 255.255.255.255. Everything after that can be addressed more directly once the two sides know each other.

Every DORA message carries a 32-bit transaction ID (xid) in the BOOTP fixed header, at offset +4, right after op / htype / hlen / hops. All four messages of one transaction share that xid, which is how a client matches an Offer to the Discover it sent. The message type itself is carried in option 53: 1 Discover, 2 Offer, 3 Request, 5 Ack, 6 NAK.

The offered address lives in the yiaddr ("your IP address") field of the Offer and Ack. In a Discover and Request, yiaddr is 0.0.0.0; the server fills it in. The server identifies itself in option 54 (Server Identifier), and the Request echoes the chosen server there so other servers that also Offered know to release their reservation.

Correlating by xid rather than by client MAC is the precise move. When multiple clients share a MAC — NAT, a range extender, virtualized hosts — the MAC cannot tell two simultaneous transactions apart. The xid can, which is why a per-Discover xid check is the reliable way to assert "this Discover was never answered."

Relay (giaddr). On a routed network the DHCP server is usually not on the client's segment. A relay agent (the "IP helper" on the gateway) receives the broadcast Discover, sets the gateway interface address in giaddr, and unicasts it to the configured server. The server uses giaddr to pick the correct scope and to address its reply back through the relay. A Discover-no-Offer pattern on a relayed segment most often means a missing or wrong helper address, not a dead server — the capture on the client side looks identical either way, which is why the wired-side config check matters.

Rapid Commit (RFC 4039). When the client includes option 80 and the server supports it, DORA collapses to two messages: Discover-with-Rapid-Commit, then Ack. A two-packet exchange is a success, not a truncated DORA — an analyzer must check for the Rapid Commit option before treating a missing Offer/Request as a fault.

Lease timers T1 / T2. After the Ack, the client runs renewal timers: at T1 (default 50% of lease) it unicasts a Request to renew with the same server; at T2 (default 87.5%) it broadcasts to any server (rebinding). A capture full of renewal Requests with no Acks points to a server that handed out the lease and then became unreachable — distinct from an initial Discover failure, and visible by the unicast Request to a specific server identifier.

The Wi-Fi join boundary. DORA is layer 3 and vendor-neutral; it runs identically over Wi-Fi, Ethernet, or a relay. What Wi-Fi adds is a place for it to fail silently: the 802.11 association and EAPOL 4-way can succeed (link encrypted, "connected") while DORA never completes, so the device shows connected with no usable network. Reading the capture in order — auth, assoc, 4-way, then DORA — tells you exactly which layer broke. DHCP is governed by the IETF (RFC 2131 / 2132); the association and handshake before it are governed by IEEE 802.11. Keeping the two straight is half the diagnosis.