The 802.11 Block Acknowledgement frame (BlockAck) is a powerful frame to predict the data flow in a WiFi network, both when the data frames are visible in a frame capture and not.

Let us use Wireshark and the I/O Graph to visualize it

If you really want to dig into 802.11ax frame formats, a wireless capture (pcap) and Wireshark is a great way of doing it.
In this blog, I will dig into the preamble of an 802.11ax frame and point out several items to look at. I will also find information from the first part of the preamble, the legacy preamble

When interpreting wireless captures it is not always easy to capture the data frames because they are usually sent with complex modulation and coding schemes. The quality of the capturing NIC is also important.
But management and control frames are easier to capture because they are sent with legacy frame format (802.11b/g or 802.11a).
The BlockAcknowledge frame (BA) is the frame used by the receiving station to send back to the transmitter the status for what the receiver has received without corruption.
The last two years I have seen two different behaviors for the BA, one according to the standard and the other with a strange behavior
Let us dig into it

Frame capturing of 802.11frames, WiFi, is a important task in managing and troubleshooting WiFi networks. In the earlier days there were different methods of capturing these frames, but now when 802.11ax (WiFi6) is in the marked the variety in methods is limited.

Capturing the management and control types of frames that normally use legacy frame formats like 802.11b/g in the 2.4GHz band and 802.11a in the 5GHz is still easily done, but capturing the data frames with 802.11ax frame format is more tricky.

I will in this blog compare 802.11ax frame capturing using a Jetson Nano with Intel ax200 wireless NIC and a Cisco C9115-AXI in sniffer mode

This is a method of having a SpeedTest service available during AP on a stick survey (APoS), with only an AP, PoE battery, and a WlanPi available

This is probably described earlier, but I do it anyway

This week I was elected by the WiFi community to be the WiFi Awards Rookie of the Year 2020. I am very thankful to all the people who have voted for me and the WiFi Award committee to be one of the finalists.
The WiFi Award has been one of the main factors and motivation for all I have done in the last years. Why?

I have been selected as the finalist for two different awards for 2020, the Cisco 2020 IT Blog Award for Best Analysis and the Wi-Fi Award Rookie of the Year

I have written several blog articles regarding 802.11ax and OFDMA frame capturing with the NVIDIA Jetson Nano Developer kit as the method evolved the last months. Now it is time to make a blog article to bring this together, both for my self and others

I will mention the available methods and give some short keywords and useful links

I have in my short WiFi life thought when an 802.11 station (WiFi) does carrier detect it would detect all parts of an ongoing frame transmission on the channel and defer its own transmission because of that. But it seems my understanding has been wrong.

The last week’s online discussions has open my eyes to another look at the protocol and the importance of detecting the 802.11 preamble.

In this article I will write about the uniqueness of the 802.11 preamble, how important it is to detect it and how long it travels

Please, set your mind into an 802.11 station and think about what happens during the start of an 802.11 frame reception.
In the preamble there is a field called L-SIGNAL and one of the subfields is called Rate. If the rate indicates 6mbs the rest of the frame could be any of the available PHY types in the 802.11 standards.
In the 5GHz band, it could be either a non-HT, HT, VHT, HE SU, HE MU, MU Trigger-based, or HE ER frame format.
How will you differentiate between those types of frame formats, and receive and process it correctly?

No clue, read this article