Any tips for diagnosing user issues on wireless?

  • 13 April 2015
  • 4 replies

Suppose you have a user who is complaining that his windows laptop isn't connecting, or is slow, or drops its connection... or whatever. You dont know anything about this laptop and everything looks normal on your wireless provision. How do you go about diagnosing where the issue lies? Are there any best practices for this or helpful guides?

4 replies

Userlevel 1
Could be a network issue. When I get users complaining about slow wireless, I make sure they have a connection from the laptop to the wireless AP, and if that's good then its probably congested network.
Userlevel 4
It is good to first find out which problem they have 🙂 That can be done first by speaking to the end user(s) and then using tools to help narrow down the issue.

1) Laptop not connecting

Check, is this the only client having issues to connect, or are all clients having a problem, or some. If its the only client, most likely some client issue. If all or multiple users affected, then something else. If client only then doublecheck client settings, driver version, try to disable / enable wifi, or reboot. If multiple users then would need to troubleshoot further. All users in one area, or everywhere. If one area could be problem with one ap, or a local interference source. If everywhere could be a larger system issue, such as a radius server down.

2) Laptop slow

Try to narrow down where the slowness comes in. Is it from client to some resource on the internet, or on the local network. Try to ftp from a local ftp server on the network, then ftp to a server on the internet. Likewise can do a ping to a local device, such as default gateway, then to something on the internet like public google dns If the slowness comes from the internet, try different internet resource, or troubleshoot edge devices, internet provider. If local, then have to troubleshoot local network.

3) Client disconnects

Can look at logs on the wireless gear, radius logs. Can also use the real capture feature to do a wireless packet capture to see why the client is disconnecting. Poor signal, roaming between aps. Can also use a wifi discovery program on the client to see what the client sees in the air. Sort by signal strength to see if client has a reasonable list of access points to connect to with good signal strength and different channels.

Hi Raffi,

Thanks for taking the time to post, the information is very useful. Could you expand on this:

"Can also use the real capture feature to do a wireless packet capture to see why the client is disconnecting."

Is this something built into the controller or are you referring to something like WireShark?
Userlevel 4
This is a feature on the controller. You are starting the trace on the ap, and then you can stream this data to wireshark over the network.

This is a link to a youtube video that shows the real capture feature being used:

This is some text describing the use of the feature:

Click Start to start real capture server on the AP. This feature can be enabled for each AP individually. Default capture server timeout is set to 300 seconds and the maximum configurable timeout is 1 hour. While the capture session is active the AP interface operates in promiscuous mode.

From Wireshark GUI set the capture interface to the selected AP's IP address and select null authentication. Once Wireshark connects to the AP, the AP's interfaces will be listed as available to capture traffic. eth0 is the wired interface, wlan0 is the 5Ghz interface and wlan1 is the 2.4Ghz interface.

The user can selected to capture bidirectional traffic on eth0, wifi0 and wifi1. The capture on wifi0 and wifi1 will not include internally generated hardware packets by the capturing AP. The capturing AP will not report its own Beacons, Retransmission, Ack and 11n Block Ack. If this information is needed, then the real capture should be done from a close by 2nd AP. Change that 2nd AP's wireless channel to match the AP that is being troubleshot. Let it broadcast an ssid so the radios switch on, but don't broadcast the same SSID you are troubleshooting, so that the clients do not connect to your 2nd capturing AP.