ARP Dead Window
The most common "connected but no internet" failure mode in Wi-Fi networks has nothing to do with RF, authentication, or DHCP. It is a timing gap in the ARP protocol between when a client associates and when the gateway updates its ARP cache. During this window, traffic from the gateway to the client drops silently - and nothing in the IP layer signals why.
The most common 'connected but no internet' complaint after a Wi-Fi association has nothing to do with RF, DHCP, or the AP. It is an ARP timing gap at Layer 2 - and it is invisible in every log except the PCAP.
arp.opcode == 1 && arp.src.proto_ipv4 == arp.dst.proto_ipv4Gratuitous ARP - sender IP = target IP. The GARP a client sends after association.arp && !arp.isgratuitousNormal ARP requests (not GARP). Standard gateway→client lookups.dns && !dns.flags.responseDNS queries with no response pair. Unanswered queries during dead window.http.request.uri contains "connectivitycheck"Android connectivity probe to Google. No response = dead window active at that moment.eapol || (arp.opcode == 1 && arp.src.proto_ipv4 == arp.dst.proto_ipv4)4-Way Handshake completion + first GARP in sequence. Measure delta between M4 and GARP.ARP - Address Resolution Protocol
ARP (RFC 826) maps a known IP address to an unknown MAC address. When a gateway needs to forward a packet to 192.168.1.42, it must know the MAC address to put in the Ethernet frame. It looks in its ARP cache - if not found, it broadcasts an ARP Request. The client responds with its MAC. This MAC is then cached (default TTL: 20 minutes on Linux, 10 minutes on Windows, varies by vendor).
In a stable network, this works fine - the ARP cache is warm. The dead window problem occurs specifically during the brief period after a client first associates (or reassociates after roaming), before the gateway has a fresh ARP cache entry for that client's IP+MAC pair.
The Dead Window - Step by Step
802.11 auth + association completes. EAPOL 4-Way Handshake done. Client has IP (from previous DHCP or fast-reconnect). Wi-Fi icon shows connected.
Gratuitous ARP broadcast: "10.0.0.42 is at AA:BB:CC". Intent: update the ARP caches of ALL on-link devices, including the gateway.
Between GARP transmission and when GARP reaches/is processed by the gateway. During this window, the gateway ARP cache may still have a stale or missing entry for this IP.
Client immediately tries internet traffic. DNS query goes to gateway. Gateway forwards to upstream. Response arrives back at gateway - needs to deliver to client.
Gateway already has fresh ARP entry from GARP or from client's outgoing traffic. Response delivered. "Connected, internet works." Window: 50–500 ms typical.
Gateway did not process GARP (rate-limited, dropped, stale cache not updated). Gateway cannot deliver response. Client sees DNS timeout. "Connected, no internet."
The client's IP stack reports "connected" because the Wi-Fi association is complete and the client has an IP address. The failure occurs at the gateway's ARP layer - the gateway simply discards the response packet because it has no ARP entry for the destination. No ICMP unreachable is generated. No TCP RST is sent. The client sees only a timeout at the application layer, which may be misdiagnosed as: DNS failure, HTTP server error, Wi-Fi signal problem, or "the internet is down." The only definitive diagnosis is a simultaneous PCAP at the client AND the gateway side.
Gratuitous ARP (GARP) - The Mechanism and Its Failure Modes
A Gratuitous ARP is an ARP Request where the sender IP = target IP. The sender is not asking for a MAC - it is announcing its own IP+MAC mapping to everyone on the link. All devices that receive it should update their ARP cache for that IP.
Android No-WAN-Path - The Aggravating Factor
Android devices add a second failure mode that interacts with the ARP dead window. After association, Android sends an HTTP probe to connectivitycheck.gstatic.com to test internet connectivity. If the probe fails (during the ARP dead window), Android marks the Wi-Fi network as "no internet" and may:
Android silently falls back to cellular. User sees "connected" Wi-Fi but all data flows through cellular. Battery drains, data plan consumed.
Wi-Fi icon shows exclamation mark (!). User thinks AP/network is broken. Actually: ARP dead window resolved after 500ms, connection fine now.
Some Android versions disconnect and retry association, restarting the ARP dead window cycle. Causes visible "connected → disconnected → connected" oscillation.
In a PCAP: client associates (Auth → Assoc → EAPOL M1-M4), client sends GARP, client immediately sends DNS query for connectivitycheck.gstatic.com, DNS response arrives, client sends HTTP GET to 142.250.x.x, HTTP response never arrives (ARP dead window), client retries the connectivity check 2–3 times, then switches to cellular. The entire sequence takes 1–3 seconds. Without a dual-capture (client + gateway), the gateway-side ARP failure is invisible.
Three-Failure-Mode Pattern in Wi-Fi 7 Deployments
In mixed WPA2/WPA3 Wi-Fi 7 deployments, the ARP dead window is often the third failure in a cascade that starts elsewhere:
Android reports MFPC=0 in Assoc Request despite connecting to a WPA3 SSID with MFPR=1. AP rejects with Status Code 30. Client retries on WPA2 SSID.
On VLAN-per-SSID deployments, the WPA2 fallback SSID is on a different VLAN than WPA3. Client gets a new IP from the WPA2 VLAN DHCP pool.
New IP + new VLAN means gateway has no ARP entry. GARP from client may not cross VLAN boundary. Internet works after ARP resolves (~1-3s) but Android has already marked the network as "no internet."
This three-failure cascade (PMF compatibility gap + VLAN change + ARP dead window) was first documented through passive PCAP analysis of production Wi-Fi 7 gateway deployments, capturing the exact frame-level interaction between the 802.11 MAC layer and the ARP layer that neither the AP vendor logs nor the client OS logs expose. The ARP dead window and PMF compatibility gap are two of three failure modes analysed in ongoing IEEE 802.11 field research.
PCAP Diagnosis - Detecting the Dead Window
arp.opcode == 1 && arp.src.proto_ipv4 == arp.dst.proto_ipv4 // Gratuitous ARP
arp && !arp.isgratuitous // Non-GARP ARP (normal requests)
dns && !dns.flags.response // Unanswered DNS queries (no response pair) Mitigations
AP intercepts ARP Requests on behalf of associated clients and responds from the client's last-known MAC. Eliminates the gateway-side dead window. Defined in 802.11v (WNM). Most enterprise WLCs support this (Cisco: ip proxy-arp, Aruba: proxy-arp).
Default Linux ARP cache TTL is 20 minutes. Reducing to 60–120 seconds forces more frequent ARP refresh but reduces the dead window's impact. Trade-off: more ARP traffic in dense networks.
When client renews DHCP lease, AP/WLC can trigger an ARP update on the gateway side. Some controllers do this automatically on re-association.
OS-level fix: client sends GARP 3× with 1-second intervals after every association. Reduces race condition probability. iOS and Windows do this; Android historically does not consistently.
Not a fix but a workaround: reducing Android's CaptivePortalCheckTimeout gives the ARP dead window more time to resolve before Android marks the network as "no internet." Not user-configurable on stock Android.