Category Archives: WLAN

Ekahau Retools For The Future

As a long-time Ekahau user (pretty sure I was one of the first few American customers way back when), I’ve gotten used to continuous improvement and evolution from Ekahau Site Survey (ESS) suite of tools. There have always been new features right around the corner, and the company has been perhaps the best I’ve ever seen at gathering and acting on user feedback. It’s been a great run. In the recent past, the hot-selling Sidekick provided a unique new dimension to the survey and spectrum analysis processes, and the Ekahau company was purchased by Ookla/Ziff-Davis. Both of those developments are pivotal to what comes next for Ekahau.

And what comes next is called Ekahau Connect.

Ekahau Connect

There’s  A LOT here to talk about, starting with ESS getting rebadged as Ekahau Pro, now compatible with both Windows and Mac operating systems. (If you are new to the world of WLAN support, trust me that Mac is a far-better tool platform than Windows- and I am unabashedly NOT an Apple lover.)

Then there is Sidekick’s expanded capabilities- including wireless packet capture leveraging Sidekick’s dual radios (yay!) and the ability to interface with the iPad as a survey platform. This is a pretty big deal, and the light physical weight of the iPad makes for easier, more comfortable surveys.

Ekahau iPad

And… Ekahau does a little catch-up with it’s introduction of Ekahau Cloud. This is one extremely valuable capability that competitor iBwave has had for some time, as I wrote about here. Having used iBwave’s cloud tools, I can assure you that Ekahau’s customers who work in teams are going to love it and there is no doubt that the cloud expertise behind Ookla has some impact here.

And is if this all wasn’t enough for Ekahau Nation, feast your eyes on another new benefit- Ekahau Connect components working together to identify, classify, and locate interferers:

interferers

I have been fortunate in that I have been a beta tester for Ekahau’s latest. At the same time, a couple of serious “life happens” events have kept me from being a good beta tester. So for real-world first-hand perspective, I’ll hand you to two two of my favorite people on the No Strings Attached podcast.You’ll be in good hands with Sam and Blake.

 

 

Announcing #WIFIQ 2.0

I’ve heard the cries of anguish. I know the many lives that have been ruined and rendered meaningless since I announced the end of #WIFIQ on Twitter at the end of last year. I too have lived in silent agony since the daily discussion exercise went dark, even though that darkness was of my own making.

I’m well aware of the value that others have found in #WIFIQ, and I again thank all of the individuals and organizations like iBwave who have said kind things about #WIFIQ.

And now… I’m happy to announce that #WIFIQ is back, baby!

But going forward, the NEW version of #WIFIQ will not flow from my muscular, impressive fingertips. Ah, the stories those fingertips could tell…  *Ahem* It’s time for fresh minds to take up the cause, and I’m tickled to announce that the Wireless LAN Association (WLA) has expressed the desire to bring back the good thing that is #WIFIQ.

I’m not sure exactly how the WLA will originate their questions, or if they will take input like old guy who did #WIFQ did. But I do know the men and women of the WLA are good folks with great minds, and I haven’t a worry in the world that they will do justice to the #WIFIQ concept.

If you don’t yet follow the Wireless LAN Association on Twitter, get yourself hooked up with @WLANAssociation handle and standby for #WIFIQ and related news as they re-prime the pump of wireless knowledge, fellowship, and goodness.

I salute you, WLA.

wlan-association-logo-gold

Move Wi-Fi Explorer From Old Mac to New

The Mac laptop that hosts my excellent Wi-Fi Explorer Pro application has seen better days. It’s time to put this awesome WLAN support tool from Adrian Granados on a newer Mac, but I was a bit stymied when I first tried to figure out how. I envisioned some sort of license key transfer, but just wasn’t seeing it… I queried my best WLAN community homies, and dropped a line to Adrian himself. Before a meaningful response came back, I figured it out, and so thought I’d share.

It’s easy-peasy, once you see it.

