For over 13 years, I’ve been teaching Wi-Fi using the same graphic to connect the client to access the point association process. With all the changes in 802.11b, a, g, n, and now ac, we use the same approach to allow a client to choose which access point to join. (Hopefully, in the future, we’ll get something from the IEEE to help in this old archaic process…)
But for now, we are stuck with this association process that has been around since 802.11 Classic. (Like Coke Classic… some call it 802.11 prime) – In my association graphic, I just picked the color green since the other colors in the palette my graphic designer used at the time were already taken. And a diamond because it represents a decision in flowcharting.
The “Green Diamond” process in the client device’s Wi-Fi NIC decides which access point to choose. This process happens when the NIC is first fired up and periodically as the client device searches for a better option.
Another term I’ve used to describe the 802.11 association process is:
“Association is to Wi-Fi what a link-light is to Ethernet.”
It might help to remember this short saying when troubleshooting. Just like Ethernet, if you have a link-light, you normally troubleshoot UP the stack. But just because you have a link-light doesn’t mean the entire network works. It just gives you some information to help diagnose where the problem isn’t.
Just a quick side note for those using packet analysis to look at the association process. Remember, when sniffing for a specific MAC address, Beacons are not sent to any device but instead sent to a broadcast address (FF:FF:FF…); thus, you won’t capture them when focusing on a specific client device. This same tip holds that you’ll miss Broadcast and Multicast traffic whenever you are filtering on a single MAC address.
Decoding the “Green Diamond”
Wouldn’t it be nice to look inside our client devices and see what their “Green Diamond” algorithm is doing to choose between access points? But client device manufacturers hold this information very close to the chest. These trade secrets, or secret sauce, are the bane of all Wireless LAN Professionals. It would be nice to know what is going on and how the decisions are being made. Then, we could design our wireless networks to meet those specific goals.
But alas, this is not to be. So instead, we are stuck with capturing packets from client devices, putting client devices in specific controlled environments, anything to try to figure out based on external analysis what those decisions are inside clients.
Peter Thornycroft did a great job at the last Aruba AirHeads Conference in Las Vegas in his presentation on Client Device Behavior – I did a review of this session in a previous post.
Our industry needs a centralized shared information database about how client devices work when in certain situations, what their various thresholds and algorithms are. I’m sure the vendors themselves won’t want to share this information freely. But I am requesting readers of this blog to share what information they might have gleaned from packet analysis and observation. Perhaps we can build a database to share client behaviors and make better wireless networks as a group.
Is anyone interested?
