Wireless Handheld Testers You May Not Know About

In the world of Wi-Fi engineering and support, there are definite crowd favorites when it comes to tools.  Not every WLAN Pro sees the world exactly the same when it comes to tools, and usually what we pick to use in our daily duties comes down to ease-of-use (which can be subjective), cost, and effectiveness. That equation shakes out a little bit different for each of us, yet the same tools tend to show up often in what is a fairly limited market. I’m not talking apps here, as there are lots of those. Here, I’m more getting at handheld wireless tools, or if you want to stretch it a bit, ones that plug into a USB (or Lightning) port to turn the host device into a handheld tester. Before you yawn and click away, let me get right to the point: chances are that almost all of us have at least one tool from MetaGeek, or AirMagnet/Fluke Networks, or maybe Oscium. You know… the usual stuff. (Again, no slight to the software/app toolmakers in the crowd.) But this blog is about the slightly exotic. Of late, I’ve stumbled across some funky looking brands of hand-held testers/spectrum analyzers that I’d like to share. If you know of others that are off the beaten path, please let us know in the comments.

I’ll ease you into this with one from a company that’s actually been around a long time, and used to be more mainstream among wireless tools- the Yellow Jacket BANG, primarily a spectrum analyzer from Berkeley Varitronics Systems (BVS).


Everything BVS has ever put out just looks cool. Here’s the specs on the Yellow Jacket BANG.

Next- get an eyeful of this thing:


From Test Um, with more info here. Needless to say, it’s underwhelming… yet interesting to look at, no?

Next up- the RF Explorer. (I wish I could say that in a Darth Vader voice with reverb effect.)


(With handsome carrying case!) Details and specifications here.

Moving on to the 802 AWE from Trilithic Broadband Instruments, I have to say that this one looks like it could be for real, and a possible competitor to the Fluke Networks AirCheck.


I’d love to take the 802 AWE for a test drive. Check out this whitepaper, and see what you think.

We’ll finish with an interesting offering from the UK.



The Vonaq Artisan Wi-Fi Tester also looks like a for-real tester, and that snazzy orange case means it should be safe in the woods during deer hunting season.

How many of these have YOU seen before? Ever laid hands on any of them? Do any of them interest you? There *may* be life beyond MetaGeek and Fluke Networks here… Please add your thoughts.

Three Inconvenient Truths and Some Conspiracy Theory About the FCC’s Mi-Fi Enforcements

The recent enforcement actions by the FCC against hotels that disrupted private Mi-Fi usage are interesting for a number of reasons. If you’re a Mi-Fi user that travels and you don’t really understand or care about the inner workings of business wireless networks, you likely did some variation of a fist-pump because evil companies must now seemingly mend their dastardly ways. (This blog may challenge the validity of that assumption, so click out of here now if you don’t want your bubble burst.) If you are a long-time wireless admin of business Wi-Fi networks, you are likely scratching your head a bit over several of the finer points of what the FCC is up to these days in going after companies like Marriott and MC Dean. I would guess that some Wi-Fi admins are feeling a bit uncomfortable but can’t quite put their fingers on why that is, but what the FCC’s doing all of the sudden just feels weird. And for those of you that are trying to keep an open mind about what it all really means as all sides of the debate try to be heard, I give you the following to ponder:

1. “Our Premises, Our Airspace to Keep Healthy” Since Late ’90s

The 802.11 Wi-Fi standard dates back to the late 90s. For over 15 years, wireless network administrators, security managers, and CTO/CEOs have been writing and enforcing policy about signals that compete with their WLAN systems and the use of “rogue” access points not put in by “Central IT”. Many of these policies pre-date Mi-Fi’s existance, but often address off-my-wire ad hoc (peer to peer, my laptop to yours) direct connect rogues that both interfere and bring their own security concerns. This is an entrenched technical cultural issue. Though Mi-Fi doesn’t meet the textbook definition of IBSS ad hoc networking, it does share the properties of being a competing Wi-Fi signal and it’s own security risk in that if you know what you are doing, you can bridge “isolated” networks to each other pretty easily. Rogue ad hoc is just as important to rogue on-wire by most WLAN policies I’ve reviewed- for both RF interference and security concerns.

All of these (and plenty more) are scraped from easily-found published private network policies on the Internet:

If there are cordless phones, ad hoc or peer-to-peer WAP’s in the prohibited frequency, [we} will attempt to notify the user in writing and ask them to remove the device.  If the device is not removed within 24 hours, [we] will take necessary actions to stop the interference of the device.

This policy covers any devices and users to adhere to the rules, regulations and policies concerning security and prevention of interference.

Due to possible interference from other sources within the 802.11 wireless 2.4GHz frequency range, [our] wireless spectrum should be kept clear of unauthorised transmissions.

Interference means the degradation of a wireless communication signal caused by electromagnetic radiation from another source. Interference can slow down or eliminate a wireless transmission depending on the strength of the interfering signal.

Interference or disruption of other authorized communications that result from the intentional or incidental misuse or misapplication of wireless network radio frequency spectrum is prohibited.

In the event that a wireless device interferes with other equipment, [we] shall resolve the interference as determined by use priority.

So, those of us administering wireless networks tend to recognize that solutions enforce policy, and the policies that guide WLAN security and interference management are nothing new. They are so ingrained in the Wi-Fi psyche from the system side that WLAN vendors and companies that train new WLAN staff are all on board with the philosophy that you can do what you need to to keep your own airspace clean and healthy for the greater good of your users, and to enforce YOUR OWN policies. And… this culture has been in place under the FCC’s own nose for all these years. Mi-FI devices are easy to lump into the spirit of long-established Wi-FI policies, with no malicious intent in doing so.

2. Non-Accommodation Equals Disruption, Too- To Users.

In convention centers where big events are going on, the Wi-Fi network will be made up of dozens (if not hundreds) of extremely low-powered WLAN cells. These cells only have limited channels to use, so staggering channels meticulously and controlling cell size is pivotal to network operation (and event success, in many cases). Along comes a Mi-Fi, with it’s often bad-neighbor config that blasts out a strength that may be an order of magnitude stronger than the conference Wi-Fi cells. As the Mi-Fi disrupts multiple cells (that other conference goers are trying to use), those same cells are also interfering with the Mi-Fi device. In these scenarios, there are typically no “free channels” so mutual interference is a fact of life.

So… I go to use my Mi-Fi at a convention center during an event, and lo and behold, it doesn’t work well. All I know from the headlines is that the FCC says it’s OK for me to do what I’m trying to do, so if it’s not working well, the stinking hotel must be trying to block me! I better report them to the FCC! It’s an outrage!  Except it’s not- it’s physics at work. So what comes next- convention centers needing to ask Mi-Fi users permission to use specific channels?

3.  The FCC Is Closing Many Field Offices, Which May Impact It’s Ability to Enforce. 

The agency is calling it an efficiency move, but what impact the cuts will have on the agency’s ability to enforce it’s own rules remains to be seen.

Let’s Play the “What If” Game A Bit

