Search

Recent Posts

Posts by Topic

see all
free-on-demand-webinars.png

Wi-Fi Troubleshooting: Guilty until Proven Innocent

by AirTightTeam on Sep 23, 2014

by Bhupinder Misra

Wi-Fi is usually installed last, after everything else in the network is already set up – switches, routers, servers, firewalls, VPNs, and the list goes on. It’s only natural that customers come to depend on their Wi-Fi provider to alleviate any network problems that arise during Wi-Fi deployments. More often than not, when things don’t work as they should, Wi-Fi is the obvious scapegoat even though the problems aren’t necessarily Wi-Fi specific.

In fact, I’ve come to expect this “guilty until proven innocent” rational. My job is to investigate, get to the root of the problem, and then propose a plan of action to remedy the situation. Such is the life of a troubleshooting Jedi! There’s never a dull moment, something is always happening.

Buggy Wi-Fi Client Implementation

I recently investigated an occurrence relating to the implementation of a Wi-Fi client. One of the more common gripes I hear is around Wi-Fi clients not connecting to APs. This is often the case with a buggy Wi-Fi implementation in clients.

Upwards of 80% of issues on our network our client related

Card Readers and Wi-Fi

Distributed over multiple locations, with a large number of gaming machines at each site, a Texas based arcade offers its customers both card reader and guest Wi-Fi services. Long gone are the days of coin and token operated gaming machines. Whether in the amusement or casino industries, most gaming machines now leverage some form of stored value card or debit card systems.

In this case, our customer contacted me because some of their older card readers were not operating properly with AirTight access points.

Put On Your Deerstalker Hat

picture of intercard readerTo help support my troubleshooting effort, I leveraged a Wi-Fi visual troubleshooting tool called WizShark. This visual, cloud-based tool is intuitive (WireShark can lead to packet trace fatigue) and allowed me to quickly perform a close inspection of the packet trace. I was able to isolate an anomaly in the client behavior. In this case, it was a mismatch in the client’s advertising data rate support.

Here is a quick breakdown and analysis of the issue.

Enabling “Data Rate” plot in WizShark shows a large data rate mismatch between client and AP.

Enabling “Data Rate” plot in Wizshark shows a large data rate mismatch between client and AP. Enabling “Data Rate” plot in Wizshark shows a large data rate mismatch between client and AP.

Clicking on probe request packet brings up the frame detail. You can clearly see that the client’s supported rate is 1 and 2 Mbps.

Clicking on probe request packet brings up the frame detail. You can clearly see that the client’s supported rate is 1 and 2 Mbps. Clicking on probe request packet brings up the frame detail. You can clearly see that the client’s supported rate is 1 and 2 Mbps.

However in the Association request frames the client is advertising support for 1, 2, 5.5 and 11 Mbps.

However in the Association request frames the client is advertising support for 1, 2, 5.5 and 11 Mbps. However in the Association request frames the client is advertising support for 1, 2, 5.5 and 11 Mbps.

Association response frame from the AP to the client shows the negotiated rates (11 Mbps is the highest).

Association response frame from the AP to the client shows the negotiated rates (11 Mbps is the highest). Association response frame from the AP to the client shows the negotiated rates (11 Mbps is the highest).

Voilà! Found the Culprit

As shown in the above packet, the client and AP negotiate on the highest data rate supported by both (which is 11 Mbps). Once the client associates with the AP, it transmits a DHCP packet and the AP responds with a DHCP offer packet. The client sends the packet using the data rate of 2 Mbps and the AP responds with packets at 11 Mbps data rate (highest negotiated data rate at the time of association, remember the client sent 11 Mbps as highest supported rate).

Since there are no ACKs for the broadcast traffic, the AP never knows that the client has not received the DHCP offer. The client is stuck in this state (no IP address) and it disconnects after some time and tries again. The cycle continues.

Since there are no ACKs for the broadcast traffic, the AP never knows that the client has not received the DHCP offer. The client is stuck in this state (no IP address) and it disconnects after some time and tries again. The cycle continues. Since there are no ACKs for the broadcast traffic, the AP never knows that the client has not received the DHCP offer. The client is stuck in this state (no IP address) and it disconnects after some time and tries again. The cycle continues.

It Ain’t Over Until The Client Connects

I came up with a simple special configuration to resolve this problem. I configured our AP to operate with a maximum data rate of 2 Mbps on that SSID. Normally you would think that this is a bad idea but not so in this case. Given the bursty nature of card reader traffic, the lower data rate is not much of an issue and the legacy client can now connect and operate with our AP. As for Guest Wi-Fi, it is on a separate SSID, customers can still connect t at 300 Mbps.

This is just one example of several instances where I have resolved Wi-Fi problems due to buggy clients. With IoT and the impending tidal wave of devices that will flood networks, I anticipate such issues to only grow over time. As a Wi-Fi troubleshooting Jedi, armed with sophisticated tools of the trade, you need to be prepared for such eventualities.

In my next blog post, I describe how I resolved a similar problem with a networked thermostat. Have you come across similar situations? Do let me know your experiences.

[Tweet "Wi-Fi Troubleshooting: Guilty until Proven Innocent by @b_misra via @AirTight blog"]

Additional Information:

Looking for a tool to simplify, streamline, and accurately visualize wireless packet capture diagnosis? View the WizShark video from Wireless Field Day 7.

Wi-Fi Troubleshooting with WizShark – A picture is worth a thousand packets.

  • Visual, cloud-based and collaborative
  • Vendor agnostic
  • More intuitive than Wireshark
  • Low risk and not cost prohibitive
  • Requires no installation, configuration or maintenance of hardware or software.
  • Interested in knowing more about WizShark?

 

Glenn Cate tweet on WizShark, Wireless Field Day 7 Follow Glenn Cate on Twitter

Keith R Parsons tweet on WizShark Follow Keith R Parsons on Twitter

Topics: WiFi, WLAN Troubleshooting, WLAN networks, Support, WiFi Access