Over the past few years, the number of times that I’ve had to do wireless captures and sniff the air like a hound dog has increased. With that increase, the amount of 802.11ac captures has gone up as well. This is of no surprise as every vendor on the market is touting 802.11ac as the new Super Bass-O-Matic 76. With this need for capturing more and more 802.11ac frames, Savvius has stepped up to the plate with their new 802.11ac adapters.

I wanted to have some fun capturing some 802.11ac frames with these new adapters, but I also wanted to see what would happen if I use my older Savvius 802.11n adapters to capture 802.11ac frames.

Lets take a look…

When doing 802.11ac captures you’ll want to make sure your using a USB 3.0 port for data transfers. These theoretically allow up to 5Gbps, but with real world testing showing speeds achieving just over 2Gbps. Plenty of throughput for any capture no doubt, but it is possible that you might be missing frames if using a USB 2.0 port (480Mbps max).

To do this test, I have my Samsung Galaxy S6 (802.11ac) connecting to my Cisco 2702i 802.11ac Access Point. I configured the AP to operate on channel 140 @ 20MHz.

With Omnipeek, I setup both adapters to run at the same time. The new card scanning channel 140 with 802.11ac, and the old adapter scanning channel 140 with 802.11n. This is a nice Omnipeek feature, being able to scan different protocols at the same time with different adapters.

Once my capture was complete, I created a filter within Omnipeek to only show frames from the MAC Address of my Galaxy S6 device. I also added entries in the Name Table for my Access Point, phone, and router in order to make things easier to see.

Here is a screenshot of the 802.11ac adapter capturing 802.11ac frames looks like. Everything appears to be normal as it should be.

Here is a screenshot of the 802.11n adapter, trying to capture 802.11ac frames. As you can see, it is only able to hear 802.11 Control frames.

An 802.11ac preamble is basically the same as an 802.11a preamble, which allows for CCA to operate with backward compatibility to 802.11a/n devices operating in 5GHz. When a device that is not the intended receiver hears the 802.11ac preamble, it knows the duration of how long the frame will be transmitting over the air, and will stay quite for this period of time.

Here are several images of the types of frames that each adapter heard. As you can see, an 802.11n adapter simply cannot decode any 802.11ac data frames, which means your out of luck if your trying to accurately determine things like retransmission percent etc.

I decided to remove my earlier filter that I created within Omnipeek, which was set to only showing transmit/receive data from my Galaxy S6.

I then lined up a group of frames from both captures to compare them side by side, and what you’ll notice is that the ‘data frames’ on the 802.11ac adapter show up as CRC Management frames on the 802.11n adapter.

The source and destination MAC Address of each of these ‘error frames’ are randomized, but we know by seeing the frames side by side that they actually represent the 802.11ac data frames between my phone and AP. This is confirmed by the received Absolute Time column.

I am still digging into the 802.11ac Survival Guide by Matthew Gast, so I’m not able to intelligently state why the frames show up as Management CRC’s on the 802.11n adapter. My best guess at this point is that its simply the default way Omnipeek marks a frame that it doesn’t understand. If you are interested in learning more on 802.11ac, you can purchase the book or read it online at this site here.

I hope you enjoyed this post, and please feel free to leave a comment below.

-Nolan