Frame Exploration: Probe Requests
I briefly went over the frames used to connect a STA to a BSS in this post but I also wanted to show more details on what each of them contain. Since the Probe Request is the first frame to explicitly start the joining process we will start here. You can also look at other info about Probe Requests and other frames from my CWAP Notes section.
These are sent by the STA wishing to join a certain BSS and will request additional info about the network. However, the info contained in the request is that of the STA sending it. We will find a lot of information about what the client is capable of in this frame.
Ive included a visual representation of the mac header and frame control field to make it easier to see how this all works together.
.11 MAC Header
Frame Control field
Beginning with the info in the Frame Control field, here is a Probe Request I captured on my own network.
We see some information that will be useful when doing packet captures with a protocol analyzer. It is possible to filter out certain types of packets when using this field. Creating a filter for 0x4000 will create a filter for a Management Frame with a Subtype of 4 which is a Probe Request. If we wanted to filter out Action frames we could make a filter for a FCF with a value of 0xd000. Note the hex value is a combination of the version, frame type and frame subtype. Of course you can always use the cheat sheet from Semfio Networks.
Moving to the address fields we see 4 are present but only two are utilized. Since we are only transmitting from STA to AP there is only a need for two. In this scenario the AP is the RA/DA and the STA is the TA/SA.
Next we have the frame body. The primary function of this field is to give the AP enough info so it can make a decision on whether the STA can join the BSS. As you can see there is a bit of info but the AP mainly is concerned with basic rates. The other capabilities such as number of radio chains, and TxBF are nice but not a deal breaker.
Frame Body
Supported rates field expanded
HT Capabilities field expanded
VHT Capabilities field expanded
Of course we also have the VHT field since this is an .11ac device. Again something interesting (but not surprising) is the lack of support for 160MHz channels. I captured this from a Pixel 3a, the lack of support could be based on the fact its not a flagship device for cost savings or power savings by using a less capable chip.
As a side note, this highlights the need to understand what devices will be used in an environment before deploying a WLAN system. Another take away we can see is the lack of MU Beamformee support. In AC MU-MIMO was never really implemented in the field and it required a lot of variables to line up just right to make it happen. This is not the same as MU-MIMO in AX which uses OFDMA technology to break up the channel in to smaller channels or Resource Units while the former uses beamformed Spatial Streams to target individual clients with the intended signals while simultaneously nullifying the signals to the other clients in the transmission.
Combining the above information allows the AP to make an informed decision on whether or not the STA can join and what capabilities it might be able to leverage with it. Next post we will look at the Probe Response frame which contains the APs capabilities.
Comments
Post a Comment
Leave a comment...