I, and others have voiced a fair amount of concern about not only what the FCC is doing with it’s new tactic of huge fines, but why it’s being done with very little substantive guidance. Even two of the five commissioners at the FCC don’t seem to agree, or to get what the agency is supposed to be accomplishing with their new fundraising campaign. With lack of leadership from the FCC, the WLAN community is left to speculate about what they could be thinking in DC. Here are a couple of theories to ponder:

  • What if the FCC really is clueless about how important Wi-FI has become to businesses of all types? What if, while we as IT organizations have been doing our best to write and enforce good WLAN policy, and have bought WLAN tools that help us to enforce those policies for the greatest number of people on our premises that rely on Wi-Fi, the FCC in it’s ivory tower was oblivious to it all for the last 15 years? What if an out-of-touch FCC is thinking one thing, while the rest of the WLAN community is basically thinking something else?  It might explain the rush to crank out big fines for what amounts to the same policy that private WLAN environments have been enforcing for the last 15 years. Because the hotels were charging big fees, they have cast the whole thing in a stinky light (and deserve to be called out on it), but the issues for the rest of us are made murky because of the FCC’s Mi-Fi related hits on the hotels and convention centers. It would seem that we all need help (that the FCC has no interest in providing) in:
    • Re-writing our business policies to accommodate Mi-Fi while still preserving our own business continuity
    • Understanding whether the hotels were only in trouble because they were trying to charge (what everyone seems to agree was too much) for their own Wi-Fi (it sure reads that way at times)
    • Or coming to grips with- if it’s what the FCC is saying- Mi-F- must be accommodated everywhere under all circumstances regardless of collateral damage from it’s interference
  • What if the FCC is just using these headline-grabbing fat fines to sew paranoia as a way to augment their enforcement capabilities as they reduce field offices and employee head-count? Uncertainty and paranoia can certainly be force-multipliers when you have the ability to name your price when handing out fines, and the bigger the fine the harder the impact of the tactic. The new-found interest in taking issue with practices that many companies have had written into their IT policies since Wireless Day 1 times out nicely with the cutting back of FCC field offices. It’s just a thought…

My personal sympathies are absolutely with those users who didn’t want to pay what the convention centers were asking for Wi-Fi. But there is so much more to the whole picture than that, and it needs to be talked about.

My related articles on this:

10 reasons to take another look at 2015 Cisco Mobility


Sam Clements does great justice to Cisco WLAN’s current strengths. I can’t say that I believe in all ten of Sam’s points, but I do believe in Sam. Have a read!

Originally posted on SC-WiFi:

Let’s face it, Cisco is huge. They’re massive, and occasionally they get things wrong. If you’ve strayed away from Cisco in the past year (or longer) because of a specific issue or gap, it’s high time you took another look. The Cisco Mobility offerings today are a far cry from what they were just an easy year back. Here are 10 great reasons to go get reacquainted with the 2015 Cisco Mobility offerings:

1) 5520/8540 WLCs

The introduction of a Converged Access 60G solution highlighted the gaps in the WLC portfolio in the 20/40G of throughput range. Both of these new controllers (one 20G, one 40G capable) are based on the more mature AireOS codebase running 8.1 and later. While this doesn’t mark an EOS/EOL announcement for the 5508 (clocking in at 8G), it does give that 7 year old platform some good alternatives for lifecycle management.


View original 845 more words

Loose Lips Sink Ships (and Network Credibility)

Stop me if you’ve heard this one… A manager- no a DIRECTOR, or a DEAN, or a CIO, or a DOCTOR, or some other person of title– walks into a bar. She tries to use the Wi-Fi, and it doesn’t immediately work, so she declares that the network sucks. And people hear her. Now, because people tend to listen to authority figures, her words get repeated. Pretty soon the off-hand comment, based in one user’s frustration, slowly becomes reality (well, maybe Kardashian-style not really reality).

But… it does become an accepted “fact” by the Person of Title’s circle that the bar has sucky Wi-Fi. And eventually, someone has to answer for that sucky Wi-Fi. It doesn’t matter that while The Legend of Sucky Wi-Fi is growing to epic proportion, hundreds of other of users are enjoying the bar’s Wi-Fi. They just aren’t talking about it, and they don’t have circles of followers that take their word as gospel and pass it on.

Maybe she didn’t mean to cause a kerfuffle, and maybe she did. For some people, if Wi-Fi isn’t working right, it’s everyone’s fault but their own (or their device’s). Regardless- the damage is done. That network has been labelled as bad, and therefor it IS bad, because of who labelled it. So now someone needs to fix what ain’t broke, even if it all amounts to is re-education and demonstration that the network isn’t problematic. That is- IF the person of title is even willing to be convinced (some are, some are not).

