// reference · capwap · wired vantage
CAPWAP for Wi-Fi Engineers
In a controller deployment the 802.11 frames you want are wrapped in Ethernet, IPv4 and UDP and sent to the WLC. A SPAN of the AP switchport captures them, which is often the only capture a remote engineer can get. This page covers what that capture contains, what it structurally cannot contain, and two places where Cisco departs from the RFC in ways that will silently corrupt your analysis.
Every number here was measured on 2026-09-02 against four Cisco captures totalling 509 inner 802.11 frames. Nothing is quoted from a vendor document.
// the two ports, and which one is readable
| Port | Plane | Encryption | Useful? |
|---|---|---|---|
| UDP 5246 | Control | Always DTLS. Cannot be disabled on Cisco. | No. Do not spend time here. |
| UDP 5247 | Data | Unencrypted by default. DTLS optional, off except OfficeExtend. | Yes. This carries the 802.11 frames. |
FlexConnect and local switching produce no tunnel at all. Client traffic is bridged at the AP and reaches the switch as 802.1Q tagged Ethernet. If you SPAN a FlexConnect AP port expecting 802.11 frames you will get none, and no controller setting changes that. Capture on the air instead.
// the header, RFC 5415 section 4.3
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |CAPWAP Preamble| HLEN | RID | WBID |T|F|L|W|M|K|Flags| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fragment ID | Frag Offset |Rsvd | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (optional) Radio MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (optional) Wireless Specific Information | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload (802.11 frame when T=1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field | Bits | Meaning |
|---|---|---|
| CAPWAP Preamble | 8 | Version (4 bits) then Payload Type (4 bits). Version is 0. Payload Type 0 means a CAPWAP header follows, 1 means DTLS. |
| HLEN | 5 | Header length in 4-byte words, including the optional fields. Minimum 2. |
| RID | 5 | Radio ID, 1 to 31. MAC addresses are not unique across radios in one WTP, so this identifies which one. |
| WBID | 5 | Wireless Binding Identifier. 1 is IEEE 802.11, defined in RFC 5416. |
| T | 1 | 1 means the payload is a native 802.11 frame. 0 means 802.3. |
| F / L | 2 | Fragment, and Last fragment. |
| W | 1 | Wireless Specific Information present. |
| M | 1 | Radio MAC address present. |
| K | 1 | Keep-alive. No 802.11 frame to decode. |
| Fragment ID | 16 | Groups fragments of one frame. |
| Frag Offset | 13 | Offset in 8-octet units, then 3 reserved bits. |
// deviation 1: cisco byte-swaps the frame control field
Cisco never implemented the final CAPWAP draft. The two octets of the 802.11 Frame Control field arrive in the wrong order. Wireshark handles it, but the preference is
off by default: Preferences, Protocols, CAPWAP, "Cisco Wireless Controller Support". Without it, frames decode as malformed Association Requests, and people have filed Wireshark bugs over it.
The reason it corrupts silently is that the misread is still a valid-looking frame. Byte 0 becomes the flags octet, whose type and subtype bits read as Management subtype 0, Association Request. Every frame in the capture becomes an Association Request, and nothing errors.
The reason it corrupts silently is that the misread is still a valid-looking frame. Byte 0 becomes the flags octet, whose type and subtype bits read as Management subtype 0, Association Request. Every frame in the capture becomes an Association Request, and nothing errors.
Detecting it reliably. The obvious test is to count frames whose byte 0 has non-zero protocol-version bits. That fails. Protocol version is always 0 on air, so a clean capture scores exactly 0, never a partial ratio. But when a capture is swapped, byte 0 is the flags octet, and its low two bits are ToDS and FromDS, which are both zero on every management and control frame. A swapped, management-heavy capture therefore scores only data-frames over total.
Measured: Capture D scores 3/14 = 21.4% while being entirely swapped. Any threshold above that misses it. Score both orientations instead and pick the one with no protocol-version violations, breaking ties on type/subtype diversity: a wrong interpretation collapses every frame onto one value.
Measured: Capture D scores 3/14 = 21.4% while being entirely swapped. Any threshold above that misses it. Score both orientations instead and pick the one with no protocol-version violations, breaking ties on type/subtype diversity: a wrong interpretation collapses every frame onto one value.
// deviation 2: the rssi field is present, correctly sized, and empty
RFC 5416 section 4.5 defines a Wireless Specific Information field for uplink data messages, the IEEE 802.11 Frame Info: RSSI as a signed 8-bit value, SNR signed 8-bit, Data Rate 16-bit. Read the RFC and you would expect a wired capture to give you per-frame RSSI from the AP radio, which would be a significant advantage over a single-vantage sniffer.
It does not. Cisco sets the W flag, writes a correctly sized 4-byte field, and fills it with zeros.
It does not. Cisco sets the W flag, writes a correctly sized 4-byte field, and fills it with zeros.
raw WSI bytes, Capture A, 228 frames with W set
len=4 00000000 226 frames len=4 d5330000 1 frame -> RSSI -43 dBm, SNR 51 dB, coherent len=4 <other> 1 frame
The one populated frame proves the field works and the encoding is right, so this is not a parsing error. Across four captures the pattern held: one usable measurement per capture, almost certainly recorded at association and never updated. On Capture B the single non-zero byte was +1, which is not a received signal level at all, so a decoder must range-check rather than trust it.
// the four captures
| Capture | Platform | Frames | FC swapped | W set | Usable RSSI |
|---|---|---|---|---|---|
| Capture A | Catalyst 9800 controller, Wi-Fi 6E client | 283 | 274/283 | 228 | 1 (one usable value, -43 dBm) |
| Capture B | Catalyst 9800 controller, Wi-Fi 7 client | 207 | 203/207 | 167 | 1 (value was +1, not a signal level) |
| Capture C | Catalyst 9800 controller, Local MAC mode | 5 | 0/5 | 5 | 1 (one usable value, -38 dBm) |
| Capture D | Lightweight AP, over-the-DS roam | 14 | 3/14 | 13 | 2 (-56 and -65 dBm) |
Note the swap column. Two captures sit near 97%, one at 21.4%, one at 0%. The 21.4% capture is entirely swapped: it is a roam trace and therefore management-heavy, which is exactly the case a ratio threshold gets wrong. The 0% capture is a Local MAC capture where the AP terminates 802.11 itself. Captures are lab traces held privately; the measurements are reproducible against any Cisco controller capture using the method described above.
Fragmentation: zero occurrences across all four captures, despite CAPWAP adding 16 to 24 bytes on top of the MTU. Worth handling for correctness, but it does not appear to bite in practice on the 9800.
Fragmentation: zero occurrences across all four captures, despite CAPWAP adding 16 to 24 bytes on top of the MTU. Worth handling for correctness, but it does not appear to bite in practice on the 9800.
// absent by construction
Retries
The AP retransmits on the air and forwards one copy up the tunnel. A retry rate computed here is always near zero, and that is the vantage rather than the network.
ACKs and Block ACKs
Control frames are consumed by the radio. They never enter the tunnel.
Per-frame RSSI and SNR
Defined by RFC 5416, and empty in practice. See the measurement below.
Most management frames
The AP answers Probe, Auth and Assoc locally in Local MAC mode. Their absence is not a failed association.
Frames from non-associated stations
A probe request from a station that never joined has nothing to be tunnelled through.
Channel and PHY rate
No radiotap exists. Anything the WSI does not carry is gone.
// what this vantage gives you
Decrypted payloads
The AP decrypts before forwarding, so DNS, mDNS, SSDP and HTTP are readable. An over-the-air capture of the same session shows CCMP-protected data and nothing above layer 2. Treat these captures as containing plaintext user traffic.
Both directions of the association
Uplink and downlink arrive on the same wire, with no channel or vantage gap between them.
A capture you can actually get
A SPAN of the AP switchport needs no spare radio, no channel guess and no physical presence. Often the only capture a remote engineer can obtain.
// field notes
01 Never conclude anything about RF from a CAPWAP capture. A 0% retry rate is the vantage, not a clean channel. So is the absence of probe storms, the absence of deauths you did not see, and any frame-type ratio.
02 Enable the Wireshark Cisco preference before you start, or verify the Frame Control orientation yourself. If every frame reads as an Association Request, that is the tell.
03 Do not troubleshoot a roam or an association failure from a tunnel capture alone. The management frames that would explain it were handled locally and never encapsulated.
04 These captures contain decrypted user traffic. DNS, mDNS and HTTP are all readable. Handle and share them accordingly, and sanitise before sending to a vendor.
05 Take a monitor-mode capture alongside where you can. The two vantages answer different questions, and the pair is far stronger than either alone.
06 A public CAPWAP sample is hard to find, since a real one exposes live BSSIDs and client MACs. Johannes Weber's Ultimate PCAP contains one: 15 data and 22 control packets, useful for testing a decoder.
// share this page
// also on this site
SK
— Shankar K., Wi-Fi engineer, Irving TX
Building WiFi Analyser V2 · CWNA-109 in progress · one post every two weeks
Building WiFi Analyser V2 · CWNA-109 in progress · one post every two weeks
// leave a comment