In this post we will see how “Over-the-DS Fast BSS Transition” works. We will use the same topology as shown below.
Originally Client is associated to LAP2 & then roam to LAP1.One thing you have to understand is the two APs communicate with each other over the DS (distribution system) & hence called it “Over-the-DS fast BSS transition“. So you have to capture that communication over the wire. At this time I have enabled “Over-the-DS FT” support on the WLAN.
3850-1#show wlan id 22 WLAN Profile Name : MRN-EAP ================================================ Identifier : 22 Network Name (SSID) : MRN-EAP Status : Enabled Broadcast SSID : Enabled . 802.1x authentication list name : MRN-DOT1X Security 802.11 Authentication : Open System Static WEP Keys : Disabled 802.1X : Disabled Wi-Fi Protected Access (WPA/WPA2) : Enabled WPA (SSN IE) : Disabled WPA2 (RSN IE) : Enabled TKIP Cipher : Disabled AES Cipher : Enabled Auth Key Management 802.1x : Enabled PSK : Disabled CCKM : Disabled FT dot1x : Enabled FT PSK : Disabled PMF dot1x : Disabled PMF PSK : Disabled FT Support : Enabled FT Reassociation Timeout : 20 FT Over-The-DS mode : Enabled PMF Support : Disabled PMF Association Comeback Timeout : 1 PMF SA Query Time : 200
I have simply configure a monitor session on my 3850 to capture this “Over-the-DS” communication & at the same time sniffing on CH36 (where LAP1-target AP) operates. Here is the 3850 monitor session configs where G1/0/2 is LAP2 connected switchport & G1/0/3 is connected to PC running wireshark monitoring PC’s Ethernet NIC.
3850-1# monitor session 1 source interface Gi1/0/2 monitor session 1 destination interface Gi1/0/3
Here is the “Over-the-DS” capture looks like. As you can see below there are two action frames [ you can filter it in wireshark suing (wlan.fc.type == 0)&&(wlan.fc.type_subtype == 0x0d) display filter). Here is the FT Action Request frame sent by the STA address (04f7.e4ea.5b66) to the target AP address of LAP1’s BSSID (64a0.e7af.474e) under fixed parameters. You can see in the original 802.11 wireless headers source address is the client MAC & destination address is LAP2’s BSSID (2c3f.382a.b12e). In other words this FT Action Request frame is going to target AP via the original AP.
LAP2 (192.168.20.166) will encapsulate original wireless frame onto CAPWAP & send to WLC management address (192.168.20.1) as CAPWAP Data frame (Dst Port UDP 5247).
You can see RSNIE, MDIE & FTIE information elements in this frame. MDIE has “FT over DS” bit set to 1 indicating it is using “Fast BSS transition over DS” mechanism. FTIE include SNonce, R0KH-ID as well.
In response to FT Action Request frame, Target AP (LAP1 in this case) send a FT Action Response frame. Here is that frame. You can see in this frame as well STA address (04f7.e4ea.5b66), Target AP Address (64a0.e7af.474e), action code “FT Response” with status code “Successful“.
In the 802.11 wireless header, source address is 2c3f.382a.b12e which is LAP2 & destination address is 04f7.e4ea.5b66 indicating response is coming via original AP (LAP2).
In this frame as well you can see RSNIE, MDIE & FTIE information. In FTIE you can see ANonce, SNonce, R1KH-ID & R0KH-ID
Now here is the wireless sniff on CH36 looks like (target AP operating frequency). As you can see there are “Re-association Request” & “Re-association Response” frames (#437 & 439). Timing wise you can see the FT occur within 88ms (time from FT Action Request frame to Re-association Response frame). Here is the detail view of “Re-association Request” frame. This frame sends by client (04f7.e4ea.5b66) to target AP,LAP1 (with BSSID:64a0.e7af.474e). This is an over the air communication. As you can see it list the current AP(2c3f.382a.b12e) which is LAP2. FTIE includes MIC, SNonce, ANonce, R1KH-ID, R0KH-ID information.Then Target AP send the “Re-association Response” frame with status code “Successful” Here is the detail view of “Re-association Response” frame. FTIE includes ANonce, SNonce, R1KH-ID, R0KH-ID & GTK for broadcast/multicast encryption.Here is the summary view of Over-the-DS Fast BSS Transistion frame exchange that we described earlier.(page 271 of CWSP Official Study Guide)References
1. LAP2-LAP1-Over-DS (Over the DS wired frame capture)
2. iphone5-EAP-FT-over-DS-ch36 (Over the air CH36 wireless frame capture)
3. CWSP Official Study Guide – Chapter 7
4. 802.11r, 802.11k, and 802.11w Deployment Guide, Cisco IOS-XE Release3.3
1. CWSP-802.11 Roaming Basics
2. CWSP-802.11r Key Hierarchy
3. CWSP-802.11r FT Association
4. CWSP-802.11r Over-the-Air-FT
5. CWSP-4 Way Handshake
6. CWSP- RSN IE
Morning Nguyen said:
do you have the document about the relationship between 802.11R and 802.11X? If yes, can you share?
I mostly used IEEE-802.11-2012 standard & CWNP reference books for these post.
Morning Nguyen said:
do you have the document about the relationship between 802.11R(Roaming) and 802.11e(Qos)? If yes, can you share?
Same go to this as well, IEEE 802.11-2012 & CWNP study guides.
Brilliant quality on this site!
Hi, do you have a recommendation for over-the-DS or over-the-air 802.11R? The environment is a large environment with centralized WiSM-2 controllers. My first thought is over-the-air to reduce traffic (and delays) back to the controllers.
enable 11r with carefull assessment of client devices, as many clients who does not support 11r will fail connecting to a WLAN if you enable 11r on that.
In the action request packet capture I don’t understand why are the destination and receiver addresses are the same ? Shouldn’t the receiver address be AP1 and the destination address be AP2 for AP1 to receive the wireless traffic and then send it wired to AP 2. How will AP 1 process the traffic when its MAC address isn’t inserted in the 802.11 Frame.
Is there any deauth frame when client moves to another AP in roaming. pls help me on this.
Rodrigo Osorio said:
I am just wondering where do you see if FT is required or optional on pcap, and how should it impact on 4-way handshake?
Capability is advertised in Information Element in certain management frames (beacon,etc). Certain legacy client having trouble connecting to a SSID when you enable FT on that SSID
Thanks Rasika for this post.
Have you enabled FT (802.11r) in your production network? Enabled or adaptive? is it over the DS?
What about devices that don’t support 802.11r? Any compatibility issues? what devices are most problematic when it comes to FT?
I am still undecided whether i should enable it in our environment. We are on WLC code 184.108.40.206 and 220.127.116.11. I am sure we will have non-802.11r devices in our environment.
Thanks in advance
I haven’t enable FT on my production (running on AireOS 8.5.x). However with 9800 migration, I am planning to enable it and see if we come across any compatibilty.
Plan is to enable “Over the Air” and test it out