Category Archives: Wireless Networking

That Which Pisses Us Wireless Folk Off- Vendor Edition

Now there’s a title. And since you’re reading this, you bit on it… Sucka. Now that you’re here, let’s share some observations from the WLAN community over the last few weeks. This is not (totally) a “Lee’s complaining again” blog; it’s more a collection of sentiments from dozens of friends and colleagues from across the Wi-Fi Fruited Plain that stuck with me for one reason or another.

Most of these observations are aimed squarely at our vendors- those who we do business with “above” as we shape their offerings into the systems and services we offer to clients “below”, with us in the middle.

You may not agree with all of these. Perhaps some of your own beefs didn’t make my list. Either way, I’d love to hear from you in the comments section. Now, in no specific order:

  • Marketing claims. OK, we’re starting out with the obvious. Wi-Fi marketing has always been about hype, far-fetchedness, and creative blather. Nothing new under the sun here. I truly hope that your 10x better Wi-Fi is serving up 500 APs per client that are all streaming 62 Netflix movies each simultaneously from a range of 37 miles away from the AP.
  • “Enterprise” switches that don’t stack. Stacking is neither new, nor special. Do your bigger switches stack? Is it not even an option? If not, maybe tone down calling them “enterprise”.
  • Big Bucks for power cords. You got major balls as a vendor if you’re pricing garden variety power cables at $20 per.  Shame on you. Same same for PoE injectors, nothing-special antennas, rack mounts and assorted other parts/pieces that can be gotten for pennies on YOUR dollar elsewhere. C’mon…
  • No version numbers. By now, we all get “cloud”. And most cloud infrastructure vendors ARE using OS version numbers as a point of reference for their customers. The absence of version numbers becomes more onerous as ever more features get added. Give us the damn version number. Do it. Doooooo it.
  •  No CPU/Memory/Interface stats. It doesn’t matter what the “thing” is, or whether it’s cloud-managed or not. EVERY interface needs to show statistics and errors, and every thingy needs to show CPU and memory information. Whatever your argument to the contrary may be, I promise that you are wrong.
  • Frequent product name changes. Just stop already.
  • The same stinking model numbers used for everything. Why? Maybe someone has a 3 and 5 fetish out in Silly Valley. It’s confusing, it’s weird, and it’s weirdly confusing in it’s weirdness, which leaves me confused.
  • The notion that EVERYTHING to do with wireless must be monetized. After a while, we start to feel like pimps as opposed to WLAN admins. I get that vendors need to be creative with new revenue streams, but it can be carried to extremes when applied to the WLAN ecosystem.
  • Too many models. It seems like some vendors must be awarding bonuses to HW developers based on how many different versions of stuff they can turn out, but customers are left confused about what to use when and where and why versus the other thing down the page a bit. Variety is good, but massive variety is not.
  • Complexity. This might be news to some vendors: the ultimate goals in deploying your systems for both us and the end user are STABILITY and WELL-PERFORMING ACCESS. Somewhere, vendors have lost track of that, and they are delivering BLOATED and HYPER-COMPLICATED FRAMEWORKS that place a cornucopia of buggy features higher on the priority list than wireless that simply works as users expect it to.
  • Slow quote/support ticket turnaround. Most times when we ask for pricing or open a case with technical support, it’s because there is a need. As in, we need something. And our assumptions are that our needs will be fielded with some degree of urgency, as we’re all in the business of service at the end of the day. No one likes slow service. No one likes asking over, and over, and over, and over, and over if there are any updates to our need possibly getting addressed.
  • Escalation builds/engineering code bugs. At the WLAN professional level, most of us work off the assumption that if we don’t typically do our jobs right the first time, we may not get follow up work and ultimately may be unemployed. That’s kind of how we see the world. I’m guessing that WLAN code developers play by different rules. ‘Nough said.
  • Bad, deceitful specs. Integrity is what keeps many of us in the game as professionals. Our word is our bond, as they say. Can you imagine telling someone that you can deliver X, but then when they need X, you can actually only provide a fraction of X- and then expecting that person to not be pissed off? Why are networking specs any different? Enough truth-stretching and hyper-qualified performance claims that you have to call a product manager and sign an NDA to get the truth about.
  • Mixed messages. OK, we ALL own this one- not just the vendors. The examples are many- grand platitudes and declarations that might sound elegant and world-changing in our own minds, but then they often fizzle in the light of day. Things like…
    • We need mGig switches for 802.11ac! 
    • We’ll never need more than a Gig uplink for 802.11ac!
    • 2.4 GHz is dead!
    • Boy, there’s a lot of 2.4 GHz-only clients out there!
    • We’re Vendor X, and we’re enterprise-grade!
    • Why do I see Vendor X gear everywhere, mounted wrong and in nonsensical quantities for the situation?
    • That one agency is awesome at interoperability!
    • Why does so much of this stuff NOT interoperate?
    • You must be highly-skilled with $50K worth of licensed WLAN tools or your Wi-Fi will suck!
    • Vendor X sells more Wi-Fi than anyone, most people putting it in are obviously untrained, yet there are lots of happy clients on those networks!
    • Pfft- just put in one AP per classroom. Done!
    • Cloud Wi-Fi is a ripoff!
    • Cloud Wi-Fi saves me soooo much money and headaches!
    • Here’s MY version of “cloud!”
    • Here’s MY version of “cloud!”
    • I freakin hate how buggy this expensive gear is!
    • At least those bugs are numbered on a pretty table!

