200+ Funny WiFi Names That Will Make Your Neighbours Laugh
The best funny WiFi names — puns, pop-culture jokes and neighbour-trolling SSIDs — with the ones that actually…
CAPWAP (Control and Provisioning of Wireless Access Points) is an IETF standard protocol (RFC 5415) that defines how lightweight wireless access points communicate with a Wireless LAN Controller (WLC). CAPWAP creates two UDP tunnels: a control tunnel (port 5246) for management traffic and a data tunnel (port 5247) for client data.
Key takeaways
- CAPWAP = Control and Provisioning of Wireless Access Points — defined in RFC 5415
- Lightweight APs (LAPs) use CAPWAP to connect to and be managed by a WLC (Wireless LAN Controller)
- CAPWAP uses UDP port 5246 for control traffic and UDP port 5247 for data traffic
- CAPWAP replaces the older Cisco-proprietary LWAPP protocol
- Without a WLC connection, a lightweight AP cannot forward client traffic independently
- CAPWAP discovery process: broadcast → DHCP option 43 → DNS → WLC IP directly
- Cisco FlexConnect mode allows APs to switch data locally even when CAPWAP tunnel drops
CAPWAP (Control and Provisioning of Wireless Access Points) is the protocol a lightweight access point uses to talk to a Wireless LAN Controller. It replaced Cisco’s proprietary LWAPP and is standardised in RFC 5415.
It builds two tunnels between the AP and the WLC, and knowing which is which explains most troubleshooting:
| Tunnel | Port | Carries | Encrypted |
|---|---|---|---|
| Control | UDP 5246 | Configuration, firmware, statistics, client state | Yes — DTLS, always |
| Data | UDP 5247 | Actual client traffic | Optional — off by default |
An AP with no controller is a paperweight — a lightweight AP holds no configuration of its own and cannot serve clients until it joins.
How an AP Finds Its Controller
The AP works through discovery methods in order and stops at the first that produces a response:
- Previously known controllers. The AP stores up to three WLC addresses in NVRAM from its last successful join. This is why a previously working AP rejoins instantly and a factory-reset one does not.
- Layer 2 broadcast on the local subnet — only works if the WLC is on the same VLAN.
- DHCP Option 43 — the DHCP server supplies the WLC’s management address. The standard method when the AP and WLC are on different subnets.
- DNS — the AP resolves
CISCO-CAPWAP-CONTROLLER.localdomainusing the domain name from DHCP. - Static configuration via the AP’s console.
DHCP Option 43
The value is hex, and its format trips people up:
! Type f1, length = 4 × number of controllers, then each IP in hex
! One WLC at 10.10.10.5 → 0A 0A 0A 05
ip dhcp pool AP-POOL
network 192.168.100.0 255.255.255.0
default-router 192.168.100.1
option 43 hex f104.0a0a.0a05For two controllers at 10.10.10.5 and 10.10.10.6, the length byte becomes 08:
option 43 hex f108.0a0a.0a05.0a0a.0a06Get the length byte wrong and the AP silently ignores the option — there is no error, it simply never discovers the controller.
The Join Process
- AP boots and gets an IP address by DHCP.
- Discovery Request sent to every controller it found.
- Discovery Response from each WLC, including its current AP count and capacity.
- AP selects a controller — primary if configured, otherwise the least-loaded one that responded.
- DTLS session established on UDP 5246. Both sides validate certificates.
- Join Request and Join Response.
- Image check. If the AP’s firmware does not match the controller’s, it downloads the correct image and reboots, then repeats the whole process. This is why a first join can take several minutes.
- Configuration download — SSIDs, radio settings, RF profile.
- AP goes operational and begins serving clients.
Why Joins Fail
| Cause | Symptom | Check |
|---|---|---|
| Certificate expiry | DTLS handshake fails | show time on both — clocks must be correct |
| Clock skew | Same as above | NTP on the WLC and the AP |
| UDP 5246/5247 blocked | Discovery gets no response | Firewall and ACLs between AP and WLC subnets |
| Option 43 malformed | AP never discovers anything | Length byte must be 4× the controller count |
| Controller at capacity | Join rejected | show ap summary vs the platform limit |
| Version mismatch | AP downloads an image, reboots, repeats | Normal on first join; a loop means the image is wrong |
| AP not in the WLC’s authorisation list | Join rejected | AP authorisation policy and MAC filter list |
| Country code mismatch | AP joins, radios stay down | The AP’s regulatory domain must be permitted on the WLC |
| MTU too low | Joins then drops repeatedly | CAPWAP adds overhead; the path needs headroom |
Certificate expiry is worth calling out
Cisco AP manufacturer-installed certificates have finite lifetimes, and a substantial number issued in the 2010s have now expired. An affected AP simply cannot complete the DTLS handshake. The workaround is to disable certificate date validation on the controller:
(WLC) config ap cert-expiry-ignore mic enable
(WLC) show ap cert-expiry-ignoreThis is a deliberate weakening of validation. It is the accepted fix for affected hardware, but it should be applied knowingly rather than as a routine troubleshooting step.
Troubleshooting Commands
On the AP console
AP# show capwap client rcb
AP# show capwap ip config
AP# show ip interface brief
AP# debug capwap client event
AP# debug capwap client error
AP# debug dtls client error
! Force a specific controller
AP# capwap ap controller ip address 10.10.10.5
AP# capwap ap ip address 192.168.100.50 255.255.255.0
AP# capwap ap ip default-gateway 192.168.100.1On the controller
(WLC) show ap summary
(WLC) show ap join stats summary all
(WLC) show ap join stats detailed <AP-MAC>
(WLC) debug capwap events enable
(WLC) debug capwap errors enableshow ap join stats detailed is the most useful of these — it records why the last join attempt failed, including the specific DTLS or configuration error.
Local Mode vs FlexConnect
| Local mode | FlexConnect | |
|---|---|---|
| Client data path | Tunnelled to the WLC | Switched locally at the AP |
| If the WLC is unreachable | Clients drop | Existing SSIDs keep working |
| WAN bandwidth used | All client traffic crosses it | Control traffic only |
| Suited to | Campus, where the WLC is local | Branch sites over a WAN |
In local mode, every client packet is tunnelled to the controller and back — even traffic between two devices in the same room. Over a branch WAN link that is wasteful and adds latency, which is exactly what FlexConnect exists to avoid.
Design Notes
- NTP on everything. CAPWAP depends on certificate validation, which depends on correct time. This is the most common preventable cause of an AP not associating with the WLC.
- Permit UDP 5246 and 5247 end to end between the AP subnet and the WLC.
- Configure primary, secondary and tertiary controllers on each AP so failover is deterministic rather than load-based.
- Use FlexConnect for branches reached over a WAN.
- Allow MTU headroom. CAPWAP encapsulation adds overhead, and a path at exactly 1500 will cause intermittent drops.
- Enable data DTLS only where required. It encrypts client traffic in the tunnel but costs controller throughput, and most deployments do not need it since the traffic is already encrypted over the air and by TLS above.
- Plan controller redundancy — in local mode, losing the WLC drops every client on every AP.
Frequently Asked Questions
What ports does CAPWAP use?
UDP 5246 for the control tunnel and UDP 5247 for the data tunnel. Both must be permitted between the AP and the controller.
Why will my AP not join the controller?
Most often clock skew or an expired AP certificate breaking the DTLS handshake, a blocked UDP port, or a malformed DHCP Option 43. Run show ap join stats detailed on the WLC for the specific reason.
What is the difference between CAPWAP and LWAPP?
CAPWAP is the standards-based successor to Cisco’s proprietary LWAPP. It uses different ports, mandates DTLS for control traffic, and is defined in RFC 5415.
Does CAPWAP encrypt client data?
Control traffic is always DTLS-encrypted. Data traffic is not encrypted by default — you can enable data DTLS, at a throughput cost on the controller.
Can an AP work without a controller?
A lightweight AP cannot. It holds no local configuration. An AP running autonomous or Mobility Express software can, and FlexConnect APs continue serving existing SSIDs if the controller becomes unreachable.
How long should a join take?
Under a minute normally. Several minutes on a first join if the AP has to download a matching firmware image and reboot. Repeated download-and-reboot cycles mean the image on the controller is wrong for that AP model.
