802.11r Fast BSS Transition

This is not an in-depth post on 802.11r. Instead, it is just about one piece of the 802.11r puzzle that will hopefully remain in my brain long enough for certification and beyond!

For a detailed review of 802.11r, I suggest Devin Akin’s excellent white paper:

And, Rasika Nayanajith’s excellent blog posts:
802.11r FT over the DS and 802.11r FT over the air

I was having trouble understanding the difference between two of the wpa_cli commands ft_ds and roam. The wpa_cli is the WPA command line interface for interacting with wpa_supplicant (as a station in client mode).

The wpa_cli command help gave me a clue, but wasn’t giving me the full story:
ft_ds = request over-the-DS FT with
roam = roam to the specified BSS

So I setup a Cisco testbed with a WLC2504 and two 1602 APs. Then setup a LANforge-WiFIRE test system with a client to roam between the two APs and with a separate monitor interface for packet captures.

With the wpa_cli ft_ds command I obtained the following capture:

With the wpa_cli roam command I obtained the following capture:

Staring at the packet captures and re-reading the following helped me see the difference:
• STA communication to the target AP via current AP using FT Action frames.
• STA communicates directly with the target AP using FT Authentication frames.

The command wpa_cli ft_ds dc:a5:f4:ff:4f:af initiates a FT Request (Action Frame) from the station 00:0e:8e:43:3a:71 to the target AP dc:a5:f4:ff:4f:af via the current AP dc:a5:f4:f3:ce:9f that the station is connected to.

The command wpa_cli roam dc:a5:f4:ff:4f:af initiates a FT Authentication from the station 00:0e:8e:43:3a:71 over the air directly to the target AP dc:a5:f4:ff:4f:af.

Both commands initiate an 802.11r Fast BSS Transition, but the distinction between the two is important to understanding how clients will transition. Using this command is a helpful way to test 802.11r wireless network setups and verifying that when it comes time for real clients to roam, you will have some confidence that it will work as expected.


Comparing USB-to-Wifi Adapters

After purchasing a handful of the Eye P.A. supported USB-to-Wifi adapters to see how well they could capture wifi traffic when compared to a dedicated PCI-E wifi NIC, I found that some of the adapters were better than others but none as good as the dedicated NIC.

Test Setup: Using a LANforge CT523b wifi traffic generator and an Aruba 315 AP setup on channel 100, I setup a single wifi client for a 10 second over-the-air UDP download at 500Mbps with a 1472B payload size. A second wifi NIC in monitor mode was used on the LANforge system to perform a 15 second wifi capture to compare against each USB adapter capture using the Eye P.A. capture tool.

The first 3 rounds were control tests to see how well the dedicated NIC would capture wifi traffic:

Round 1
    wiphy2 RX Pkts 217788
    wlan2 RX Pkts 424631
        captured 109306
        dropped 106672
Round 2
    wiphy2 RX Pkts 214776
    wlan2 RX Pkts 424618
        captured 109218
        dropped 106119
Round 3
    wiphy2 RX Pkts 215087
    wlan2 RX Pkts 424568
        captured 108803
        dropped 107875

The next 5 rounds compared different USB adapters to the dedicated NIC wifi capture:

Round 4 – adding capture device Edimax 7833
Eye P.A. captured 8730 pkts with 4240 data frames
    wiphy2 RX Pkts 213697
    wlan2 RX Pkts 424569
        captured 114925
        dropped 102400
Round 5 – capture device Linksys 6300
Eye P.A. captured 4970 pkts with 9 data frames
    wiphy2 RX Pkts 213462
    wlan2 RX Pkts 416002
        captured 109170
        dropped 106777
Round 6 – capture device Asus AC68
Eye P.A. captured 7240 pkts with 3276 data frames
    wiphy2 RX Pkts 138598
    wlan2 RX Pkts 241384
        captured 91625
        dropped 65146
Round 7 – capture device Asus AC68
Eye P.A. captured 7957 pkts with 4269 data frames
    wiphy2 RX Pkts 213985
    wlan2 RX Pkts 424611
        captured 108988
        dropped 109630