Unfortunately, there’s no punchline here.

If you’re reading this, and you are a leader of any sort (the kind that people listen to), the WLAN community asks this of you:

  • Remember that your Wi-Fi client device is like everyone else’s, even though it’s yours.
  • Wi-Fi client devices don’t always act the same way as you travel from network to network. This includes expensive client devices.
  • Not all Wi-Fi networks are set up the same, and sometimes what you expect based on your frame of reference isn’t what happens,
  • None of this means that the Wi-Fi network sucks or is broken.

At the same time, network problems DO occur. Sometimes they impact all wireless clients. Sometimes they impact just you. There’s no way to tell what’s going unless a system administrator gets involved. So… rather than declaring that the network sucks and invoking The Butterfly Effect From Hell For Wi-Fi Networkers, why not help us to help you? Report the problem, including symptoms and a specific time and very detailed location where you experienced your frustration, and wait to see what the outcome is.

A huge part of being a network administrator is basically proving that the network is OK, and solving client-specific problems. The first part often comes from off-hand comments that are blown up into issues bigger than they are because of who said them, and the second is often the reality behind the first.

So c’mon… give us a chance- before you trash the network.

Quien es Mas Macho? A Beacon Battery Brouhaha!

There’s not a lot of networky substance here, so if you’re looking for that, well- you just keep moving. But, if you’ve been following what’s going on with beacons and location services that use these little gems, you might want to keep reading.

I give you… Exhibit A.


At the top, we see The Aruba (Meridian) BT-100 beacon, which was given to me at Wireless Field Day 8 as I sipped a cold one and got briefed on lofty tech topics at Levi’s Stadium by Aruba’s SMEs (I run in those circles). At the bottom, we have the Gimbal beacon, by Qualcomm. This was another freebie, which I scored during a promotion. Each has it’s place in the beacon universe, with the power to help build amazing success stories in the field of location based applications and services.

This isn’t a Beacon X vs Beacon Y smackdown in the making- but it is an opportunity to point out a pretty important point about beacons.

I give you… Exhibit B.

beacon 1

Using my world-class Leatherman Skeletool CX (special Kieth Parsons Edition), I jimmied my way into the innards of each beacon with the precision maneuvers of a skilled surgeon. And what I saw made me do some thinkin’ about the powerful lonely feeling that grips a man when batteries go dead and whatever the thingy is in play stops working. Which brings me to the points of this blog:

  • Some batteries are bigger than others
  • Bigger batteries have more capacity
  • More batteries combine for more capacity
  • More batteries that are bigger combine for even more capacity

Sounds so simple, right? The implications aren’t so profound if whatever you’re doing with beacons only needs a few of them in easy-to-reach places. But I have been to Levi’s Stadium, oh yes I have, and I can testify that copious amounts of beacons are in use and not all are easy to get to. This is an example of a place where beacon battery brevity blows. 

You want loooong battery life in many beacon situations, and out of the box the BT-100 promises an impressive 1,460 days. For those not up on Common Core math yet, that equals 4 years. By contrast, the Gimbal above is rated for “many months” (I got about 6-7 months out of mine).

The Gimbal uses the CR2032 battery, whereas the BT-100 uses two of the phat-daddy CR2477 cells. This is the biggest “watch battery” I’ve ever seen, personally.

What’s the Big Deal?

To me, battery refresh on deployed beacons has the potential to significantly add to total TCO where hundreds are deployed, especially if ladders need to be climbed and maintenance windows need to be followed. This simple example shows that not all beacons will have the same battery life, based solely on the battery used (note- I’m leaving out some important operational parameters that impact battery life, but these are beyond what I’m trying to get across here).

