Wouldn’t is be nice if there was a simple to use troubleshooting tool that could quickly monitor the initial 802.11 frame exchanges between a Wi-Fi client that is trying to connect to an access point?
Sure, anyone can do this onsite with an 802.11 protocol analyzer, or even possibly remotely. But that method requires WireShark or a commercial third-party solution, which require the proper filters to be created when troubleshooting on a single client MAC address.
Some WLAN vendors offer a way to look at the client/AP connectivity exchange if you SSH into the WLAN controller and type a series of complex commands from the CLI and then try and decipher the information. Yuck!
What we need is an integrated client connectivity-troubleshooting tool that can be run from a network management server. Well guess what? Aerohive has just what you need. Without a doubt, one of the most popular troubleshooting tools used by Aerohive customers and partners alike is the HiveManager Client Monitor tool.
Client Monitor gives a Wi-Fi administrator the ability to view the layer 2 frame exchanges that establish a client’s connection to an access point. As shown in Figure 1, Client Monitor can watch the exchange between a client’s MAC address and all HiveAPs. Client monitor also has the ability to watch the exchange between a client and a single access point.
It takes all of twenty seconds to setup and configure a Client Monitor, which can then run indefinitely.
Whenever the chosen client attempts a connection, the Aerohive access points forward the brief client exchange information via CAPWAP to HiveManager. The information can be observed in real time, and can also be exported to a CSV text file. As shown in Figure 2, the “staring-eye” icon is an indication that a Client Monitor has been setup for the shown client MAC address.
Don’t worry; Aerohive and HiveManager are not watching you. You are watching the client.
One of the best uses of Client Monitor is to troubleshoot problems with both PSK and 802.1X/EAP authentication. PSK authentication (also known as WPA2-Personal authentication) is quite simple to troubleshoot with Client Monitor.
Let’s first take a look at a successful PSK authentication in Client Monitor. In Figure 3, you can see the client associate with the AP and then PSK authentication begins. Because the PSK credentials matched on both the access point and the client, a pairwise master key (PMK) is created to seed the 4-Way Handshake. The 4-Way Handshake process is used to create the dynamically generated unicast encryption key that is unique to the AP radio and the client radio.
Client Monitor shows that the 4-Way Handshake process was successful and that the unicast key known as the pairwise transient key (PTK) is installed on the AP and the client.
The Layer 2 negotiations are now complete, and it is time for the client to move on to higher layers. So of course the next step is that the client obtains an IP address via DHCP. If the client does not get an IP address, there is a networking issue and therefore the problem is not a Wi-Fi issue. Most likely there is an improperly configured VLAN.
Perhaps a Wi-Fi admin gets a phone call from an end-user that cannot get connected using WPA2-Personal. The majority of problems are at the physical layer, therefore, Wi-Fi trouble-shooting 101 dictates that the end-user first enables and disables the Wi-Fi network card. This ensures the Wi-Fi NIC drivers are communicating properly with the operating system. If the connectivity problem persists, you can then create a quick Client Monitor for the end-user MAC address and then monitor the attempted connection with an access point.
In Figure 4, you can see the client associate and then start PSK authentication. However, after several attempts, the 4-Way Handshake process fails and the access point then sends a deauthentication frame to the client. There is no attempt by the client to get an IP address because the Layer 2 process did not complete.
If you observe the connectivity failure in Client Monitor as shown in Figure 4, the problem is almost always a mismatch of the PSK credentials. If the PSK credentials do not match, a pairwise master key (PMK) seed is not properly created and therefore the 4-Way Handshake fails entirely.
The passphrase that is used to create a PSK can be 8-63 characters and is always case-sensitive. The passphrase could possible be improperly configured on the access point, however, the majority of the time, the problem is simple: the end-user is incorrectly typing in the passphrase. The administrator should make a polite request to the end-user to retype the passphrase slowly, which is a well-known cure for the fat-finger disease.
Another possible cause of the failure of PSK authentication could be a mismatch of the chosen encryption methods. An access point might be configured to only require WPA2 (CCMP-AES), which a legacy WPA (TKIP) client does not support. A similar failure of the 4-Way Handshake would occur.
As you can see, troubleshooting PSK authentication with Client Monitor is an easy task mainly because PSK authentication is a relatively simple process. What about troubleshooting the more complex method of 802.1X/EAP authentication? If deployed properly, 802.1X/EAP provides more robust security than PSK authentication. However, because 802.1X/EAP is more complex, there are many possible points of failure. The good news is that Client Monitor really shines as a troubleshooting tool when analyzing 802.1X/EAP connectivity failures.
Stay tuned for my next blog where we discuss troubleshooting 802.1X/EAP authentication with the HiveManager Client Monitor tool.