For over 13 years I’ve been teaching Wi-Fi – all using the same graphic to talk about the client to access point association process. With all the changes in 802.11b, a, g, n and now ac, we are still using the exact same process 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) – I my association graphic I just happened to pick the color green, since the other colors in the pallette my graphic designer used at the time were already taken. And a diamond, because it represents a decision in flow charting.
The “Green Diamond” is the process in the client device’s Wi-Fi NIC that makes the decision on which access point to choose. This process happens when the NIC is first fired up, as well as 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 one 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 true whenever you are filtering on a single MAC address, you’ll miss Broadcast and Multicast traffic.
Decoding the “Green Diamond”
Wouldn’t it be nice if we could 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 so nice to actually know what is going on, 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 certain controlled environments, anything to try and 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.
What our industry needs is 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 as a group we can build a database to share client behaviors and together build better wireless networks.