There are many, many more beacons on the market than just these two, but if you’re going down the beacon path, make sure you consider expected battery life as you make your choices.

Just getting started with beacons? Here are a couple of blogs I wrote up as I went from knowing absolutely nothing about beacons to knowing enough to be able to not be totally clueless.

Beacon Baby Steps
A Little More on Beacons

Using Speed Tests to Troubleshoot Wi-Fi? Understand What You SHOULD Be Getting

OK- we all know this routine… In the name of troubleshooting or diagnostics, you do some kind of network speed test as a data point. Sometimes, you use it as the ONLY data point to judge if the connection is good or bad. Maybe not the best practice, but let’s see if we can’t tighten up the process and expectations of speedtesting here.

This piece is written for those who may not realize the nuances of wireless networking versus wired when it comes to using simple speed tests as a diagnostic tool. Wi-Fi pros know that what’s being described here is actually one of the less-precise tools we have available, but it’s a handy one when more advanced WLAN tools are not on hand.

What SHOULD I be getting for throughput?

This question is of paramount importance. And the answer is a firm “that all depends”. If you are testing from a LAN or WLAN off to the likes of speedtest.net on the Internet, you really can’t know what the entire range of “good” is. You might be able to get as far as “well, it doesn’t suck, or it seems generally OK”, but you won’t be able to put a lot of precision on it. And, your results will be wildly variable (more on this in a minute). You absolutely have to consider the size of the ISP connection as well. Let’s say you are home and your internal network is healthy; your speedtest results should be very close to the rated connection speeds of your Internet connection (it can’t be faster). If you are on a robust business network that has multiple Gigabits of  ISP connectivity  to the Internet, the bottleneck to off-net speedtest.net will typically be out on the murky parts of the Internet or at the speedtest server itself.

There’s great luxury in setting up your own internal speedtest server (and lots of ways to do it, but that’s another blog article). You can get used to what you see from an internal server as a more reliable troubleshooting tool, but even here your results will vary whether you are on wired or Wi-FiLet’s explore all of this a bit.

Example 1- Wired Connection on Robust LAN

These are two consecutive runs to an off-network speedtest.net site from a verified Gig-connected PC on a business LAN, that minimally has a Gigabit path all the way to the Internet. All top-quality switches, routers, and cabling are in play on a professionally-built network. I ran these tests back to back. You’ll notice I was sent to two different servers on the Internet with greatly varying results.Speed 2


That’s life on the Internet. And this test tells me little about the true quality of my internal network.

Using our internal, on-network speedtest server yields far more consistent results- generally within 10-20 Mbps with every pass for my wired Gig PC. All internet variability has been removed.speed 3

Now again- this is from a very stable, predictable WIRED gigabit connection.

Example 2- Wireless. A LOT More Complicated

So… you can probably accept the difference in what you should expect between on-network and off-network servers for doing speed tests, and can understand the variability of the Internet. And, I’m guessing that you’re OK with the fact that testing a Gig wired connection to an on-network speed test server should consistently give something close to a Gig. But on Wi-Fi, there are other important variables to consider when trying to use speed tests in troubleshooting.

Check out both of these, taken from my Nexus 7 tablet, on the same Wi-Fi network:

Speed5          Speed6

Clearly the first connection is better, right? There must be something wrong with the second one… yes? Especially if I told you that each test was run against the same model AP, with the same Gigabit uplink and all other variables equal. And it’s the same client device in each test. So the second connection is not as good. And the first connection is smoking- right?

The problem is that neither conclusion is true. And both are true. Maybe. Perhaps. How do you know?

As presented, you simply don’t have enough information to draw many conclusions- ESPECIALLY if you are troubleshooting and making determinations about network performance using speed tests. When it comes to wireless, you gotta think way past the simple elegance of Ethernet, Fast Ethernet, and Gigabit Ethernet that wired PCs enjoy, where all you have to consider is “am I getting close to 10, 100, or 1000 Mbps or my ISP speed?”.

To attempt to use throughput tests on Wi-Fi, and have them be even somewhat meaningful, you need to master the following.

  1. Know your device. I used the Nexus 7 (2013 model) above. Looking up the specs shows me that it’s dual-band 11n, but doesn’t tell me the specific WLAN adapter in use. Looking a little deeper tells me my tablet DOES NOT USE MIMO antennas (important in a minute). All of this is much easier to find on a Windows PC or Apple device, but find it you must. And it shouldn’t take more than 5 minutes on the web. If you don’t know what your WLAN interface is capable of, you can’t tell if it’s living up to it’s potential. (Here’s one table that shows a bunch of Intel 11n adapters and what they can do. We care very much about that 1×1,2×2,etc. stuff, BTW.)
  2. Now that you understand that wireless adapters can have huge differences in capabilities,and what yours is capable of you have one piece of the puzzle. (But just because my new Mac might be capable of a 1300 Mbps data rate, I shouldn’t expect to ever see that, and we’ll find out why in a minute.) The next thing you have to know is what access point/wireless router is in use. I might only get 5 Mbps during a speedtest with a wireless PC that is capable of 100x faster, and still have a perfectly healthy connection if I’m connected to old WLAN gear (and there is a lot of it out there). If you don’t know what your device and the network itself are capable of, you can’t know if you’re getting top-end performance.
  3. Next- figure out where you are in the WLAN universe. Whether you use your wireless utility and the Network Management System (NMS) or AP/wireless controller interface, you can’t tell what a reasonable speedtest result is without knowing a bit about both ends of the connection, in terms of:
    – did you connect to the AP you think you should?
    – your data rate (.11a/b/g) or MCS value (11n or 11c)
    – your signal strength and quality
    – your retries (generally)
    – are you on 5 GHz or 2.4 GHz?
    – What channel width is in play? (20 MHz or 40 MHz)

On most laptops regardless of OS, you don’t have to work too hard to see what data rate your computer thinks it’s connected at. Remember- you’re seeing data rate here- NOT SPEED (again, we’ll get to the difference). Here’s a WIndows PC showing it’s data rate:


In “the system” from the infrastructure side, it looks like this (or some variation, depending on vendor and view):

Speed 9


In wireless, NOTHING is as easy as with wired Ethernet. Under “802.11 metrics”, to tell what the system thinks my client should be doing for speed, I need to understand that the numbers listed next to “Data RateSet” apply to 802.11b/g/a radios should the client need them. In other words, this client is saying to the AP that these are the pre-11n data rates it is capable of supporting. Note also, I have excellent signal strength and SNR, and that my retries (will ALWAYS be some on wireless) are low as a percentage of overall traffic. We also see that I’m in 5 GHz (11an), so on MY network we’re using 40 MHz channels, if the device supports it (all 5 GHz 11n or 11ac devices do, older 11a devices do not). We only use 20 MHz wide channels on 2.4 GHz regardless of 11g or 11n. Many 11n/ac environments will have the 40 MHz channel option disabled as a design choice, and you may need basic WLAN analysis software to tell what channel widths are in play if you don’t have access to the admin views on a given WLAN.

Then we see that the current transmit rate in use by my device is “m6”- but what does that mean?


Remember, my Nexus 7 is not MIMO. In other words, it’s a single-stream device. (2×2 and 3×3 MIMO clients would be 2 stream and 3 stream clients. We need that stream count knowledge to make decisions on whether we are getting the speeds we should!) Now, we need to consult a table for 802.11n or 11ac MCS values (they are not quite identical for 11n and 11ac) and figure out what we should see for a legitimate good data rate based on:

  • MCS value
  • Channel width
  • Number of streams

(chart from WirelessLAN Professionals web site)

With my Nexus 7, using a 40 MHz wide channel, at MCS 6 and a single stream (because that’s all it’s capable of) I follow the red line into the two data rate values of 121.5 and 135 Mbps. The difference is whether “short guard interval” is in use, and that can be really hard to figure out if you don’t do Wi-Fi for a living. So lets’s just split the difference and say our data rate should be around 128 Mbps based on all of the parameters we can identify.

Let’s go back to this.

I’m saying our data rate should be around 128 Mbps. So why is our speedtest only around 70 Mbps on the download? BECAUSE IT’S WIRELESS! At best, for 11n and 11ac, you’ll get about 60% of your data rate as actual throughput. And guess what? 60% of 128 Mbps = 72.6. So we’re pretty close to what a perfect speedtest for MCS 6 should be FOR THIS DEVICE. Note that other MCS 6 values on the chart can go as high as over 1755 Mbps! That’s why you have to understand the specifics of each client device being used in testing if you are trying to base decisions about network performance on the results of speedtests.

TIP: In all practicality, if you take the time to master this methodology, if you realize 50% or better of an expected data rate during a speedtest, the network by this measure is generally fine.

But wait- there’s more!

So why did my Nexus 7 connect at MCS 6 for the faster test? It did so because I was fairly close to the AP and my strength and SNR were good. As my SNR decreases (because I get further away from the AP or because of interference), My MCS value will drop, and my speedtest results will follow- as reflected in the second test where things felt slower. But both were valid for the circumstances.

Use this methodology, please! 

This was a long piece, but the process is pretty simple at the end of it all. If you can digest and use this, you’ll make more realistic determinations about network problems, and you’ll also really start to understand Wi-Fi better.

If you do the exercise and get far less than you expect for a speedtest result, run it again. And again. Go at least 5 passes in case whatever server you’re using is getting creamed or some transient condition hit while you’re testing. If you are still getting low results after multiple passes, confirm them with another Wi-Fi client in case your first one has some oddity (driver wonkiness, OS updates in the background). And if both devices show less than expected… you’ve probably found a network problem. The bonus- you’ve done it methodically, and established a quality baseline to work the problem from.

Xirrus Loses One, Wins One

One of the more curious WLAN players in the market, Xirrus is always interesting. The wireless array company certainly doesn’t sit still from a development perspective, and is usually among the first WLAN vendors to get major popular new features announced. I’ve met with Xirrus at Wireless Field Day 5 (their presentations here) and WFD 6, and followed their evolution through the years with a number of articles written about them..

Of late, Xirrus has a bit of a bad news/good news story to tell.

The bad news- they’ve been dropped from Gartner’s 2015 Wired and Wireless LAN Access Infrastructure Magic Quadrant. Many of us in the WLAN industry have fairly low regard for Gartner’s current methodology in this space, but at the same time those in the market for business Wi-Fi frequently refer to the report for information on the pros and cons of industry players. I don’t agree with Xirrus’ exclusion, but it is what it is.

On the sunnier side, Xirrus has just announced a potential game-changing feature for customers struggling to do secure guest Wi-Fi. Called “EasyPass Personal”, it’s easy to mistakenly equate the new offering to the likes of Aerohive’s Private PSK. Xirrus differs significantly from just PPSK in that EasyPass Personal allows the guest/visitor to set up their own SSID and private pre-shared key. Yeah, read that again because it’s pretty wild.


See more on Xirrus’ web site here.

My thoughts on EasyPass Personal: I’ve not tried it, so can’t speak to the feature first-hand. My only real concern is whether the generation of personal guest networks in the air creates a lot of management overhead traffic (seems like it could, at first thought). But beyond that, I applaud Xirrus for bringing an innovative new option to the ridiculously challenging paradigm of secure guest access. Hotspot 2.0 is the promised “official” answer to secure guest Wi-Fi, but it’s both complicated and going nowhere. EasyPass Personal *seems* like a nice methodology, so I’d love to hear from Xirrus users who try it.