Network labs Docs Open simulator →

CAPWAP round-trip — wifi-client traffic both directions

Slice J closes the round-trip: the WLC now intercepts packets destined for known wifi-clients and re-encapsulates them as CAPWAP-Data downlink (UDP/5247) toward the associated AP. Wireless client → DEST → reply → WLC → re-encap → AP — both legs in pcap.

Open this lab in your browser →

Free · no install · no account

Scenario

Slice I delivered the *uplink* datapath: wifi-client → AP encap → WLC decap → policy-VLAN egress → DEST. Slice J adds the downlink half. When a packet arrives at the WLC destined for a wifi-client's IP, the controller's IPv4 forwarder consults a per-client locator (built from wifiClient.ipv4 + wifiClient.associatedAp + the AP's apJoin.joinedController). On hit, the packet is wrapped in CAPWAP-Data with direction: 'downlink' and emitted from the WLC toward the AP's IP — instead of the normal FIB lookup that would ARP the client on the policy VLAN and fail (the client has no wired iface). This closes the canonical "phone → callmgr → phone reply" round-trip: 1. PHONE (wifi-client at 10.30.0.50) emits via engine.emitWirelessClientPacket. 2. AP1 wraps in uplink CAPWAP-Data (UDP/5247) to WLC1. 3. WLC1 decaps, re-emits inner ICMP echo-request 10.30.0.50 → 10.40.0.5 via Vlan30 → routed to DEST. 4. DEST replies with echo-reply 10.40.0.5 → 10.30.0.50, default-route via WLC1. 5. WLC1 receives the reply on its transit iface; the forwarder's wireless-client intercept matches dst 10.30.0.50. 6. WLC1 wraps the inner echo-reply in downlink CAPWAP-Data and sends it to AP1. 7. AP1 receives the downlink frame — pcap shows it. What's deferred: - Per-WLAN ACLs at the AP: the downlink frame would have its inner evaluated against the AP's per-WLAN ACL before reaching the client's radio. v1 ships only the encap. - Real wireless delivery: the AP doesn't model 802.11 frame transmission, so "the client receives" is implicit (visible as PacketDelivered for the downlink trace at AP1). The downlink intercept matches *any* IP protocol — ICMP, UDP, TCP, other — destined for a known wifi-client. The inner packet is embedded verbatim into CAPWAP-Data; the AP's downlink handler renders it. Loop protection excludes our own outbound CAPWAP frames so we don't wrap-and-rewrap.

Topology

2 × router, 1 × wireless controller, 1 × switch, 1 × access point, 1 × wifi client · Cisco IOS-XE-style

What you will do

  1. Confirm AP1 joined WLC1 and PHONE has its static IP.

  2. Trigger PHONE: engine.emitWirelessClientPacket({ deviceId: 'PHONE', dst: parseIPv4('10.40.0.5') }). Pcap should show: (a) UDP/5247 uplink AP1→WLC1, (b) decap'd echo-request on Vlan30, (c) routed via Gi0/2 to DEST, (d) echo-reply from DEST returns to WLC1, (e) UDP/5247 downlink WLC1→AP1 carrying the inner echo-reply.

Open this lab in your browser →

More labs on this topic

This lab in other languages

CAPWAP-Rundreise – WLAN-Client-Verkehr in beide RichtungenCAPWAP ida y vuelta: tráfico de cliente wifi en ambas direccionesIda e volta CAPWAP - tráfego de cliente wifi em ambas as direçõesCAPWAP aller-retour — trafic client Wi-Fi dans les deux sensCAPWAP राउंड-ट्रिप - वाईफाई-क्लाइंट ट्रैफ़िक दोनों दिशाओं मेंCAPWAP 往返 — wifi 客户端流量双向CAPWAP andata e ritorno: traffico client Wi-Fi in entrambe le direzioniCAPWAP ラウンドトリップ — Wi-Fi クライアント トラフィックの両方向CAPWAP 왕복 — Wi-Fi-클라이언트 트래픽 양방향CAPWAP туда и обратно — трафик Wi-Fi-клиента в обоих направленияхCAPWAP gidiş-dönüş — her iki yönde de Wi-Fi istemci trafiğiChuyến đi khứ hồi CAPWAP - lưu lượng truy cập wifi-client cả hai hướng