THE BLOG ★ Ramblings on WiFi & stuff.

When is a wireless issue a "wireless" issue?

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:

♻︎ Today’s Quality Linkage (Friday, Feb 5, 2016)

Hotspot 2.0 in the wild →

So, it seems public Wi-Fi may finally be coming of age big time. LinkNYCs blog has a write up of their "Secure" public WiFi:

 via Medium:

LinkNYC has two free Wi-Fi networks, ‘LinkNYC Free Wi-Fi’ and ‘LinkNYC Private.’...
 
The ‘LinkNYC Private’ network goes a step further, offering state-of-the-art encryption via HotSpot 2.0 and WPA to secure all wireless communications between devices and the Link, regardless of whether a website uses SSL security. This means that even casual browsing is protected from snooping. The network is one of the first in the country to offer an encrypted public network at this scale.

 

Hotspot 2.0, or 802.11u, OR "Wi-Fi Certified Passpoint" (Blerg.) is an amendment that specifies internetowrking between external networks. Per the amendment:
 

support for external authentication, authorization and accounting, together with network selection, encryption, policy enforcement and resource management.


At launch it will only support Apple mobile devices (of course), but will add other device support over time.

Hotspot 2.0 has been a thing for a while, and this is not the first network to provide it, but with all the attention this project is getting, I have the feeling Hotspot 2.0 may actually have it's day - like legit.

But, there's more! Fierce Wireless is reporting "AT&T in process of upgrading Wi-Fi in NYC parks with Passpoint". "Passpoint" is the Wi-Fi Alliance's marketed name for Hotspot 2.0. That's pretty huge. Two major wireless initiatives in the largest city in the U.S. rolling out secure public wireless.

For those unfamiliar with Hotspot 2.0 I refer you to this blog post by Ruckus Wireless' Dave Wright.

♻︎ Today’s Quality Linkage

RRM Design – Putting it into Perspective A reasonable viewpoint from Alan Blake.

Yeah, where the frak IS Waldo?! Yes, it's about wireless.

Wireless NICs, External USB Hubs, and Noise

Oldie, but goodie: When 802.1X/PEAP/EAP-TTLS Is Worse Than No Wireless Security

And, another one... How secure is your EAP-PEAPv0 deployment?

China Just Released True Color HD Photos Of The Moon Commies on the moon! What's not love!

WALLPAPER WEDNESDAY! The SR-71 Blackbird is just so friggin’ dope!!!! Here’s a pic. And here's another. And another.

Survey For Your WiFi Clients Knowing how your CLIENTS see the WLAN is better than how your NIC sees it.

What Anyone in Wi-Fi Needs to Know About Ethernet

Her Code Got Humans on the Moon—And Invented Software Itself Girls rule!
 

via @BLAKEKRONE: Where's Waldo? (or, The case of the missing wireless engineer.) →

Blake Krone, via his blog →

What do I mean by a skilled wireless engineer? Do I mean they are CWNE or CCIE or AC[]X? No, not at all. I simply mean someone that understands wireless and the challenges it brings when trying to design. It’s the person that knows about Co-Channel Interference and Adjacent Channel Interference, someone that understands when and how to use 20/40/80MHz channel widths, the person that knows you have to do a survey to get things right, etc.

I think sometimes we (myself included), as wireless engineers, make it seem impossible for people to think they can unlock the "secrets of Wi-Fi". No doubt there are some complicated things, but no more so than some other enterprise technologies out there as Blake points out. He thinks it's the PERCEPTION of wireless be too high an entry level and I tend to agree.

Maybe we need to preach some more "bare bones" wireless for the network folks out there that don't have the budget, or support, to access the expensive tools we all desire. Things like knowing WHAT to look for when doing a wireless scan, or basic understanding of channel management could go a long way to helping the many over-burdened IT individuals out there saddled with the task to install a WLAN. At the very least enough knowledge to know when to call in an "expert". In the end what we really need is to bring more people into the wireless fold.

♻︎ Today’s Quality Linkage

FCC: The Next Step for LTE-U: Conducting Limited LTE-U Performance Tests

From the FCC blog: →

Today, the FCC’S Office of Engineering and Technology is taking an important step by granting a special temporary authority (STA) to Qualcomm to conduct very small scale performance evaluation tests of LTE-U equipment at two Verizon sites in Oklahoma City, OK and Raleigh, NC. OET routinely grants STAs and experimental licenses for parties to evaluate the performance of products and conduct testing, subject to the condition that no harmful interference is caused.


I've been quite outspoken about my concerns with LTE-U and it's co-existence mechanisms with Wi-Fi. Wi-Fi has become a pretty integral part of our economy, business-life, and our lives in general, and the dangers I see with letting LTE-U go live without testing and validating it's use in 5GHz I believe are real.

