In Windows, you cannot effectively analyze wireless frames, because you are unable to put the wireless NIC in "RF Monitor Mode" - that is the mode in which the wireless NIC can see ALL 802.11 frames in the air, not just ones intended for itself.
Historically, it's been an expensive proposition. There are some great tools out there like OmniPeek (which I use), the gold standard for Windows packet analysis. And for years, AirPcap Nx was the main NIC folks used for pcap'ing WLANs with Wireshark. Unfortunately, both options are pricey. And the AirPcap NX is no longer manufactured. You’d be lucky to find a used one on eBay. Linux and MacOS have been the only ways to cheaply get access to RF Monitor mode without spendy software and hardware, like Omnipeek and the AirPcap Nx.
But, not everyone uses Linux, or macOS. Fortunately, and fairly recently, there are more and more ways to get RF Monitor mode in Windows. Here are some relatively inexpensive options (NOT an exhaustive list) to perform an RF Monitor Mode wireless packet capture in Windows using relatively inexpensive hardware. Here's a list from least to most expensive.
Acrylic Wi-Fi Pro ($45) (Plus supported NICs)
@WiFiNigel's blog on how to turn a WLANPi into an external packet capture device for Windows WLANPi can be purchased here. ($75 US)
TamoSoft CommView ($499 US) (Plus supported NICs)
MetaGeek Eye P.A. now supports native Windows Monitor Mode! - (List of supported NICs) ($800.00 US)
OR, you could just get a Mac and do it natively. 😉
If you'd like or learn more about understanfing wireless packet analysis I highly recommend the CWAP (Certified Wireless Analysis Professionals) Study Guide.
Knowing is half the battle. Understanding how your devices make decisions helps you determine design requirements to build better WLANs. Here’s documentation on how Apple and Samsung devices make roaming decisions.
MacOS & IOS Wireless Roaming For Enterprise
Apple was kind enough to provide this information for iOS.
Samsung Knox Roaming Algorithm
Knox is an Enterprise platform for Samsung devices that offers enhanced roaming. Learn how it works to help you support it in your wireless designs.
BONUS: here’s Apple’s iOS Deployment Guide too!
Aruba was not one of the early players in the Dual-5Gig radio field, but as is their way, waited to see how they could implement best. This article is a good overview dual-5GHz requirements for a successful implementation.
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. →
This is a great talk from George Stefanick at this years Aruba Atmosphere Conference in Las Vegas. Make the time to watch this one. It's extremely informational.
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!
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:
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:
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.