1. De-Activate Wi-Fi Explorer Pro on Old Machine, under “Help”

Deactivate WFE

2. Download, install trial version of Wi-Fi Explorer Pro on new machine

3. Fire up the program, find these options:

Activate WFE

4. Dig out your license file- search on “Paddle license” in your email:

WFE License

5. Enter the license key and activate the program. 

Like I said… easy.

DON’T FORGET ABOUT THE DISCOUNTS ADRIAN GRANADOS HAS OFFERED FOR NEW PURCHASES OF WiFi Explorer PRODUCTS!

  • Educational customers get 50% off. Details are here.
  • Everyone who attended WLPC Conference in February ’19 was given a card for a 30% discount on WiFi Explorer Pro. You need the code from the card, and the discount is available until 3/31/19.

Now you now.

Contemplating APIs and the WLAN State of Things

Having just attended the 2019 Wireless LAN Professionals Conference (WLPC), I got a few days full of really interesting perspective from other WLAN doers. I saw and heard predictions, hopes, and fears for what comes next as we roll toward 802.11ax, the coming of 6 GHz spectrum to Wi-Fi, and more widespread use of WPA3. There was a lot of good chatter, because there simply is no conference like WLPC (I recommend it to anyone who is in WLAN practice/management, or over those who who are).

One thing I heard A LOT about was APIs. And using Python to get more out of our WLAN hardware and management systems. And… how “you should all learn to do coding!” I have no issues with any of these, but I also tend to be a 10,000 foot thinker and so couldn’t help but ponder the real-world implications of all that when it comes to how wireless systems are actually run day-to-day. I also found that I wasn’t alone in my contemplation in talking with others at the event.

Let me get right to my points- I have great appreciation for the flexibility and capabilities that using APIs can bring to a WLAN system. But… that is balanced by a number of concerns:

  • If a vendor has historically put out crappy code that is developer-driven versus engineer-driven, how do we trust the developers to get it right when it comes to what data awaits engineers at the end of the APIs?
  • I fear that “and we have an API!” can become a cop-out for NOT putting out a complete enough NMS system for the high costs that you’ll still pay for these NMS systems. As in… “oh THAT feature is leveraged by the API”, and not in the expensive management GUI that maybe now is missing common-sense basic functionality.
  • In some ways APIs-to-the-rescue is a huge step forward, in other ways it’s an admission that vendors sometimes can’t build an NMS that doesn’t suck (because if they could, maybe we wouldn’t need APIs?) Maybe…
  • Not all WLAN staff teams will want to be in the programming business. Time will tell if they will be able to work effectively as they avoid the API and try to stick with the NMS and non-API tools.

None of this is necessarily my own strict opinion as I digest everything I’ve seen and heard at this year’s WLPC, but I heard enough from other people to know that the community is not in lockstep embrace of “API all the things”. Some teams are just stretched thin already, and pay a good buck for vendor tools so they don’t have to become programmers to keep their WLANs on the rails. Then there’s the always-relevant “evolve or watch your career die” school of thought that can’t be ignored either.

Fascinating times. Much change is in the air.

Now onto one of the most interesting things of all that I heard at WLPC: more on Open Config. Mike Albano from the Enterprise side at Google planted some fascinating seeds back in 2017 with a presentation he did at that year’s conference:

Introduction to OpenConfig; What Is It, What Does It Mean To Wi-Fi | Mike Albano | WLPC 2017 Phoenix from Wireless LAN Professionals on Vimeo.

Mike was on the stage again this year doing a little follow up on progress made with Open Config. He also participated in a Whiskey and Wireless Podcast with a couple of nicely-hatted lunatics and shared even more with an eager audience. I suggest you keep an eye out for both his recorded WLPC presentation and the podcast to come live (I’ll add the links here as well), because Open Config is the API concept on steroids. As mentioned in the 2017 video, but expanded on this year, Open Config seeks to make the software side of many vendors’ wireless offerings largely irrelevant. You gotta hear it.