It goes on and on and on. Always has, always will. Behind the electronics that we bring to life and build systems from are We the People. The humanity involved pervades pretty much everything written here, from all sides and all angles. And I have no doubt that every vendor could write their own blog called “That Which Pisses Us Vendor Folk Off- WLAN Pro Edition”.  Touche on that.

Ah well- there’s still nothing I’d rather be doing for a living.

Will Reliability Be Prioritized Before Wi-Fi’s Whizzbang Future Gets Here?

This blog looks forward, but before we go there we need to zoom back to 1983 where I will corrupt John Mellencamp’s “Crumblin Down“:

Some features ain’t no damn good
You can’t trust ’em, you can’t love em
No good deed goes unpunished
And I don’t mind being their whipping boy
I’ve had that pleasure for years and years

Indeed. I too have had that pleasure for years and years. Whether it’s what comes out of mechanisms that are supposed to ensure that standards and interoperability testing bring harmony to the wireless world (but don’t), or code suck that flows like an avalanche coming down a mountain, I’ve been there and suffered that a-plenty. Somewhere during one of many wireless system malfunctions, the opening lyrics of “Crumblin’ Down” started blaring in my head, usually followed up Annie Lennox singing this line from 1992’s “Why”:

Why can’t you see this boat is sinking
(this boat is sinking this boat is sinking)

But enough of the musical ghosts trapped in my head, waiting to sing to me when the network breaks. We’re going forward, and as Timbuk3 sang in 1986- The future is so bright I gotta wear shades.

Maybe, maybe not on that.

Super-Systems Become Super-Terrific Systems

Soon, market-leading WLAN vendors will likely unveil grand strategies that finally bring real SDN kinda stuff to the Wi-Fi space. And just like the day is fast coming where you can’t just buy a simple RADIUS server from the same folks (you have to invest in a NAC system then simply NOT use the parts that aren’t RADIUS to get a RADIUS server), one day some Grand Orchestrator of All Networky Things will get it’s tentacles into our wireless access points and controllers and you might not have a say in that. (Some of this is already happening with specific vendors, but it’s all just warm-up for the big show, in my opinion.)

This magic in the middle will promise API-enabled everything network-wide, so provisioning and on-going operations on LAN and WLAN will be child’s play. The frameworks will have spiffy marketing names, and get pushed heavy as “where our customers should be going”.

Some of you are probably thinking “So what? This is evolution. Deal with it.” I’m down with that, to a point.

What If They Don’t Fix What’s Broke First?

I know well that I’m not alone in feeling a bit behind the 8-ball when it comes to our networking vendors. There are far too many code bugs impacting far too many components, end users, and networking teams. There’s also an entrenched culture that keeps chronically problematic operating systems alive when they should arguably be scrapped and the bug factories in full production.

I personally shudder to think what might happen if that grand vision for the future meets the Culture of Suck, and a whole new species of bug is unleashed on end users. Ideally, vendors would take a hard look at their code bases, their developers, and their cultures and ask if what’s in place today is worth rigging up a bunch of APIs to as part of The New Stuff.

As an end user, it terrifies me.

A House Built on Suck Can Not Stand

