Use Apple Wireless Diagnostics to Help You Resolve Wi-Fi Issues on Your Mac

We love our Macs. And this is just one of that MANY reasons why.

We use Apple's built-in wireless diagnostics often to troubleshoot, or get quick diagnostic information about a WLAN. Everything from performing a Wireless Scan, a packet capture, Monitoring the connection, and more:

Read Apple's article about using OS X's Wireless Diagnostics utility here. →

Presenting: ACCX #533, Brandon Williams!

ACCX 533, Brandon Williams.

ACCX 533, Brandon Williams.

So, our very own Brandon Williams (CWNA, ACMP) can now add some more prestigious letters to his name... ACCX - Aruba Certified ClearPass EXPERT! This is no easy task and involves a lot of field work and a grueling, 8-hour, practical exam at Aruba HQ in Sunnyvale.

And if that weren't enough he'll be taking his ACMX (Aruba Certified Mobility Expert) next month - which we have no doubt he will also pass with flying colors. Brandon has been with CommunicaONE going on 4 years and has grown leaps and bounds over that time. He is simply - The Man.

So, congratulation, Brandon. You truly earned it!

Video: Overview of Aruba Clearpass Guest Access

Aruba ClearPass offers managed guest access for Education, Enterprise, Healthcare, and High-Capacity user requirements. But, it's more than your traditional captive portal. Options like, Guest Self-registration, Sponsored Guest Access, integration with 3rd party services for payment processing, elevate ClearPass from other Guest solutions.

For more information read the ClearPass Guest data sheet.

Or, watch the video below:

Aruba ClearPass Sponsored Guest

Aruba ClearPass Sponsored Guest

When is a Wireless Issue a "Wireless" Issue?

If you're into wireless and aren't following Lee Badman's (@WiredNot) #WIFIQ (Wi-Fi Question of the Day) hashtag on Twitter, you really should. This particular question is insightful, because it emphasizes one fact about WLANs - that it's more than just the wireless. There are other very important things that need to be performing well 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?

