Category Archives: WLAN

The Network is Code: Cisco at MFD4

It’s always a bit of a thrill to visit Cisco HQ, and to step within the walls of this global network powerhouse. I got to do that again at Mobility Field Day 4, and as usual the presentations and the visit just went too fast. Such is the way these events go… On this go round, Cisco offered us:

Each is interesting and informative, especially when combined with the delagates questions. You’ll be glad you watched them, if you haven’t yet.

But something else jumped out at me at this event, and it may seem silly to even mention. Have a look at this sticker:
Code Pic

The wording of it got my mind working. In a number of directions.

I’m just sharing what’s in my head as a long-time Cisco wireless customer as I ponder the message on that innocous sticker.

I’m glad to see that CODE is the network, because it hasn’t always been. CODE, as presented like this, implies “reliable code, as surely you don’t want an unreliable network”. To that I would add “especially at the costs charged for licensing the hell out of everything”.  The sticker mentions CODE + the 9000 Catalyst Series, and perhaps sends the message that it’s a new day for reliability? On that topic, the CODE in this case is IOS-XE, which displaces AireOS as what powers the Cisco line of wireless controllers. I do hear often that “IOS-XE has been out a long time so it has to be solid by now” kinda talk.

I’m not sure I buy into that, but am hopeful. If I’m a little skeptical, it’s because IOS-XE packaged as a wireless controller brain is a new paradigm, despite the maturity of the OS. And… despite many, many mea culpa  sessions in private with Cisco’s wireless business unit through the years over wireless code quality, I have yet to see any sort of public-facing commitment to not repeat the development sins of the past as the new magic seeks to gain traction. This bothers me, in that I don’t know that the background culture that allowed so many problems with the old stuff isn’t being carried over into the new. My problem, I know. But I’m guessing I’m not alone with this feeling.

The other thing thing that this sticker has me thinking about is this: if  the network is code, why do I need controller hardware? Yes, I know that the 9800 WLC can run in VM- but VM instances ultimately run on hardware. As a big Cisco customer with thousands of 802.11ac access points that run the latest AP operating system, I would love to be totally out of the controller business (and all the various management servers needed) WHILE KEEPING MY INSTALLED ACCESS POINTS. If the network is code, maybe let me point these things at my Meraki cloud and simplify life?

I’m just one man, with opinions. But that sticker did get me thinking…

 

Code, Heal Thyself: Mist Systems Brings Something Badly Needed to WLAN Market

If you do any profession long enough, you’ll experience all sorts off good and bad along the way. For me, “good” has been the honor of providing reliable Wi-Fi to hundreds of thousands of client devices through the years, and “bad” has been fending off downtime and damage to organizational reputation when code bugs hit. Why focus on code bugs? To me, they are the one huge factor in WLAN system operation that we as wireless professionals can’t control. We can get everything else right from RF environmental design to RADIUS server capacity to onboarding clients, but we can’t defend against what evil lurks in the lines of code that runs the system hardware. Nor should we have to- that’s where we expect vendors to hold up their end of the deal on hardware and software that ain’t getting any cheaper.

Oh, how I have bitched and whined and complained about code bugs through the years. There was “The Horrible Bags We Hold For WLAN Vendors“. And “Code Suck Regulation: Should We Sue Vendors For Major Code Bugs?” I got a bunch of them… and it’s not just me. One of my favorite people, Jake Snyder, laid down a really good video lament on the topic. No one can forget my own video from the Wireless LAN Professional Conference in 2017 where I detailed real-world impact of code bugs. It’s a real thing, ya’ll.

I titled one post on the topic “Will Reliability Be Prioritized Before Wi-Fi’s Whiz-bang Future Gets Here?” (a house built on suck cannot stand).  This one jumped to mind yesterday as I sat in a Juniper Networks conference room in San Jose and heard Mist Systems talk about reliability. What I heard was refreshing.

Mist CTO Bob Friday and his crew presenting at Mobility Field Day 4 detailed how the company’s AI does all kinds of things- but among the most important is finding it’s own system anomalies. The gravity of the point is fairly significant, as one vendor after another wants to put a dashboard in front of you that calls out anything and everything as a wireless problem for you to chase after, but none that I know of will raise their hand and admit “OK- I’m actually the problem here… me, the system. I screwed up… I’ll fix me so we can all move on. Beg your pardon…” But now Mist is promising that, and it’s huge.

CTO Friday not only called out this capability, but was kind enough to give me a shout out for my years of crying like a school girl about code bugs, which was thoughtful.

IMG_3558.jpg

Well done, Mist Systems! There was a hell of a lot more to the presentation- and in the couple of hours I listened, I was impressed that Mist has managed to boil the hype off the concept of AI and actually did a decent job of explaining real-world, practical applications and benefits. There are several videos from the session, and they are worth watching.

More about Mobility Field Day 4 here.

 

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