CAPWAP retry, heartbeat, and wifi-client tunnel emission
- Services & wireless
- Advanced
- 18 min
- 3 steps
- Cisco IOS-XE-style
Slice H makes CAPWAP behave like the real protocol: APs retry the join when the path is broken, exchange echo heartbeats with the controller every 30 s once joined, and wireless clients are first-class topology citizens. PHONE (a wifi-client associated with AP1) emits a packet that travels CAPWAP-encapsulated on UDP/5247 from AP1 to WLC1 — visible in pcap.
Open this lab in your browser →
Free · no install · no account
Scenario
Three additions in this lab: 1. Retry timer: when AP1's join-request is lost (firewall drop, bad route, packet collision), the AP re-emits every 5 s. After 6 attempts it gives up — pcap shows the bounded burst rather than an infinite spin. 2. Echo heartbeat: once joined, AP1 emits an echo-request (UDP/5246, messageType: 'echo-request') every 30 s. WLC1 acknowledges with echo-response and result: success. After 3 missed responses the AP transitions back to phase: 'discovered' and triggers a fresh join — exactly what real APs do when the controller goes silent. 3. wifi-client device kind: a new device kind that logically associates with an AP. Outbound traffic is wireless-to-AP and then CAPWAP-Data-encapsulated (UDP/5247) to the controller. The simulator exposes engine.emitWirelessClientPacket(deviceId, innerSummary) to fire one — pcap shows the encap'd UDP/5247 frame with app: { kind: 'capwap-data', direction: 'uplink', innerSummary, apMac }. The combined effect: a network engineer can now assess "how much CAPWAP traffic is on the wire?" by reading captured frames; can see retry storms when paths break; can place firewalls/IPS along the AP-WLC path and watch them inspect real UDP/5246 + UDP/5247 traffic. What's still forward work: the WLC-side decap of UDP/5247 (re-emit inner frame on the policy-VLAN egress) and DHCP-via-AP for client IP acquisition. Slice H gives the *uplink* datapath visibility — the most useful piece for firewall positioning — and defers the full bidirectional model.
Topology
1 × router, 1 × wireless controller, 1 × switch, 1 × access point, 1 × wifi client · Cisco IOS-XE-style
ROUTER— routerWLC1— wireless controllerHUB— switchAP1— access pointPHONE— wifi client
What you will do
After convergence, AP1 should be in
phase: joined(open path, no firewall blocking).Run the simulator for 90 seconds. Pcap should show at least 2 round-trips of
echo-request(AP1→WLC1) andecho-response(WLC1→AP1) on UDP/5246.Trigger PHONE to emit a packet via the engine API:
engine.emitWirelessClientPacket({ deviceId: 'PHONE', innerSummary: 'icmp echo-request 10.30.0.5' }). The pcap shows a CAPWAP-Data UDP/5247 frame leaving AP1 toward WLC1's mgmt IP, carrying the inner summary.
Open this lab in your browser →
More labs on this topic
- Configure a DHCP serverBeginner · 12 min
- WLAN — broadcast a basic SSIDBeginner · 10 min
- HSRP: configure first-hop redundancyIntermediate · 12 min
- NAT: PAT (overload) for an inside LANIntermediate · 14 min
- HSRP — interface tracking with priority decrementIntermediate · 12 min
- VRF-Lite — two customers on one routerIntermediate · 12 min
This lab in other languages
CAPWAP-Wiederholung, Heartbeat und WLAN-Client-Tunnel-EmissionReintento CAPWAP, latido y emisión de túnel de cliente wifiNova tentativa CAPWAP, pulsação e emissão de túnel do cliente wifiNouvelle tentative CAPWAP, battement de cœur et émission de tunnel client Wi-FiCAPWAP पुनः प्रयास, दिल की धड़कन, और वाईफाई-क्लाइंट सुरंग उत्सर्जनCAPWAP 重试、心跳和 wifi 客户端隧道发射Nuovo tentativo CAPWAP, heartbeat ed emissione del tunnel client Wi-FiCAPWAP の再試行、ハートビート、および Wi-Fi クライアント トンネルの送信CAPWAP 재시도, 하트비트 및 Wi-Fi 클라이언트 터널 방출Повторная попытка CAPWAP, контрольный сигнал и эмиссия туннеля Wi-Fi-клиентаCAPWAP yeniden denemesi, kalp atışı ve Wi-Fi istemci tüneli emisyonuThử lại CAPWAP, nhịp tim và phát ra đường hầm wifi-máy khách