As a man-of-action-living-in-the-world, I’ve been around.  I’ve seen first-hand what happens during earthquakes to buildings and people when there are no rules governing building quality. I’ve seen carnage and devastation in multiple situations “out there” that all could have been prevented, and when I became Deputy Mayor of my village, I was able to appreciate what our Code Enforcement Officer does to keep people and buildings safe. Often it’s just curbing somebody’s foolish way of doing something.

As silly as it sounds, I’d love to see independent Code Enforcement Officers  for the network industry who enforce… well, code quality.  They would audit developers, their track records, and the pain inflicted on end users. Any vendor that gets too sloppy gets fined, or has to probably clean up their mess before they can keep developing. Like I said, I know how silly that sounds- but the current culture of poor Quality Assurance and protracted debug sessions at customer expense does not serve as a suitable foundation for the Super-Terrific Systems that are coming our way.

What’s really scary is that vendors tend to go all-in on these initiatives. It’s not like they leave a de-bloated, scalable option (key phrase) for those who don’t want all the Terrific Superness as they develop these monster frameworks of complex functionality.

I’d like to put on my sunglasses for the future of wireless, but if things aren’t cleaned up first for certain vendors, the current cloud over their wireless units is just going to get darker.

Sometimes Batteries Conspire Against You

There I was at a customer site, with what should have been just a few minutes worth of work ahead me. I pulled out my beloved CableIQ tester to make sure the cable I was about to use was in good shape, when IT HAPPENED. The tester wouldn’t turn on. And when I opened the battery compartment cover, I saw that the AA cells must have had a party and forgot to clean up after themselves because there was stuff everywhere. Gunky green-white stuff. A couple had exploded, and I suddenly felt both stupid and worried… stupid for having allowed this to happen to my own equipment, and worried that this not-cheap tester was ruined (thankfully it wasn’t, but you don’t always win this game.)

Same site. Pull out my equally beloved Samsung tablet to fire up iBwave Mobile for a quick verification survey.  And… it was also dead. This time I felt the same stupidity, with the added bonus of anger at myself for allowing this tool to also be out of juice when I needed it.

As I finished my work with other tools on hand, I got thinking. What if the battery issues with these two devices wasn’t just happenstance? What if- and shudder to verbalize it- what if my battery-powered devices were actually conspiring against me? What if there was a device-killing plot afoot to punish me for inattentiveness and neglect? Don’t get me wrong, I usually live in the real world, but the little voice in my head said “you better start checking your stuff out pretty quick for other battery issues. Maybe there is an evil plot afoot.” 

And so I got busy checking.

Let’s get right to the carnage:

  • Handheld GPS unit- destroyed by leaked batteries
  • Very powerful laser (that’s right, a frikin’ laser) used for point to point bridge work- destroyed by leaked batteries
  • Small cheapo shortwave radio- not destroyed, was able to clean it up and get it going again
  • Very expensive non-cheapo shortwave receiver- caught the battery leak just in time, before it started flowing for real
  • FRS radios (two sets) – three out of four had some battery leakage, salvaged all but did some damage to battery contacts
  • Big Mag-lite flashlight- destroyed
  • Small Mag-lite flashlight- destroyed
  • Other small Mag-lite flashlight- caught just in time

Not EVERYTHING I looked at had battery issues. I’m a gadget guy for work and play, so I have many, many battery-powered devices. A fair amount of my gear uses rechargeables, which helps the reduce the overall problem. But as you can see, I ended up losing at least a few-hundred dollars’ worth of equipment to my own neglect. You can certainly chalk this whole affair up to “first world problems”, and maybe throw out a snide “maybe you just have too much STUFF”. I would agree a bit on both points, but I also don’t want the point I’m trying to make to get lost.

My destroyed devices didn’t have to end up this way. And my unusable tablet didn’t let me down- I did. I now have a monthly reminder on my calendar to check my disposable-battery-powered  devices, and a weekly reminder to check charge level (and available updates) on all of my many tablets and laptops. And… I’m switching to rechargeable batteries where I can to lower my overall battery consumption.

I tell you my own sad story here so that you may hopefully avoid your own. Now, go check all those devices you’ve been ignoring for the last several months.

Learning to Use iBwave For Wi-Fi Design

