Will we be able to capture 802.11ax frames?

This blog post started out as a question to Jim Vajda on Twitter, but I quickly realised there were too many facets to the question for 240 characters. So I thought I’d lay my thoughts out in a blog post instead.

While listening to Jim on the The Wireless Pubcast (ep 16) the topic of capturing frames in an 802.11ax world was brought up. Several distinguished people in the Wi-Fi community have suggested that we won’t be able to capture frames using anything but the associated AP. Jim talked this through with the strange gentlemen from the Pubcast and this is my counter opinion/confusion on the topic.

I should start out by stating I have not done much research into this new amendment yet and could be missing something very obvious. I do know a thing or two about 802.11 protocol analysis but without any conference drinks to chat this over I decided this post was a good outlet for my thoughts and a place for people to edcuate me if they disagree.

The general consensus around 802.11ax capturing is that, as the AP performs all scheduling of OFDMA transmissions in both upstream and downstream directions, it is the only device with all pieces of the puzzle required to dissect the multiple signals that will be transmitted simultaneously.

I think this concept relies on an incorrect core assumption – that we want to see all of the frames from every client.

Stepping back from 11ax for a second, good 802.11 troubleshooting using protocol analysis requires you to capture the frames as close to the client as possible. You might also twin this with a capture from the AP at the same time but in my many years of 802.11 protocol analysis I’ve rarely found the infrastructure side necessary until data goes missing.

When you’re capturing close to a client a) you only typically care about the frames between that one client and the AP, and b) you’re going to miss frames from other clients regardless of the 802.11 amendment you’re using, because of each clients varying position in the coverage cell.

So now lets change that core assumption to – we want to see frames between the client and the AP.

Does this change the feasability of 802.11ax captures? This is my question to Jim, Peter, Gjermund and others far more informed than I am on this new amendment.

Just to bore you further and because I like the sound of my own voice writing typing, here are further thoughts from me on the discussion.

The client will receive everything it needs to from the AP in order to decode/encode its portion of an OFDMA tranmission. If my capture device is close to the client (inches) would it not also receive this information in order to decode those transmissions in both directions?

Maybe on the upstream transmissions the client that we are close to will be transmitting the data in a way that would converge into a decodable signal at the AP’s location but be unreadable at the source. This is something I am unsure about given the various information I’ve seen on how OFDMA and multiple radio’s works. But given most clients only have 1-2 radio’s in them I don’t think this will be true. And the closer to the AP the client is the less impact this would have, so for troubleshooting anything other than signal strength (which doens’t need troubleshooting) and roaming, just take the troubleshooting closer to the AP.

Of course to make this possible the capture drivers are going to need to understand that we want to see information that isn’t for the capture device. But that is the case now and the purpose of Passive/Monitor mode drivers. Perhaps a capture driver could use the scheduling information in the Trigger frame and speculatively attempt to decode as many Resource Units (RU’s) as possible. For the ones it can’t decode it could give us an empty frame to demonstrate this. After all it should know from the scheduling the Tx address, Rx address, and the length of the frame.

Or maybe we have to tell the capture driver the MAC of the client we want to mimic so that it just calibrates itself to those RU’s, just as the client has to to receieve the data. Something that could hinder this is WPA3’s requirement to use 802.11w (Management Frame Protection), but I’ve not seen that mentioned as a factor in these conversations, and it will take a long time for WPA3 to be the most common security method on WLAN’s.

I think it is too early to give up on 802.11ax capturing. And if we give up, why would our suppliers go to the effort of developing these tools?

There are two more important considerations that give me hope for 802.11.ax capturing.

Firstly, 802.11 is a Layer 1 & 2 protocol. And even then it doesn’t fully satisfy Layer 2 functionality either. Most (if not all) the information we need about the data’s journey to and from the Distribution System (DS) is in Management and Control frames, or a header attached to the Data itself. We don’t need to decode the data to troubleshoot an 802.11 connection. If there is a problem with the data itself then a) you can capture that at the controller and b) it is not an 802.11 issue.

Secondly, OFDMA is not 802.11ax. It is a single function of that amendment. 802.11ax still supports OFDM (not A) and our 11ax stations will continue to use it as and when appropriate. So there will still be a lot of the communication we can capture. Yes, this will probably reduce as the proportion of 11ax clients in a cell increases, but I think the consensus is that OFDM will still be used most of the time until cells gets congested enough that the efficiency gains of simultaneous transmissions outweighs the overhead brought by this complicated scheduling.

I am looking for peoples opinions on the above and whether they’ve considered the factors I’ve raised, so please do comment below or reach out to me with your thoughts.