So, I'm glad the FCC is granting the STA so testing can happen in earnest. The Wi-Fi Alliance will has some involvement in the testing methodology and how it should be done. 

Previous tests by Qualcomm have been blown out of proportion by stating that it works better with Wi-Fi than Wi-Fi and would actually improve wireless networks - which was non-sense. The tests were conducted in ways that did not reflect how wireless networks are typically deployed especially in Enterprise environments.

I am not against LTE-U, I just think before a new technology that could be detrimental to another very vital communications technology is deployed, it should be properly tested and vetted.

Is your CAT6 cable CAT6? Probably not. via @HackaDay →

Well, this sucks:

via HackaDay →

This is the part where [Blue Jeans Cable] earns our respect; like good scientists, they set out to replicate Fluke’s results. Sure enough, 80% of the Cat 6 cables they tested from big box stores etc. failed the specification. More surprising, many of them didn’t even pass the Cat 5e specification.

So, it's bad enough that 11ac APs are bringing up the throughput game, as well as the fact that any AP will typically have more throughput than a single device connected to a wired port - simply because one AP hosts multiple clients. But, now we're being told that cable manufactures aren't even meeting the bare minimum specification for CAT6 cabling?

I'm glad someone took the time to verify this. Just like wireless, or any networking hardware - you get what you pay for. Using trusted brands is a start, but wireless engineers should understand that a wireless install doesn't end with the AP. There's also the cabling infrastructure itself. It can be just as much a bottleneck as a crappy AP.

Going all 11ac? You're most likely not going to need +Gigabit ports, or two cables to each AP (for now), but you WILL need to up your uplink game. Gigabit uplinks probably aren't going to cut it. Also, TEST you cables! Or, better yet, have your cable installer test and VERIFY the cables for you.

One great tool for at least validating connectivity on an APs cable is Fluke's LinkSprinter. This little handheld tool checks for connectivity (Is there DHCP? A gateway? Internet access?), as well a PoE, and Link speed of the cable. It doesn't validate the cable for CAT6 specifications, so you'll need a real cable tester for that, but it at least insures that connectivity to the network is functional.

This is a good reminder to make sure your infrastructure can support your WLAN - all the way from the cabling itself, to the switch ports, the uplinks, the router/firewall capacity, and ISP.

Go read the article. It has some good links to Fluke's page on cable testing, and Blue Jeans Cable post on their test results.

♻︎ Today’s Quality Linkage

First thing's first: REQUIREMENTS

Estimated reading time: 2 minutes, 14 seconds. Contains 448 words

 

I was at a meeting today with a large Mechanical/Electrical Engineering firm who was in need of some wireless expertise. More and more they are getting asked to include wireless "designs" for building projects and are finding (as many do) that it's not as simple as it seems.

The discussion took many turns, but often came back to something like, "So, if we have a school with say 35 students per classroom how many APs do we need?" My answer would be, "it depends." What does it depend on? Their requirements.

How many clients (not users, but devices)? What type of clients (1 stream, 2 stream, 3 stream)? What applications will they be using (e-mail & web, video streaming vs. YouTube caching, voice, etc) What are the bandwidth requirements for their State testing? And more.

The point was - just like they could not just "make up" an electrical, or engineering design out of the blue (How many people need to be in the space? What's the total power consumption required? Do we need HVAC in all locations?) - one could not just "make up" a WLAN "design" (Well, one could, but then you get what you get). That made total sense to them which was good.

I love explaining how wireless works and seeing their eyes light up. I love how it makes sense to them when I explain why they're not going to see 1.3GBs throughput, or adding more APs is not a default answer to a problem, how coverage & capacity are different things, how having a bunch of low-end single stream devices is not as efficient as have a bunch of 2, or 3 stream devices, etc.

The FIRST step to wireless network design, and the best way to avoid the BAD-FI, is to determine the REQUIREMENTS and EXPECTATIONS of the customer. Here just a few of things you should consider:
 

  • How many clients will be using the WLAN?
     
  • What are the types/capabilities of the devices? (# of streams, 5GHz support, DFS support, 802.11r/k/v support, etc.)
     
  • What applications will be using the WLAN and what are the requirements of those applications?
     
  • Is there a budget for the project?
     
  • Are there accurate, scale floor plans available?
     
  • What security and authentication types are you looking to support?
     
  • What the total bandwidth coming into your facility?
     
  • What is the time-frame for the project?
     
  • Aesthetics: Are external antennas ok? Do LEDs need to be off Should APs be inconspicuous?
     
  • Cable lengths: where are/is the MDF/IDFs located? More than 300ft from the APs?


These are a few off the top of my head, but you get the gist. DEFINE your customer's (or, YOUR) requirements and expectations BEFORE you design a solution.

Anything else and you're just guessing.