When a connection breaks, test from the client device, in order, from the radio up. The client is the only place where the truth lives. The controller dashboard tells you what the AP thinks is happening. The client tells you what is actually happening to the user standing in the room. Those are not the same thing, and when they disagree, the client wins.
I walk the same 12 checks every time, bottom-up the stack. Each one proves a single thing, and each one depends on the one before it. Skip a step and you end up guessing. Run them in order and the failure tells you exactly where it lives.
Here is the ladder.
Step 1: Can the client see all SSIDs being broadcast?
Before anything else, prove the client can hear the network. If the target SSID does not show up in the scan, nothing downstream matters. You have an RF visibility problem, not a network problem.
On 6 GHz this looks different than it used to. A Wi-Fi 6E or Wi-Fi 7 client does not blindly scan every 6 GHz channel. It learns about the 6 GHz AP out-of-band, through a Reduced Neighbor Report from the 2.4 or 5 GHz radio, and through preferred scanning channels. The mechanism got smarter. The check did not change. Can the client see the network it is supposed to join? Yes or no.
Step 2: Associate to the target SSID
Seeing the SSID and joining it are two different events. Association is the client and the AP agreeing to talk. If the client sees the network but cannot associate, you are looking at the AP, the band, or a client-capability mismatch, not RF coverage.
Step 3: Complete SSID authentication
Association gets you in the door. Authentication proves you belong. This is where a wrong PSK, a misconfigured RADIUS server, or a 802.1X failure stops the client cold.
The methods behind this step advanced since the card was first drawn. WPA3-Personal with SAE and WPA3-Enterprise are mainstream now, and 6 GHz mandates WPA3. Open networks and legacy WPA2 are not allowed on 6 GHz at all. So if you are testing a 6 GHz join and the client is trying to authenticate with anything below WPA3, the failure is by design. The step is identical. The security baseline underneath it moved up.
Step 4: Receive an IP address via DHCP
Authenticated and on the network, the client now needs an address. No IP, no Layer 3. If authentication passed but DHCP did not deliver an address, the radio side is healthy and your problem is upstream, in the DHCP scope, the VLAN, or the relay.
Step 5: Receive default gateway and DNS
An IP address alone gets the client nowhere useful. It needs to know where to send traffic, the default gateway, and how to resolve names, DNS. DHCP hands these over with the address. Confirm the client actually received them. A missing or wrong gateway looks like a dead connection even though association, authentication, and addressing all passed.
Steps 6 through 9: Ping the path, then read it correctly
Now you prove reachability, in widening circles:
- Ping the default gateway. Can the client reach its own first hop?
- Ping DNS. Can it reach the resolver it was handed?
- Ping a remote IP address. Can it reach off the local network?
- Ping a remote DNS name. Does name resolution plus routing work end to end?
This is the part of the card that needs modern interpretation, and it is the most important thing to internalize about ping in 2026.
Ping still proves Layer 3 reachability, and it is still a fine first cut. A failed ping is a strong negative. If you cannot reach the gateway, you have found your problem and you stop here.
But a passing ping is no longer a verdict. ICMP, the protocol behind ping, is now routinely rate-limited, deprioritized under QoS, or blocked outright on modern networks. That means a ping can come back slow, or with loss, on a connection that is actually fine, because the network is throttling ICMP on purpose while real application traffic sails through untouched. It also means a ping can pass while the link underneath it is garbage.
Treat ping as a reachability gate, not a performance measurement. Use it to answer one question: is the path open? Yes or no. The moment you start reading ping latency as your connection’s speed, the network’s QoS policy is lying to you and you are believing it.
For the performance picture, you do not look at ping. You look at the next three steps.
Step 10: Check the client MCS
MCS, the Modulation and Coding Scheme index, is the radio reporting the link quality it actually negotiated, independent of whether any traffic is flowing. It is the RF-layer truth. A low MCS on a client that should be close to the AP tells you the RF conditions are worse than the signal bars suggest.
Read the ceiling correctly for the generation you are on. The original card came from the 11ac era, where MCS topped out near MCS 9 with 256-QAM. A modern client can report up to MCS 11 with 1024-QAM on Wi-Fi 6, and MCS 12 or 13 with 4096-QAM on Wi-Fi 7. On a Wi-Fi 7 link the label carries a prefix, EHT-MCS, where Wi-Fi 6 says HE-MCS and 11ac said VHT-MCS. Same index concept, generation-stamped name.
One thing to know before you call a low number a fault: 4096-QAM, MCS 12 and 13, needs roughly 42 dB of SNR and is an optional Wi-Fi 7 feature. Not seeing MCS 12 or 13 is very often correct behavior, not a problem. The client is telling you the honest truth about its RF conditions, which is exactly why this check earns its place.
Step 11: Check the client Tx data rate
This is the single most useful line on the card. The negotiated Tx data rate is the actual speed the radio achieved, the real number, before any application ever sends a byte. Modern ceilings are far higher than the card’s era, 320 MHz channels and 4096-QAM and MLO on Wi-Fi 7 push the top end way up, so “what good looks like” is a bigger number now. The act of reading the client’s real Tx rate is unchanged, and it is the truth a speed test only approximates.
Step 12: Complete a network speed test
Last, and only last, run the speed test. This is the application-layer consequence of everything above it. By the time you get here, you already know the RF link is good, because you read the MCS and the Tx rate. The speed test confirms the end-to-end experience matches the link you measured. When the Tx rate is high and the speed test is low, your bottleneck is not the Wi-Fi, it is somewhere upstream, and you have just saved yourself from blaming the radio for the internet’s problem.
That ordering is deliberate. Read the negotiated rate the radio actually achieved first, then run the application speed test. The Tx rate is the RF truth. The speed test is the downstream result. Never invert it into “just run a speed test and see,” because a speed test alone cannot tell you where a slow result was born.
Why bottom-up, every time
The 12 checks isolate where a connection breaks by walking the stack from the radio up: RF visibility, association, authentication, addressing, reachability, PHY-rate quality, then end-to-end throughput. Each step proves one thing. The first step that fails is your answer. You stop guessing the moment the ladder stops climbing.
Test from the client device, in order, from the radio up. Read ping as a gate and not a stopwatch, read the Tx rate as your truth, and let the speed test confirm what you already measured. Do that and you will know where every broken connection actually breaks, instead of arguing with a controller dashboard about a problem the user is living and the dashboard cannot see.