Given that we’re in an era where WLAN vendors have declared themselves “software companies” who happen to put out some pretty crappy software and then charge through the nose for it, Open Config is interesting for reasons far beyond it’s API-ness.

Like I said, these are fascinating times.

Enhance Your Wi-Fi Mojo With Old-School Radio Hobbies

I have this odd love of some really arcane signals. With a modest but decent receiver from Tecsun (the PL-880), I take advantage of the winter months in the northeast (less atmospheric electricity and no thunderstorms) to “hear” these quirky Longwave signal churn out slow Morse Code identifications. It’s utterly addicting to the right-minded radio geek, and also draws large parallels to what goes on with Wi-Fi that help reinforce my WLAN foundational knowledge.

For wireless networks , we know that output power, antenna choices, the environment where we’re operating, and the capabilities of the client devices all contribute to whether Wi-Fi is “good” or “bad”. If the signals can’t get through, then the microprocessors involved can’t turn those signals into data. Let’s talk about what it feels like to listen to NDBs for a bit, then how that relates to Wi-Fi.

I live about an hour south of Lake Ontario in the middle of New York state. With my beloved Tecsun PL880, I recently received an NDB signal from Pickle Lake’s little airport in Ontario Canada. This location happens to be several hundreds of miles away. The beacon transmitter (considered a “navigation aid”) at the airport generates a fairly low-power cone of  signal into the sky, more or less straight up (that’s the non-directional part of “NDB”). The intelligence in the signal is simply slow Morse Code continuously looping the letters Y-P-L. See this link for  information on the airport.

Pickle Lake

Given that any beacon is typically low powered and pointed straight up, finding them on the air from afar is a sport unto itself. Longwave spectrum sits below the AM broadcast band, way down where frequencies are measured in kilohertz.  It’s absolutely cluttered with man-made signals, and is at the mercy of natural electrical interference, like lightning strikes (called “static crashes” int the radio world). Yet I was able to discern that slow Y-P-L signaling from across a huge Canadian province and a Great Lake, making it an accomplishment as a signal-chasing radio hobbyist.

If you’re not familiar with Morse Code, that Y-P-L formats like – . – – / . – – . / . – . . (dash-dot-dash-dash/dot-dash-dash-dot/dot-dash-dot-dot).

In 802.11 WLAN, specialized modulation helps to ensure that the important signals prevail despite RF conditions being crappy enough to kill narrow-band signals. I see Morse Code is somewhat akin to spread spectrum when I’m chasing NDBs as the dots and dashes can often be heard through really bad conditions that would utterly destroy voice signals. (This is actually why Morse Code was created and used as a mainstream long-distance radio communications mode for so long.)

When Wi-Fi signal quality is degraded, data rates will decrease. When I hunt down NDBs like Y-P-L signal, I might have to listen to each for several minutes and manipulate the filters on my receiver before I know what I’m actually hearing- and sometimes I just can’t quite clarity.  For this and other radio activities, my own ears and mind are the actual microprocessor. Call me silly,  but each beacon identified is like catching a nice fish and brings it’s own little flicker of excitement. Here’s a great list of Longwave NDBs out there to chase, and there are many other lists to be found online.

For improved reception, I could connect my PL880 at to a better antenna, just like in Wi-Fi. I could improve my “data rates” (or words-per-minute copying) by using better filters and practicing my Morse Code more. This would make me a better “microprocessor” in this activity.

Really geeky stuff, eh? I have no problem wearing that label. I also know that there are other radio nerds out there in the WLAN community, as well as those who want to learn more about radio “stuff” beyond Wi-Fi. For those folks, I’ll be teaming up with Scott Lester to present “Radio Hobbies for the WLAN Professional at the 2019 WLAN Professionals Conference. Sign-ups start mid-December, and I hope to see many of you there!

