Back to Home Back to Archive

WiFi Client Capabilities

clients.mikealbano.com

If it's not obvious, the capabilities of clients using the network directly impacts the WiFi design. Among the swath of 'optional' support for various 802.11 protocols and standards are:
  • Radio chains, spatial streams and channel-width; contributing to max achievable data-rate. (MCS)
  • Frequency (2.4 vs. 5GHz); affecting client-count per AP radio and all sorts of other design implications.
  • Supported bands, or channels; affecting channel-planning. 
The last one is what I'm primarily focused on documenting. If you'd like to skip the 'reasons' part, head right to the Project section below.

UPDATE: If you've already captured packets, you can use the web-based tool at: http://randomizer.mikealbano.com/

Background

How many 'cells' you can get into a physical area is directly related to the amount of spectrum available. Spectral re-use in a high-capacity environment is a much bigger issue if you have 8 20MHz channels, instead of 24. When capacity planning, you always have to balance the "what if..." scenario's.
  • What if the clients are 2.4 only?
  • What if the clients don't support UNII-2/2e?
  • What if the clients don't support 40MHz?
  • What if the clients don't support 802.11<alphabet>?
There's plenty of discussion around DFS, WiFi Alliance certification and how we ended up in this train-wreck situation of such varying client-support, but I'll leave that subject for those much better at articulating it than I. @wirednot wrote up a great article on this here.

Goal

My primary goal here is to answer the question "which client's support which channels?". For a number of reasons, it's unusual to find the answer to this in vendor documentation. Even if documented, it'd be nice to have an easier way of verifying support and a public document for reference.
I'd like to promote sharing the results on clients.mikealbano.com, or wherever the public repository of this data ends up. I realize a spreadsheet may not be the best format for this, but for now it'll do.

I've created a Python script to assist with:
  1. Capturing frames 
  2. Identifying Association Requests
  3. Randomizing the data (BSSID, ESSID & Client MAC)
As an example, if you download the pcap file from that spreadsheet for my Moto-X phone (direct link) you'll see I have verifiably associated to each channel that the device advertises support for in it's Association Request Information Element. You'll also notice the data has been randomized.
Note: You can see from the color chart, Green means verified association on all supported channels. If the only source of information I have is via 'Information Element' (see below) the color in the sheet will reflect that.
Info Source is listed towards the right-most columns of the sheet.

Project

The script is hosted here: https://github.com/mike-albano/frame-randomizer

The web-based tool (for randomizing already captured data) is here: http://randomizer.mikealbano.com/

For example usage, and dependencies, see the README. The TLDR version is this....
  • Scapy is an awesome tool. Modifying/crafting/injecting packets is extremely useful (Here's a great intro to it) and I use it here for randomizing data & writing new pcap files.
  • Getting it to work on Linux is simple. 
  • Getting it to work on OSX is not.
For those wanting to contribute, but do not use Linux or don't want to battle OSX & macports, the web-based tool should work. Reach out to me direct, or @mike_albano if it doesn't.

The usual disclaimers, like I'm just learning Python and it's probably full of errors, apply.