Most “wireless” problems aren’t wireless. After 25 years and a few thousand site visits, the pattern holds: the ticket says Wi-Fi, the fix is wired. Bad cable. Wrong PoE class. A VLAN that never made it to the port. A DHCP scope that ran dry. DNS the client could never reach. The radio is innocent far more often than the radio gets blamed. So before you climb a ladder with a spectrum analyzer, prove the plumbing.
That is the whole doctrine, and it is more true at Wi-Fi 6E and Wi-Fi 7 than it was a decade ago. Faster radios don’t remove the bottleneck. They move it onto the wired side, onto the uplink, onto the switch. A 6 GHz radio that can move multi-gigabit traffic over the air is worth nothing if the cable feeding it negotiated 100 Mbps because someone crimped pair 3 wrong. The faster the air gets, the more the wire decides whether you succeed.
So here is the checklist I use, in the order I use it. The order is the point. Prove each layer before you move to the next, and never trust the config when you can test the path.
Before you install the Access Point
Prove the wired path first. Every item here is something you can verify with a tester or a laptop terminal before the AP ever powers on:
- Cable meets or exceeds Cat5e, and the total channel is under 100 m including patch cords. Cat5e is the floor. It carries 1 GbE and even 2.5/5 GbE multi-gig over the same 100 m channel. For a new install feeding a Wi-Fi 6E/7 AP with a multi-gig uplink, run Cat6A and leave yourself the headroom. The 100 m channel limit (90 m permanent link plus 10 m of patch cords) has not changed.
- PoE meets the AP’s specific requirement. Check 802.3af, 802.3at, or 802.3bt, and verify the class actually negotiated. This check matters more now than it ever did. Many Wi-Fi 6E/7 APs need 802.3bt (Type 3 or Type 4, up to 60 to 90 W) to run all their radios plus USB and IoT ports at full power. Feed one of those APs from an older 802.3af or 802.3at port and it won’t fail loudly. It degrades quietly: a radio goes dark, spatial streams drop, the uplink throttles. You spend a week chasing an “RF problem” that is a power budget problem. Verify the negotiated class. That is the failure this catches.
- Confirm the DHCP address and the VLAN. Does the port hand out an address, and is it on the VLAN you intended?
- Confirm the correct VLAN assignment, and the access or trunk port as required. An AP that needs a trunk on an access port is a problem you want to find now, not after it’s bolted to a ceiling.
- Confirm the default gateway, then ping it. Confirming it is configured is not the same as proving it answers. Ping it.
- Confirm the target IP addresses are reachable. The controller, the cloud endpoint, whatever this AP needs to phone home to.
- Confirm DNS is reachable, and confirm the target DNS addresses resolve. A reachable resolver that can’t resolve the name you need is still a dead end.
- Management VLAN assigned and available.
Notice what every one of those has in common. You can prove it before the AP is in the air. None of it requires a ladder.
Install the Access Point
One gate. Mount it. Now you verify what you mounted.
After you install the Access Point
Document what you put up, then prove it does what you intended. Documentation first, because an undocumented AP is an AP you will lose track of the moment the controller dashboard fills up:
- Document the AP’s MAC and assigned name.
- Document the AP’s location.
- Document the switch and port it lives on.
- Document the AP’s IP address.
- Confirm the AP is installed in the proper orientation. With 6 GHz in the mix, this is less forgiving than it used to be. The shorter range and tighter link budget at 6 GHz punish a sloppy mount harder than 2.4 or 5 GHz ever did.
- Confirm external antennas are installed correctly. Right antenna, right port, right orientation.
- Wait for the AP to receive its configuration, and allow for a possible second reboot. Controller, cloud-managed, on-box config: a firmware pull plus a config apply often forces a reboot cycle. Sometimes two. Let it finish before you judge it.
- Listen in the air for every SSID being broadcast. Not the config screen. The air. Are all the SSIDs you intended actually on the air?
- Connect a client to each SSID.
- Check each SSID for the proper VLAN and IP pool. This is the verification that catches the silent failures. An SSID can broadcast fine, accept a client fine, and still drop that client onto the wrong VLAN or an exhausted IP pool. Prove every advertised SSID maps to the VLAN and subnet you meant it to.
You do not need a five-thousand-dollar tester
You can run every check above with a dedicated cable and network tester, the kind that certifies the link, reads the PoE class, pulls a DHCP lease, and pings the gateway for you. Those tools are fast and they’re worth owning if you do this for a living.
You can also run every check above with a laptop and the right commands. ping the gateway. nslookup or dig to prove DNS. ipconfig or ifconfig to read the lease. arp to see who answered. tracert or traceroute to watch the path. The WLAN Pros Toolbox ships these exact utilities, so the phone in your pocket can do a fair amount of it too.
The tester is faster. The laptop is free. Either one beats the most common method, which is to assume the config is right and blame the air when it isn’t. Test the link. Don’t trust it.
The verdict, restated
Most wireless problems aren’t wireless. Prove the wired path before you touch the radio, in this order: cable, PoE, DHCP and VLAN, gateway, DNS, install, then verify every SSID lands on the VLAN and pool you intended. Verify, don’t assume, at every single layer. Do that, and the next time someone hands you a “Wi-Fi problem,” you’ll already know whether it’s even a Wi-Fi problem at all. Most of the time, it won’t be.