WLPC2019DD.jpg

Stop the Little White Wi-Fi Lies- Data Sheet Specs Matter

There I sat in a pleasant regional users meeting for a large networking company.  It was a decent presentation that provided me with some food for thought, and so I was glad I went. But there was one statement made while talking about pending 802.11ax access points that raised my dander.

I’m paraphrasing here…

The data sheet will say the AP can do over 1,000 clients, but you know how that is…”

Hmmm. There was some discussion in the room after that statement- I asked how we as Wireless Doers are supposed to reconcile these grand claims that WE all know are bullshit with the expectations of CUSTOMERS who DO NOT recognize the same info for the operational untruth that it is.

“It’s theoretical”

“Everybody does it”

Again… hmmm. Lee’s not buying it. A lie that we all choose to live with is a still a lie. This isn’t even the biggest whopper out there… Another vendor right now is touting an AP that can do FIFTEEN HUNDRED CLIENTS!

So all I need is a dozen per stadium and I’m the most efficient LPV wireless guy in the land, no? I can design my networks for 1 AP for every 1000 (or 1500) Client devices and reduce my AP spend significantly! All right! Except it doesn’t work this way.

Why do I care, really? What about this one little falsehood got me perturbed? Because we spend money based on what data sheets tell us. It’s insanity to SEE one number, but then have to go ask someone else what that one number REALLY means. Let me tell you a couple of stories of data sheet burn that I still carry scars from.

When 10 Gig Is Not


8510a

This  screen grab comes from a leading vendor’s now EOL wireless controller. 10 Gbps is clearly stated as what the controller will “do”, at least by my interpretation. Nowhere in the spec sheet does it say “…unless you run a highly desirable feature called Application Visibility and Control, which then knocks the unit’s throughput capabilities to well under 3 Gbps“. That little gem you have to discover for yourself and suffer through… while 20K wireless clients get pissed off as the WLAN core melts down. No “if this, then that” qualifiers to explain that a popular feature would neuter your throughput by an order of magnitude- just “10 Gbps”. I fell for it, and got burned bad.

Is 3,000 APs + 802.1X Significant, or No?

Same vendor, beefier controller.
8540a
In the midst of another support case that impacted multiple users, the TAC person said something like “I see you have over 3,000 APs and are doing 802.1X…” with great concern in his voice. I asked- “So? Is this a problem on a controller that supports 6K APs?” The fellow put me on hold for several minutes to talk with somebody else about the point. Meanwhile, a colleague in another part of the world sent an email raising the same flag on one of his own support cases- there seemed to be a common TAC-side fixation with 3K APs and 802.1X on a controller that is rated for 60K clients. My TAC guy eventually came back and said “um, no, that should be OK” in a voice that didn’t exactly inspire confidence, and it immediately hearkened me back to the the great meltdown on the other controller. The point was raised yet again by another support person as the case played out, who also avoided explaining why this seemed to be of concern when I asked.

I still have no idea whether 3K APs and 802.1X are the ingredients for an eventual meltdown on this controller, or whether perhaps inexperienced support engineers talked out of school. Given my past experiences on this product line (I’ve only mentioned the tip of the iceberg here), my confidence was very much shaken by the thought of some sort of undeclared 3,000 AP “wall” that I had hit. (A code upgrade, or rather multiple code upgrades, eventually got me past whatever the original problem was in this case.)

To me, the data sheet is gospel as presented – if there are exceptions, caveats, qualifiers, or whatever- the vendor needs to get it out there ON THE DATA SHEET. My end result- I have little confidence in ANYTHING to do with spec from this vendor on this product set.

Speaking of exceptions, caveats, qualifiers, or or whatever…

The Enterprise WLAN vensors can actually learn from the “little guys” when it comes to technical honesty. Have a look at what Amped Wireless includes on their data sheets: 


Specifications are subject to change without notice.

