Estimated reading time: 3 minutes, 10 seconds. Contains 635 words
If you're into wireless and aren't following Lee Badman's (@WiredNot) #WIFIQ (Wi-Fi Question of the Day) hashtag on Twitter, then I'll just wait while you go ahead and do so.
It's o.k. I'll wait.
Ready? Good.
I really like this question, because it does emphasize one fact about WLANs - it's more than just the wireless. There are other very important things you need to have a well performing WLAN. The question asks what issues do you typically run into when troubleshooting wireless networks that ARE NOT necessarily wireless issues. The answers were varied and insightful as they are for all the #WIFIQs.
There are many "wireless", or 802.11 based specifics that can affect wireless performance. A short list would be:
- Client can't associate to an SSID because a particular feature (like 802.11r/k/v) is enabled and the client driver does not like that - so it refuses to connect.
- Clients can't connect because you have WPA2 enabled, but not WPA (the older client only support TKIP).
- You expect a certain connection speed, but the WLAN is configured for 20MHz channels, instead of 40, or 80.
- Clients are having connectivity and throughput issues because channel reuse is poor (maybe you're using 80MHz channels) and co-channel interference is exacerbated.
These things are clearly 802.11 related and can rightly be considered "wireless" issues. But, what about the guest user that is connected to the WLAN, but can't get an IP address? Or, the client that connects to guest network and never gets the promised captive portal? These client have associated to the AP, but are unable to get network access. And of course: user complains that they enter their credentials, and they just can't connect. Are these wireless problems?
I can think of several reasons why the above mentioned clients could be having these issues, and none of them are "wireless". For example, the IP address issue could simply be a depleted subnet. Many guest networks use long lease times (read: default) and don't realize a client connected several days ago could still have an address reservation that has not expired. Even with a small number of clients you could exhaust the address pool in a few days, or weeks.
Or maybe to was incorrectly configured switch ports. If that AP is placing client in specific VLANs, and those VLANs are not tagged on the port, that would also cause our "no DHCP" issue.
The captive portal could be several things: no DNS properly configured, no IP on the guest VLAN interface, the old "DHCP exhaustion" issue, etc. These are all technically not wireless issues, but can absolutely affect, and be detrimental to your wireless clients.
And the password/credential issue? The most obvious one is they forgot, or incorrectly entered the password, or login credentials. Another possibility is their account was deleted, locked, or de-actiavted, so RADIUS authentication is failing. OR, someone fat-fingered the RADIUS shared secret when setting up the server, and RADIUS is ignoring the request.
So, the moral of this lil' ditty is that you need to be aware that there is more to your wireless network than wireless. You need to understand DHCP, addressing schemes, PoE, cable types, firewall rules, RADIUS servers, etc. You may not have responsibility, or access to do anything about them, but you should be able to diagnose, and troubleshoot these issues and get folks involved that can help.
Regardless, when someone says, "the Wi-Fi don't work!", and it's not a "wireless" issue - it doesn't matter. The user doesn't know, or care, they just want it fixed. Being able to quickly determine where the issue is originating will go a long way in making your users happy.
As my buddy Jake pointed out: