AP will not join, or joins in the wrong country
common
“Half the new APs never showed up on the controller. The ones that did are on channels we do not use and their power is nothing like the others.”
Likely causes
-
Controller discovery missing: DHCP option, DNS name or broadcast domain
25%APs on the controller's own subnet join and APs on other subnets do not. The DHCP option carrying the controller address is absent or wrong for that scope, or the vendor's discovery DNS name does not resolve on that subnet.
-
Wrong VLAN or a locked-down port profile
20%AP powers up, so PoE is fine, but has no route to the controller, or it landed in a data-only or quarantine VLAN because port authentication or device profiling did not recognise it. An ACL or firewall blocking the vendor's control and data tunnel ports does the same thing from further away.
-
Firmware mismatch against the controller version
20%AP joins, downloads, reboots and repeats, or is rejected outright in the join log. New hardware revisions frequently need a newer controller release than the one running.
-
MTU or fragmentation breaking the tunnel
15%AP joins and then drops, or joins but clients get no traffic. Small control frames pass, tunnelled client data does not. Anything tunnelled, VPN'd or routed over a WAN link is the suspect; check path MTU against the figure the vendor documents for that platform's tunnel.
-
Clock skew failing certificate validation on join
10%Join log shows a certificate or authorization failure on an AP that is otherwise perfectly reachable. AP or controller time is out, or NTP is unreachable from the AP's VLAN. Bench-fresh and long-shelved units are the usual offenders.
-
Country code or regulatory domain wrong
10%AP joins but comes up with a channel list and power ceiling that do not match its neighbours: DFS channels missing, 6 GHz absent, power capped low or set unexpectedly high. It then presents as a coverage or channel-plan fault, which is how it survives for months. Hardware is also domain-locked, so a unit bought for another region may refuse to join or refuse to radiate there.
What to bring
- Controller AP-join log and AP list
- switch CLI for port, VLAN and PoE state
- AP console cable or adapter
- DHCP scope configuration
- a host on the AP's VLAN for discovery and MTU testing
- vendor release-compatibility matrix
Safety
Ceiling, ladder and lift access for AP work: ladder and fall protection rules apply (29 CFR 1926.1053, 1926.501). Above-grid work in older buildings: confirm tiles, fireproofing and pipe lagging are not asbestos-containing before you disturb anything.
Steps
-
Step 1: Split power from network in one look
Does the AP light up and appear on the switchport at all? Up on the port but absent from the controller is a discovery or network problem. Not powering, or cycling, is a power problem.
If that doesn’t do it
AP never powers or reboots in a loop: go to High-power AP will not stay powered.
-
Step 2: Confirm the AP got an address and can find the controller
From the console or the switch's view: address, mask, gateway, DNS, and whatever discovery information it received. Then check the DHCP option on that scope and resolve the vendor's discovery name from a host on the same VLAN.
If that doesn’t do it
AP has no address: fix DHCP on that VLAN first. Nothing downstream will work until it does.
-
Step 3: Read the controller's join log, not just the AP list
The rejection reason is usually written out: image mismatch, certificate or time failure, unknown AP, capacity or licence limit, country-code conflict. That single line picks your next step.
If that doesn’t do it
Nothing in the join log at all: the AP is not reaching the controller. Check routing, the ACL or firewall on the vendor's control and data ports, and the MTU, step 4.
-
Step 4: Test the path the tunnel actually uses
Reachability on the vendor's control and data ports from the AP's VLAN, then test for fragmentation with large packets and do-not-fragment set, up to the MTU the platform documents. Joins that succeed and then die under client load are this fault.
If that doesn’t do it
Path clean at full size: go to firmware and time, step 5.
-
Step 5: Match firmware and fix time
Stage the AP on the release the controller expects, and get NTP reachable from the AP's VLAN before you retest. Both are free, and both produce join failures that get mistaken for hardware faults.
If that doesn’t do it
Staged, timed and still rejected on a proven port: suspect a domain-locked or grey-market unit, step 6.
-
Step 6: Check the country code on every AP, then re-check the RF plan
Compare each AP's regulatory domain, and the channel list and power ceiling that result, against the rest of the site. A mis-set country code quietly rewrites the channel plan and the power limits, so after correcting it go back over co-channel and coverage: see APs fighting each other for airtime and Heat map was green, the room is dead. Take allowed channels and power from the AP's own regulatory table for that country, not from a forum post.
If that doesn’t do it
Domain is correct and it still will not run the expected channels: the hardware variant is wrong for the region. That is a supply problem, not a configuration one.
References
- 47 CFR 15.407
- ETSI EN 301 893 (outside FCC regions)
- RFC 2132 (DHCP options)
- vendor controller deployment guide