1 Range specifications are based on performance test results. Actual performance may vary due to differences in operating environments, building materials and wireless obstructions. Performance may increase or decrease over the stated specification. Wireless coverage claims are used only as a reference and are not guaranteed as each wireless network is uniquely different. Maximum wireless signal rate derived from IEEE 802.11 standard specifications. Actual data throughput may vary as a result of network conditions and environmental factors. Output power specifications are based on the maximum possible radio output power plus antenna gain. May not work with non-standard Wi-Fi devices such as those with proprietary software or drivers. Supports all Wi-Fi standards that are compatible or backwards compatible with 802.11a/b/g/n/ac Wi-Fi standards.

2 All transmission rates listed, for example 800Mbps for 2.4GHz and 1733Mbps for 5GHz, are the physical data rates. Actual data throughput will be lower and may depend on external factors as well as the combination of devices connected to the router. AC2600 wireless speeds are achieved when connecting to other AC2600 capable devices.

3 May not work with non-standard Wi-Fi routers or routers with altered firmware or proprietary firmware, such as those from third party sources or some Internet service providers. May not work with routers that do not comply with IEEE or Wi-Fi standards.

4 For MU-MIMO to work, additional MU-MIMO capable devices must be connected to the network.


You can argue that no one reads the fine print, but I would disagree. As is, deception and partial truths are problematic and confusing. What else on the data sheet can’t be trusted? And why do it, at all? Seriously- why say an AP will do 1000+ clients? Where is the “win” for anybody other than the Chief Embellishment Officer?

What Wi-Fi Tools are MetaGeek and Oscium Cooking Up Together?

As I write this, the 2018 Wi-Fi Tek Conference is going on in San Diego. I’m not attending (mostly because Boardman is there) but I am listening to various comments being made about the event goings on though the many channels that all of us WLAN types keep each other updated on. There’s a lot of good chatter, and I wish my CWNP family the best of luck with conference (I am on the CWNE Advisory Board you know… I run in those circles.) One little nugget from Twitter caught my attention, in particular.

metageek-oscium

I happen to have products from each company, and both are among my favorite tools when it comes to WLAN support. After the tweet, I went and found MetaGeek’s own announcement on the new partnership, which you can read about here.

Oscium Logo

metageek_logo-250x51

Now, betwixt you and I- neither company has been especially active of late as far as getting new tools (or even updates to existing tools) out in front of us loyal customers, and I’m glad to see hope of that changing.

I’ve written about Oscium in the past and still think their WiPry 5x is one of the slicker spectrum analyzers out there for those of us that have familiarity with real lab-grade spec ans. I’ve also covered MetaGeek through the years, and was fortunate enough to see their presentations at multiple Tech Field Day events. You won’t find nicer folks than MetaGeek’s current and past employees… must be a Boise thing.

Now back to that announcement of a partnership between MetaGeek and Oscium. We still don’t know a lot, but this is pivotal from the MetaGeek blog:

MetaGeek plans to partner with Oscium for additional hardware offerings moving forward as part of the company’s shift to focus on the software side of their industry-leading Wi-Fi analytics solutions.

Just as Ekahau has realized, you can only take legacy USB adapters so far in the world of 802.11ac (and soon .11ax) wireless support tools. MetaGeek has had profound impact on the WLAN industry with their USB-based stuff, but it also became stunted despite having really effective software pairings (like Channelyzer, InSSIDer, and the fantastic Eye P.A.). Oscium has figured out how to leverage well a range of mobile devices (both Android and Apple) and their latest connectors for use as Wi-Fi support specialty tools.

I smell synergy, baby…

I have seen nothing in beta as for as this story line goes. I’ve had no conversations of late with either MetaGeek or Oscium, so I really can’t give you anything beyond speculation and hope that good things are coming, but I also have a lot of faith in both companies.

I’m looking forward to the end of the year, and whatever announcements these two toolmakers are working on.