ibwaveHaving been invited to try out iBwave’s suite of Wi-Fi design and survey tools, I couldn’t help but do what any WLAN pro does: immediately start judging it against my current tool of choice. For me, that’s been Ekahau for a lot of years. It didn’t take more than a couple of practice runs with iBwave to get the general feeling that it definitely competes with Ekahau, and I’m guessing that the AirMagnet designer/survey devotees would also reach the same conclusion. Each product will absolutely have advantages and subtle weaknesses when weighed against the competition, but in my mind that competition is legitimate and good for those in the market for quality wireless tools.

Back to iBwave and my journey through their Wi-Fi Suite.I had the pleasure of spending around a half-hour with iBwave’s marketing exec Kelly Burroughs in person (we were at the same conference), and she got me started with both the PC and mobile versions of the design and survey tools. Kelly is awesome, but after we parted ways and I dug in more on the tools, I found myself needing a bit more help. Part of the problem is that my mind is conditioned to use my current tools, and iBwave’s interface is different. It’s actually pretty well designed, having just been freshened up in January of 2017. But if you’re not used to something new that has some complexity, anybody might legitimately need some help. This is where iBwave’s tutorials are effective, and appreciated.

I already know HOW to design and survey. I just needed to learn how iBwave’s tools are leveraged to do that which is otherwise familiar to me. So… about those tutorials- once you start the PC software, you’re presented with very well-done walk-throughs on the major tasks if you need them (as shown below).

iBwave tutorials
These lessons are handy as heck, and did me up well as I got through my early projects.

As iBwave seeks to make a bigger noise in the WLAN design space, they are also coming out with certification training for their customers. iBwave Wi-Fi Mobile training is available now, with iBwave Wi-Fi (for PC) formal training coming in April.
I think we’ll be hearing and seeing a lot more from the company on numerous fronts in the days to come as they try to grow a following for their Wi-Fi tools and a name as not just a DAS design company.

Read my write-up on taking iBwave for a spin here.

Wi-Fi NOW Conference in April Looks Pretty Damn Good

FINAL_Wi-Fi-logoSo many conferences, so little time. I know that I’m not alone in wishing that I had the time and budget to attend all of the conferences that are available these days to WLAN professionals. There’s one coming up fast (April 18-20) that has my interest piqued, and that’s the Wi-Fi NOW International Expo and Conference, in Washington DC. Given that I just attended the WLAN Professionals Conference in February, my circumstances don’t let me get to Wi-Fi NOW.

But… being a good looking, well-connected gonzo bloggist does afford me certain other little perks- like being able to talk with the man behind Wi-Fi Now to get his perspective on why this event is getting to be very popular. I caught up with Claus Hetting (CEO and Chairman of Wi-Fi NOW, video blogger, and all-around Wi-Fi guy) and gave him a chance to share why he’s passionate about the conference.

Here’s how it went:

ME: I can’t make this one, Claus. But it looks like it’s gonna be awesome.
Claus: we will miss you at the event but very much hoping to get you on board for the next one 🙂

 

It looks like you have great representation from a variety of wireless spaces and interested parties.
Claus: Indeed. We’re covering all of in-home, enterprise, cities, carriers, emerging markets, and security.

That’s awesome. What are you especially excited about for the attendees?
Claus:
 For your contacts this is probably the most important: We’ll be taking a deep-dive into all the new standards including ax, HaLow, and WiGig including presentations & panels with the tech & business leaders in Wi-Fi.

What are the bigger players bringing to share?
Claus: We’ll have keynotes by the Wi-Fi Alliance, the FCC will be there, various well known analysts will present, and we’ll have lots of lively debates & discussions.

Is this one of those events that’s only for big companies?
Claus: We’re very happy that a lot of startups are joining us, too.

Wi-Fi NOW looks like a really decent event for anyone in or interested in Wi-Fi, at any level. What else do my blog readers need to know?
Claus: 
This is the conference agenda. And you can have a look at our Show Guide including main themes here as well.

And there you have it! The lineup of speakers is impressive, and I do look forward to getting to Wi-Fi Now in the future.  If you decide to go, make sure you take advantage of the 25 %discount that Claus has created for readers of this blog. It applies to all ticket types (individual days, expo, Gold pass).

To manually claim the discount, enter this code: LeeBWFN25

Finally, if you have any questions on Wi-Fi NOW or want to follow Claus’ various activities (and he is fascinatingly busy), his contact information is below:

Claus Hetting

CEO & Chairman Wi-Fi NOW
CEO HETTING Consulting
Ph. +45 25 34 17 05
claus@hettingconsulting.com
Skype: claushetting
Web: www.wifinowevents.com