Round 8 – capture device Comfast Realtek 8812
Eye P.A. captured 6560 pkts with no data frames captured
    wiphy2 RX Pkts 226968
    wlan2 RX Pkts 424522
        captured 111036
        dropped 58637

Next steps are to try this test again under Linux or modify some of the other test setup to see if there is any benefit. Also I’d like to try the test against other APs and wifi modes, but the overall result appears to be that the USB-to-wifi adapters are not a good as a dedicated wifi NIC…but you probably already knew that!

Hidden SSIDs

How hidden are hidden SSIDs? Hidden SSIDs are only “hidden” because the AP doesn’t put the SSID (wlan_mgt.ssid) in the Beacon (wlan.fc.type_subtype==0x0008) and that’s it.



However, if any device that already has the SSID configured, sends an
Association Request (wlan.fc.type_subtype==0x0000) or a
Probe Request (wlan.fc.type_subtype==0x0004), then the SSID is not hidden anymore.


Association Request


Probe Request

As demonstrated here, if you’re running a wifi capture and happen to sniff these two requests or you happen to get the Probe Response (wlan.fc.type_subtype==0x0005), then you get the SSID!!!


Probe Response

It’s kinda like telling your toddler “Don’t tell Mommy we got her a surprise birthday cake!” If anyone asks how her day was, it only takes about 5 seconds for her to blurt out “We got cake!”

The takeaway here is…don’t bother hiding your SSID…there are better ways to secure your wlan network as well as surprise your loved ones with cake!!!

Measuring Beacon Interval

Here is my attempt to take a wifi capture file and use the IO Graph feature in Wireshark to measure the beacon interval as well as see how beacons behave with wifi traffic.

The wifi beacon from the AP is configurable and the default is usually around 100ms. But, this is more accurately described in the CWNP article:

In the Wireshark capture, I can filter on beacons by using wlan.fc.type_subtype==0x0008 and see the time delta from the previous displayed frame as 0.1025 seconds then 0.1023 seconds then 0.1024 seconds and so on which makes sense…but a graph would be much better to visualize what is happening.

Starting with the how-to I found here,
I started building a graph for beacon intervals. Going to Wireshark – Statistics – IO Graphs brings up the IO Graphs window. The default graph is for All Packets, but you modify this with a display filter and then add Y-axis filters if needed. After adding the entries for time deltas for Min/Max/Avg beacons, I also added a display filter for QoS Data to show when traffic was being transmitted.
Wireshark · IO Graphs · wifi-capture_045
The default time scale is too big to see what is going on, so next I set the Interval to 100ms.

Wireshark · IO Graphs · wifi-capture_040
Here the time scale to too compact, so next I zoom in.

Wireshark · IO Graphs · wifi-capture_041
Now you can see that the Max Beacon Interval before traffic starts and after traffic stops is measurable at 100000 microseconds or 100ms. There is a big gap at 10.24 seconds where the beacon was delayed for some reason, but I haven’t figured that out yet. When traffic starts, the beacon intervals are scattered among the traffic carrying frames because now there is more contention for air time.

Wireshark · IO Graphs · wifi-capture_043
Zooming in further shows how closely yet separate the beacons are from the data traffic.

Wireshark · IO Graphs · wifi-capture_044

Now with the original goal accomplished, measuring the beacon interval, this post also reveals that beacon intervals can change as air time becomes limited. Another cool trick is that you can also measure the beacon interval with this tshark command:

tshark -r wifi-capture.pcap -q -Y wlan.fc.type_subtype==0x0008 \
-z io,stat,0.01,”AVG(frame.time_delta_displayed)frame.time_delta_displayed” \
|grep -v “0.000000”

Partial output of this is:

| IO Statistics                                                    |
|                                                                  |
| Duration: 29.39 secs                                             |
| Interval:  0.01 secs                                             |
|                                                                  |
| Col 1: AVG(frame.time_delta_displayed)frame.time_delta_displayed |
|                |1         |                                      |
| Interval       |    AVG   |                                      |
|---------------------------|                                      |
|  0.10 <>  0.11 | 0.102500 |                                      |
|  0.20 <>  0.21 | 0.102273 |                                      |
|  0.30 <>  0.31 | 0.102406 |                                      |
|  0.40 <>  0.41 | 0.102391 |                                      |
|  0.51 <>  0.52 | 0.102361 |                                      |
|  0.61 <>  0.62 | 0.102445 |                                      |
|  0.71 <>  0.72 | 0.102400 |                                      |
|  0.81 <>  0.82 | 0.102398 |                                      |
|  0.92 <>  0.93 | 0.102402 |                                      |
|  1.02 <>  1.03 | 0.102402 |                                      |
|  1.12 <>  1.13 | 0.102409 |                                      |
|  1.22 <>  1.23 | 0.102393 |                                      |
|  1.33 <>  1.34 | 0.102381 |                                      |

Thanks for taking a look at this post!


Capture The Frames

When MetaGeek announced that they would support wifi capture from within Eye P.A., I quickly scanned the list and purchased the Edimax EW-7833UAC AC1750 Dual-Band Wi-Fi USB 3.0 Adapter, Supports Windows 7/8/8.1/10, Mac and Linux, because it was only $33.70 on Amazon and Eye P.A. is a fantastic visualization tool for analyzing wifi events. My company had previously purchased the software-only license for Eye P.A., but this adapter also supports Linux which is great for using horst and wireshark among the many free tools available.

Here is MetaGeek’s list as of July 2018:
Windows: 802.11ac adapters

Here is the full list of compatible adapters for 802.11a/b/g/n/ac packet capture built into Eye P.A.:

Linksys WUSB6300 (recommended)
ALFA Network AWUS1900
EnGenius EUB1200AC
D-Link DWA-182 rev C1
D-Link DWA-192
TP-LINK Archer T4U v2
TP-LINK Archer T4UH v2
Edimax EW-7822UAC
Edimax EW-7833UAC
Windows: 802.11n adapters

Linksys AE2500
Linksys AE1200
Netgear A6200 WiFi Adapters
RiverBed AirPcap Nx

Installing and capturing wifi with the EW-7833UAC via Eye P.A. in Windows was easy enough.

My Windows setup…

I did have a bit of trouble getting the EW-7833UAC adapter to work in Ubuntu 16.04, but I was eventually able to enable monitor mode and get horst and wireshark to start scanning and sniffing. At first I went to the Edimax site to download the driver version because Ubuntu is running kernel 4.13, but the make errored out. I also tried the 4.3.21 driver just to see, but make also errored out.

Then I found a post on the Ubuntu forums that sorted the driver out:

sudo apt-get update && sudo apt-get install git dkms
git clone https://github.com/zebulon2/rtl8814au.git
cd rtl8814au
gedit dkms.conf

Replace line 1 MAKE=”‘make'” with
MAKE="'make' all KVER=${kernelver}"
save and exit gedit, then
sudo dkms add ./rtl8814au
sudo dkms install rtl8814au/4.3.21

However, I was not able to put the device into monitor mode with:
sudo iw dev wlx123 set monitor

and had to use
sudo iwconfig wlx123 mode monitor

Now I can sniff, capture and analyze wifi with my dual boot laptop and be ready to study wifi wherever and whenever necessary.

My Linux setup…

By the way…if you haven’t already done so, go get some wifi coloring rules from these guys or make your own!





Begin Wifi Certification

Wifi Certification is something that I’ve been thinking about pursuing for a while now. There are many facets to wireless networking that I think I know, but I would like to know more and actually study the concepts. After listening to WLAN Pros podcast #153, I too asked myself, “Why haven’t you done it yet?”

The last certification I obtained was the CCNA almost 9 years ago to the day of this writing. There must be something about July that inspires me to get more done before the end of the year! Anyway, the CCNA cert was useful in the sense that I was able to configure new test scenarios and be more confident using Cisco gear, however after 3 years I decided not to renew because my overall job did not require the certification and higher level certifications were not tempting me.

The CWNE certification however appears to me to be a potentially great investment of time given the heavy focus on wireless test gear that my company is now providing. Furthermore, I would like to better understand the concepts behind the wireless specifications and features. I have first hand experience with many wireless networking features and would like to find out more. The amount of time I have to devote to study is limited, but my day job involves using wireless and testing wireless and I believe that in the next 6 months I should be able to make significant progress toward the CWNA as a starting point. So, here we go…