There could be several reasons why the above mentioned clients are 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 story 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 Jake Snyder (CWNE #161) pointed out:

Aruba Clarity. Because a Wi-Fi Problem's Often Not a "Wi-Fi" Problem.

It’s interesting that Aruba showed off “Clarity”, a new feature in its network management product AirWave, at Atmosphere. It’s interesting because it seems that lately there have been discussions about users blaming Wi-Fi for non-Wi-Fi related issues. I even blogged about it myself a few weeks back. And recently, Lee Badman posted “the soon to be famous cocktail napkin" he drew, to explain how wireless issues are more complicated then they appear. When users are connected to Wi-Fi, and they can't get to a webpage, or get an IP address, or that fancy captive portal you spent so much time customizing, the assumption is, “the Wi-Fi’s broke” ¯\_(ツ)_/¯. And the user is right… well, as far as they know, or care. And that’s where Clarity comes in.

What Clarity does is offer a window into what may be affecting the wireless user experiencing a problem. Clarity gives you a "heads up" letting you know there are issues with DHCP, or DNS queries, association, and authentication failures, by showing you an overview in its dashboard. Also, it gives you a "real-time" view of a client experience. Maybe it's taking too long for a client to associate to an AP, or the captive portal is not working, and you see DNS issues on the clarity dashboard - insight into what the REAL issue could be.

The fact is many help desk calls about wireless, are not wireless problems. The problems lay elsewhere in the infrastructure. Knowing where to start your troubleshooting helps you find resolution faster. Clarity is another tool in the help desk arsenal to help you get customer complaint resolution quicker, and more efficiently.

But, that's not all. Clarity also offers "Synthetic testing". Essentially, it allows you to simulate user activity on the WLAN, by using an access point as a client. You can then use that simulated client to run tests on the WLAN. If there are service affecting issues you have an opportunity to find them, and fix them, before you actual users arrive.

In a scenario we were shown you would go to the VisualRF tab and select the location you would like to perform the test. You then click on the AP you would like to act as your client and perform tests that simulate a client connecting to the WLAN. This test should expose issues with DHCP, DNS, captive portals, etc.

In theory, this should help predict, or rather, REVEAL problems that could occur once the real clients arrive onto the WLAN. This is what we as WLAN professionals do when we perform validation surveys after a deployment. You do perform validation surveys after all your deployments, right?  It's a very appealing idea to be able to perform tests, maybe even SCHEDULE tests, on a regular basis, to head off those issues at the pass.

This is what I would love to see - a mobile app that can be installed on a client, that can perform those same tests. This would be an improvement to the already great option of testing with an AP or an AM (Air Monitor), but here's the difference - it's an ACTUAL client. It's not an AP, on a ceiling (where there are no clients), with super RX sensitivity. It could be a single-stream mobile device, or 3-stream MacBook Pro, and you can run test AS THE CLIENTS THEMSELVES WOULD. Run test in multiple clients at the same time - like you would see with REAL clients.

Well, Aruba is already working on that. It will initially be an Android only app, that will allow you to perform Clarity tests from the client itself. There is no word on a release date, but I am hopeful that it will come in a timely manner.

At introduction, Clarity will be available only for Aruba controller-based platforms. 

Aruba Clarity with real-time monitoring will be available as part of the Airwave 8.2 release coming out in the next few weeks. Synthetic testing will soon follow.

See how you can fix networking issues for your mobile users before they escalate with Aruba Clarity on AirWave.

Levi’s Stadium Crowd Sets Single-Day Wi-Fi Record with 10.1 Tb Used at Super Bowl 50

For us the big story out of Super Bowl 50 was how the Wi-Fi performed. And according to all reports it performed superbly. The Aruba wireless LAN peaked at over 27 THOUSAND clients connected - with average speeds around 15-20mbps.

From The Mobile Sports Report:

The 71,088 fans at Levi’s Stadium for Super Bowl 50 helped set a single-day record for Wi-Fi usage, with 10.1 terabytes of traffic on the stadium network, according to the NFL and the San Francisco 49ers network staff.

I had the privilege of listening to Chuck Lukaszewski, from Aruba, talk about what it takes to design for Very High-Density WLANs. If you have some time watch the video of the talk from the Wireless LAN Pros Conference.

First Thing's First: Requirements

*Originally published on Eddie's BadFi.com.

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 requirements and expectations BEFORE you design a solution.

Anything else and you're just guessing.

Single VLAN Architecture for WLANs

Aruba has just posted their most recent VRD (Validated Reference Design). In the past we've relied on VLAN pooling for large WLANs do to the issues with broadcast and multicast in large subnets. Optimization of these now allows WLANs with a single large VLAN/Subnet simplifying deployment.

"Rather than using conventional design with VLAN Pooling and multiple smaller subnets, we think that there is a better way to design WLAN today using 'Single VLAN with One Large Subnet' to serve all the wireless clients connecting to an SSID. This paper explains how we came to this conclusion."

Download VRD now →

You should also take advantage of Aruba's entire VRD Library →

 

Bigger isn't ALWAYS better. 802.11ac and 80/160 MHz Channels.

Last week we were asked to come and troubleshoot a WLAN that was experiencing connectivity issues. All we knew was this was a brand-new installation and that it was the latest hardware available from this particular vendor.

The first thing we did upon arriving on site was scan the area as we walked around. Immediately we saw something that was troubling. All of the brand-new 802.11ac access points were broadcasting on 80MHz channels, and there were no DFS (Dynamic Frequency Selection) channels being used thus limiting their channel re-use options even more.

As you can see in the chart below there are only TWO 80MHz channels available for use without DFS channels (the entire UNII-2) :

5MHz Channels in the US.

Even in a deployment as small as this one (they only had eight APs) using 80MHz channel is a non-starter. The WLAN was literally interfering with itself. Even enabling DFS channels would have been a difficult thing to make work, even if (theoretically) we could have SIX channels. However, channel 144 is ONLY usable by 802.11ac devices. So, typically, the 80MHz channel that includes 144 is not used. Also, the TDWR (Terminal Doppler Weather Radar) channels are not used so now we're down to FOUR 80MHz channels. Four channels may work in a small environment, but then you have to consider WLANs other than yours.

Unless you are in a secluded area there will probably be other WLANs within earshot of your network. So, if any of the sub-channels that make up the 80MHz channel that you are on, are also in use by other clients, you will experience issues. In this case, the WLAN was in an office building that had other tenants with their own WLANs. So, using 80MHz channels in the scenario was the main cause of their problems. (Even if they were secluded usage of 80MHz channels would not be practical.)

The fix was simple. We enabled DFS on their controller and disabled 80MHz support in the ARM profile for that AP group. This immediately dropped all APs (access points) to using 40MHz channels. And, with the use of the now available DFS channels, we had NINE channels to use among 8 APs. The point here is DFS gives A LOT more channels to work with - so it's worth using them.

We can't blame the customer for this. The installer should have known that 80MHz channels in an enterprise environment is not practical, or in this case, even viable. It was clear what had happened. The system defaults were left as-is, and there was little to no customization of the WLAN.

By default, 80MHz channels were enabled. 

By default, DFS was disabled. 

By default, all APs were set to transmit at maximum power.

This just shows the importance of knowledgable, experienced professionals deploying your wireless network. It's more than mounting APs and creating a few SSIDs. It's understanding how RF (radio frequencies) work, what its limitations are, and how to design around them.

One last note on using DFS channels. I have seen great success using them, but the reason DFS channels are not enabled by default is because they share spectrum with radar systems:

DFS is a mechanism to allow unlicensed devices to use the 5GHz frequency bands already allocated to radar systems without causing interference to those radars. The concept of DFS is to have the unlicensed device detect the presence of a radar system on the channel they are using and, if the level of the radar is above a certain threshold, vacate that channel and select an alternate channel.
— Aruba, an HP Enterprise company.

For this reason DFS is disabled by default on Aruba controllers. If near an airport, a marina, or military installation, you should consider the possibility of radar events. A radar event occurs when an AP hears (or, thinks it hears) radar on the channel it's on. When this occurs the AP immediately switches to another channel (as per FCC regulation). This will cause all the clients on that AP to be disconnected. They will then probe for a new AP and reconnect. With a few events per month this may not be a big issue. But, if you have mission-critical applications (a hospital perhaps) radar events may not allow DFS to be an option. You may even need to go down to 20MHz channels so you can have more spatial re-use with non-DFS channels.

We recommend enabling DFS. Then monitor your network for events. If they never occur, or are very infrequent then continue using DFS. If you see events that seem to be centered on certain frequencies disable just those DFS channels. 

Enabling DFS channels.

Disabling 80MHz support.

The easiest way to monitor for DFS events on an Aruba controller is from the CLI. SSH into your controller and use the following command:

(controller) # show log all | include Radar

Do this every few weeks. Then if all seems good - once a month, or so. If you're lucky enough to have an NMS (Network Management System) perhaps you could setup alerts for these events.

The four things I hope you get from this post are:

1. 80MHz channels are impractical for enterprise use.
2. Use DFS channels whenever you can (which should be most of the time).
3. NEVER take the default settings from manufacturer at face value.
4. When in doubt hire a professional.