As always, thanks for reading!

Getting to Know Cape Networks

I recently attended the 2017 edition of the Wireless LAN Professionals conference in Phoenix. As usual, it was awesome. Catching up with old friends who are scattered far and wide, hearing information-rich presentations, and meeting new people with their own wireless story made it a very enriching week for me. But part of my learning actually came after the conference. I was saying my goodbyes when a gent named David Wilson asked for a few minutes of my time, and that’s how I would come to know of Cape Networks.

It turns out that Wilson and his travel partner Michael Champanis are two of the co-founders of Cape Networks. These guys were awesome to talk with at the end of a long week, and the conversation flowed easily. I learned that Cape Networks is based in both South Africa and San Francisco, and is trying to raise their brand awareness here in the US. The company is in the business of Wi-Fi performance monitoring and testing through deployed sensors and a deceptively simple cloud dashboard.

I was given a demo of the Cape dashboard and got to handle the low-profile sensors. We talked of how the system finds issues and helps with resolution, and what customers are already using it.None of us was in a particular hurry since our travel arrangements were all later in the evening, so they patiently handled every one of the many questions that came to me during the demo.

I’m hoping to get a couple of sensors in the near future, and to be able to do a proper review. Until then, I can share that the solution looks interesting and of decent quality with the potential to reveal information that other systems I’ve looked at or used don’t really do very well. At the same time, I’m not endorsing Cape Networks here as I haven’t used the solution yet.

But I did find them interesting, with enough potential differentiators that I felt it worth sharing what little I know of Cape so far. Once I do a review on their hardware and dashboard, I’ll be sure to follow up.

Meanwhile, I encourage anyone running business WLAN systems to have a look at Cape Networks’ web site and to learn about a company that you may not have been aware of yet.

How Much Data is Used For Open Mesh Cloud Management?

You got questions, I got answers.

You see, I’m not just a network guy … Nossir,  there’s so much more. My cranium is enormous, I could be a male model, and I’m learning the Ukulele. I’m a CWNE, a newly minted Cisco CHAMPION (that’s right, Bucko- a champion– I might even run in the Kentucky Derby this year), but I’m also a gonzo bloggist. I don’t write the story. I live the story.  Hell, frequently I am the story.

And I ask the tough questions.

Like after I published this article about Open Mesh’s new access points (which I happen to be connected to as I type this, thank you very much) and a cheeky fellow asked me on Twitter something like “how much data do those Open Mesh APs use for cloud management, and would I have to worry about it on small WAN links?” I couldn’t give this gent a straight answer, because I didn’t know. Somehow, my enormous cranium did not have that information stored. But I knew where to go find it, I tellya.

The first thing I did was to go to my Meraki dashboard and look where my Open Mesh switch with four attached APs uplinked into the Meraki environment. (Yes, I’m mixing cloud-managed solutions, and I have never felt so alive!) Anyhow, I saw maybe 27ish kbps of traffic that looked like it was probably Open Mesh admin traffic heading out, and it was happening every few minutes. I shared this with my  inquisitive Twitter pal, but I wanted confirmation from the top. I had to know with certainty, from the source. And I knew just how to get it.

I’d need to breach the Open Mesh corporate perimeter and make someone talk. 

Mind you, I was prepared to go all the way on this mission- if you know what I mean. I’ve run these ops before, and rarely do I come up empty-handed. In this case, I tried the oldest trick in the book; I asked my contact directly.

Evidently she knew the stakes and thought better of trying to wiggle out  of the situation.


Lee, 

Here’s what I got back regarding management traffic: access points check in every 5 minutes and send on average ~5KB of data
Let me know if you were looking for something else. 


BAM! Not only did I brazenly come away with the inside scoop thus showing my style and my energy, I corroborated my own findings-  proving that there’s essentially nothing I can’t do in this wretched, unforgiving world of pain.
Now, what I don’t know, and am big enough to admit: Is Meraki’s cloud management traffic load similar? Is Aerohive? Cucumber Tony? Other vendors? I don’t know, because to date, I have not really cared. My running assumption has been “it’s not enough traffic to care about” on any link. Maybe someone else can step up and put a finer point on it.
But let the record show- we now know, with certainty and style, what the overhead cloud-bound traffic for Open Mesh is.
And ain’t no one taking that away from us.