Category Archives: WLAN

Why You Should Care About MetaGeek’s MetaCare

metageek logoTo the WLAN support community, there are just a few tools that are truly revered. Among these are the various offerings by MetaGeek. I still have my original Wi-Spy USB-based Wi-Fi spectrum analyzer dongle that I used a million years ago when 2.4 GHz was the only band in town, but have also added almost every other tool that MetaGeek offers. Go to any WLAN conference or watch the typical wireless professional at work, and you’ll see lots of MetaGeek products in play. So… is this blog a MetaGeek commercial? I guess you could say so to a certain degree. I decided to write it after my latest renewal of MetaCare to help other MetaGeek customers (and potential customers) understand what MetaCare is all about.

I queried MetaGeek technical trainer Joel Crane to make sure I had my story straight, as MetaCare is one of those things you refresh periodically so it’s easy to lose sight of the value proposition. Straight from Crane:

MetaCare is our way of funding the continued development and support of our products. It’s also a great pun (in my opinion), but people outside of the United States don’t get it. When you buy a new product, you basically get a “free” year of MetaCare. When MetaCare runs out, you can keep on using the software, you just can’t download versions that were released after your MetaCare expired.

On this point, I have let my own MetaCare lapse in the past, then lamented greatly when an update to Chanalyzer or Eye P.A. came available. You have to stay active with your MetaCare to get those updates! Which brings me to Crane’s next point.

When you renew MetaCare, it begins on the the date that MetaCare expired (not the current date). Basically, this keeps users from gaming the system by letting it lapse for a year, and then picking up another year and getting a year’s worth of updates (although I try to not point fingers like that, generally our customers are cool and don’t try to do that stuff). MetaCare keys are one-time use. They just tack more MetaCare onto your “base” key, which is always used to activate new machines.
Like any other decent WLAN support tool, you gotta pay to play when it comes to upgrades. At the same time, I do know of fellow WLAN support folks who have opted to not keep up their MetaCare, and therefor have opted out of updates. Maybe their budget dollars ran out, or perhaps they don’t feel that MetaGeek updates their tool code frequently enough to warrant the expenditure on MetaCare. As with other tools with similar support paradigms, whether you use to pay for ongoing support is up to you. But I give MetaGeek a lot of credit for not rendering their tools “expired” if you forego MetaCare.
Crane also pointed out one more aspect of the MetaGeek licensing model that is actually quite generous (other WLAN toolmakers could learn something here!):
 Speaking of base keys, they can be activated on up to 5 machines that belong to one user. Each user will need their own key, but if you have a desktop, laptop, survey laptop, a couple of VM’s… go nuts and activate your base key all over the place. 

And now you know. As for me, my MetaCare costs are a business expense that I don’t mind paying- and I’m really looking forward to new developments from MetaGeek.


But wait- there’s more! Thanks to Blake Krone for the reminder. MetaGeek has a nice license portal for viewing and managing your own license keys, so you don’t have to wonder where you stand for available device counts, license expiration, etc.

_______

Related:

The Idiot’s Guide to Ubiquiti UniFi

BTW- I’m the idiot, in this case. Something about Ubiquiti’s “UniFi” approach to networking can make me feel confused and inexperienced at times. But I’m determined to make peace with it, and to also maybe help save someone else the confusion. Ubiquiti’s product lines are interesting, feature rich, innovative, flexible, and cost-effective. And… also occasionally bewildering if you have yet to Ubiquitize your mind. To this point, let me (hopefully) make the indoctrination to UniFi a little easier.

UniFi is a Management Methodology AND Networked Components

Part of what confused me early on was the name- “UniFi” must surely just be a bunch of bridges and access points… As in, things that do Wi-FIIf you’re thinking that, you’re wrong. UniFi is more like UniFied in that a wide range of switches, access points, security gateways, video components, and more are branded with the UniFi moniker and managed as an ecosystem.  First major point: UniFi isn’t just wireless.

As for how the UniFi ecosystem is managed, that’s one of the main areas of getting to know Ubiquiti’s latest stuff that made me feel like a child (and not a very smart child, at that). I have set up and managed my share of other non-UniFi Ubiquiti bridges, where you get to the individual component’s UI and configure to you heart’s delight. But if it’s a UniFi AP, switch or gateway, life gets a little more involved. Forget the individual per-component UI, for UniFi you need to adopt each component into a “controller” and then manage a “site” worth of stuff (or multiple sites) via the controller.  Second major point: you don’t generally manage individual UniFi parts/pieces, you adopt each into a “controller” and then manage them all from the controller interface. I’m not a fan of the term “controller” here, but it is what it is. Think OpenMesh or Meraki dashboards and you’re on the right track.

Maybe Too Flexible?

This is where experienced UniFi users might tell me to go eat rocks, and I’m OK with that. But I have been utterly confounded trying to wrap my head around the various incarnations of the UniFi Controller. One way or another, you need to get to this point:
UniFi Controller

This inventory view of the Controller shows what devices I have, then from there it’s pretty robust in both configuration and monitoring capabilities.
UniFi Controller1

UniFi Controller2

Once you get your devices into the controller instance, life gets pretty pleasant. I give Ubiquiti a lot of credit for the completeness of the management interface and for putting together a framework that makes perfect sense- once you get there. Getting there, however, can be tricky. To me, Ubiquiti isn’t doing so hot on their messaging that the UniFi controller can take multiple forms and that you have to really know which form you want to use before your bring an environment to life.  I’ve spent a lot of time pouring through Ubiquiti’s web pages, and there seems to be more of an emphasis on dazzling potential customers with grand claims of cloud this and that and SDN blah blah blah than a realization that newcomers to Ubiquiti may need some basic buzzword-free guidance on this controller thing. The UniFi controller can exist in different forms, and you can only use one at a time with a given set of end devices:

  • On a laptop. You need to use the controller to manage devices, but the devices don’t NEED the controller to operate, so you might only invoke the controller when you have changes to make. But… here you don’t get the monitoring and statistics that you would with a more persistent controller method.
  • On a CloudKey.  Now this is cool. I wrote about my first use of CloudKey here, and you need to know that it’s just another way of managing the UniFi devices.
  • On your own virtual host. Load up a controller in AWS, manage a bunch of sites in your own private cloud- but know that you have to provision the devices to get them to your cloud-hosted controller with effort not required in pure cloud-managed systems like Meraki and OpenMesh.
  • Let Ubiquiti host it. Recently added to the UniFi offerings is the Elite Controller option. Here, you end up with something that’s kind of like Meraki but not nearly expensive. You pay a modest fee per device, and in exchange Ubiquiti provides cloud hosting of the controller for your devices, and phone and chat support. Unlike Meraki or Open Mesh, this is not plug and play. Your devices do not magically tunnel out to the cloud controller just because you’d like them to! You need to provision the devices, as Justin Paul writes about in his blog. If you don’t do the provision thing right, you’ll beat your head against the wall in frustration.

Third major point: there are several versions of “UniFi Controller”. You have to grasp the differences to decide how you’ll manage a given network, 

I’m currently kicking tires on UniFi hardware and the Elite Cloud option. I will have much to say on both as my evaluation continues, but I do hope that this quick primer can help anyone who is new to Ubiquiti’s UniFi environment.

Newsflash: All 5 GHz Clients Don’t Work on All 5 GHz Channels

OK- this really shouldn’t be a newsflash. But, if you’ve never had to deal with what I’m about to summarize, then it may well be a headline story. But first, a word from today’s musical guest- Genesis, fronted by the great Phil Collins:

Talk to me, you never talk to me.
Ooh, it seems that I can speak.
I can hear my voice shouting out.
But there’s no reply at all.

Look at me, you never look at me,
Ooh, I’ve been sitting, staring, seems so long.
But you’re looking through me
Like I wasn’t here at all.
No reply, there’s no reply at all.

Phil and the boys know well what happens when you assume that any 5 GHz client will work on any 5 GHz access point. Rumor has it that Genesis was troubleshooting a wireless installation at a mall in Duluth when they were inspired to write the super-hit “No Reply at All”, but that’s a story for another time.

I’m here to tell you of- and show you- an example of a 5 GHz client that just can’t (and therefore WON’T) talk to anything but a few 5 GHz channels. If it’s not obvious, there is high potential for the “the network sucks!”  factor here. If you don’t know what you’re doing, you can foolishly add more APs, tweak every setting there is to tweak, RMA one client device after another, and end up with an over-radiating nonfunctional heap of squadoosh, baby.

Trouble in Po Po Land

Once upon a time, there was an awesome dual-band Wi-Fi network that few could match. The APs were pretty, the signals were clean, and the installation crew was a bunch of snappy gents. Thousands upon thousands of client devices used this high-performing WLAN daily- every kind of laptop under the sun, all sorts of common mobile devices, and smartphones aplenty.

Then the police cars came.

The Long Arm of the Law wanted in on that Wi-Fi goodness. The idea was simple: police cars would pull into their very wireless well-covered parking area at the end of shift, and dashcam video would automatically download to network servers via that sweet, sweet Fi. A vendor was hired to equip the cars, the police technical staff got the lowdown from the network folks on how to configure the client devices, and everything seemed good.

Except it didn’t work.

About That Police Car Wireless Client Device

The cruisers in question are equipped with the Ubiquiti Bullet M5 radio. These have a handy form factor, and can be had for less than $100 (then obscenely marked up and resold as something special).  And look- they are 802.11a and 11n-capable!

M5-2

Should be no issues on that robust dual-band network, as long as signal is coming out of the 5 GHz radios in theAPs and the 5 GHz radio in the M5- yes? I can stand next to the police car with my iPhone and connect on 5 GHz, so the car should work too! But… the cars weren’t working at first, despite their 5 GHz output being verified with a number of tools.

Curse you, fickle Fi! What dark magic is afoot?

5 GHz is a Big Range of Channels. You Gotta Understand Those Channels.

So, this big world-class WLAN uses a lot of 5 GHz channels (36, 40, 44, 48, 52, 56, 60, 64, 149, 153, 157,  and 161). But take a look at that graphic again. The M5 operates in the range of 5170 to 5825 MHz, whatever that means. And did you catch the footnote?

DID YOU CATCH THE FOOTNOTE? (* Only 5725 – 5850 MHz is supported in the USA)

If you didn’t know any better, you might expect that the entire range of 802.11a and .11n is 5725-5850 MHz, and that all of the channels on the WLAN would fit in that range. This is American Wi-Fi, and that’s an American client device!

It just isn’t that simple. Looky here (5 GHz channels, Wikipedia):
5 chans

It turns out that the M5 only works in one small slice of the entire 5 GHz range that 802.11a/n/ac Wi-Fi can function in. So… those police cars were hitting lower frequency channels from the WLAN that they don’t support. A quick channel change for the parking lot APs to the few that the M5 does support, and the video was soon flowing from the cars as desired.

This Happens Often on Utility Devices- Be Aware!

I’ve seen this same scenario play out on ticket scanners in stadiums, retail scanners in warehouses, and wireless cameras that all operate in only a slice of 5 GHz. You absolutely MUST understand what radio capabilities are in play when it comes to non-mainstream devices.

These are the cases that often separate WLAN pros from those who don’t understand the important nuances that unfortunately pervade modern Wi-Fi. And that lack of understanding can lead to a lot of wasted time and money trying to fix a problem that is nothing more than poor configuration born of ignorance.

Just how complicated is the question of which individual devices can operate on what specific 5 GHz channels? Let’s ask a good guy named Mike Albano.

 

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.

Doing “The Paperwork” – the CWNE Application

cwne2Life is full of paperwork. As kids, we drag home endless school forms for everything from permission to ride a different bus to graduation paperwork. We fill out mortgage forms, military enlistments, juror forms, and marriage licenses. Life is paperwork, and we get pretty desensitized to the simple act of putting words on paper and handing them off to whoever is supposed to get them.

But some paperwork is sweeter than others. Some is exciting, thrilling, and makes you feel damn good when you do it. I was recently privileged to fill out some of that GOOD paperwork when I applied for my Certified Wireless Network Expert (CWNE) certification.

I won’t go into how I studied, or recommend what you should do to get to the point where you’re able to apply- many of my excellent CWNE fellows have already done that. But what I want to share is what getting this far means to me. I can tell you that crossing the finish line absolutely will have different significance to each of you individually. I’ve seen some who are very discreet about their top-level certificates, and others who find a great sense of identity in them. Here’s where I am, now that I’ve taken the journey…

I’m older than some in the CWNE demographic. My CWNE won’t get me a better job with my current employer (I’m a wireless network architect and next step up is my boss), and I’m not looking to find another job. I’ve been doing wireless for longer than many folks reading this have been working any job. So why did I go after the CWNE?

Many moons ago, I had CWNA and CWSP when both were new. I went off to school for both, got certified, and used what I learned. I used THE HELL out of what I learned. That knowledge has contributed to the unqualified success of the many WLANs I have designed, administered, and troubleshot. “Old” CWNA and CWSP, combined with my other network experience, work ethic, skills learned in college and a 10-year Air Force career, got me to where I am today in my networking and Wi-Fi careers. But I got busy with many other things, and let both CWNA and CWSP expire, because they couldn’t “get me anything”, or so I thought. But the more I went to conferences, watched new products roll out with new features, and see one 802.11 standard give way to the next, I realized that I needed to get back to basics because those basics had changed since I learned them.

I do know A LOT about wireless networking. And technology-related politics. And reading situations and adjusting to them when one solution isn’t right for given circumstances. I’m doing good in my career but realized that I could be doing better, with more confidence.  I’ve been around the wireless world and back, but the ground under me had changed through the years- and THAT’s why I went back to CWNP and worked towards CWNE.

I did learn, and reinforce much of what I already knew, by going through CWNA, CWSP, CWDP, and CWAP (in that order). I was humbled when I failed CWAP the first time- I don’t fail tests. Ever. But I did this time, and studied that much harder to pass it the second go round.

Then when it was time to apply for CWNE, reading over the application and writing the required essays gave me time and reason to reflect. Yes, I proved my “book smarts” on the certification exams. But spotlighting my experience through the essays and required non-CWNP certs gave me insight into myself: I have actually earned the title of Expert. A lot of people rely on me to wear that hat and to properly discharge the duties that come with being an Expert. I was reminded of that as I wrote up my experiences and realized just how much I have accomplished so far in wireless. The CWNE process has formalized that recognition for me.

And it feels pretty  damn good.

Now here’s the rest of the story for those keeping score at home. Being an Expert is different from being a Know It All. Any one of us in the CWNE community can likely bubble up a topic or two they feel weak in, and have no shame in admitting to such. The day I have nothing left to learn will actually be depressing, because every day I pick up some new tidbit of wireless knowledge and look forward to that.

And now that I’m a CWNE, I have continuing education requirements for keeping the title that I’m rapidly coming to enjoy. CWNP recognizes that the WLAN world changes, so CE will help those of us with ANY level cert to stay fresh with what we know. And when I turn in my first CE paperwork, that will feel good in it’s own way, too.

 

 

Of Malfunctioning Boats and Wi-Fi Support

boats_230_odyssey_20742179I have an old power boat, and it has recently taught me a life lesson that very much applies to Wi-Fi support. Every boat should have a name, and this vessel is the Sweet Baboo. She’s a 22-foot Cuddy Cruiser, built in 1985. It’s powered by a 5.7L OMC motor (basically a Chevy 350). This is my first “real” boat, and it has humbled me… A boat like this is really just another vehicle to keep up, but it has mystique and mystery to the new boat owner and the passengers that ride on it, just like Wi-Fi often has mystique and mystery to many networkers and clients.

Just a bit more background, if you’ll indulge me. I consider myself a pretty good shade-tree mechanic, and I do everything I can on my vehicles when it comes to maintenance. I like to save money, and know HOW a job was done, in exchange for my time and skinned knuckles. But I do know my limits, and know when it’s time to get professional help.

Stay with me- I promise the Wi-Fi angle comes into play soon.

Something about being a new boat owner made me kind of silly. Every oddball problem this old boat has had seemed exotic somehow, until very recently. After all, every part on the thing is a “marine” component. It has a marine carburetor, a marine ignition system, a marine gearshift, etc. Which for a while made me think that somehow they were all forged by unicorns in Magic Marine Parts Land, and for whatever reason I’d get stupid when it came time to troubleshoot. I’ve seen Wi-Fi have the same effect on network troubleshooters… somehow everything they know about basic network troubleshooting goes out the window because Wi-Fi is also exotic and different.

Finally, working through one lingering, long-term headache I was able to get my boat mind right, and to draw parallels with Wi-Fi support.

I got through that problem, but I did some really knuckle-headed things along the way. I threw away money and time because my troubleshooting methods were not sound. I looked past “the basics”, and often got sparkly-eyed that my problem had to be some exotic marine thing, just like many people get sparkly-eyed and start dicking with controller settings, adding APs, and taking other fruitless steps to solve exotic Wi-Fi problems that often end up being not so exotic.

The boat problem? Well, Sweet Baboo would start nice, idle great, and run really well at low speed. Give her some gas to speed up this big beast, and the motor would stall or fall back to idle speed at 2,500 RPM every time. Put another way, I had crappy performance.

I went through the troubleshooting steps in the repair manual fairly diligently, but also (in retrospect) bit on many red herrings, hoping for an easy fix. But… even easy fixes can hide behind complex symptoms and pre-conceived notions. I fixated on “it’s GOTTA be this!” at least a half-dozen times after reading online user forums. In those user forums, I latched on to the sage advice of frequent-posters that seemed to be revered by the other folks in the forum. And it turns out they were wrong every time. Or rather, I wrongly applied their analysis to my situation because they seemed to know their stuff.

All the while, because this boat is an exotic marine craft, my brain refused to acknowledge that when I let myself apply sound troubleshooting techniques I have fixed a wide range of cars, computers, F-4 and A-10 aircraft, broken furniture, swimming pool pumps, blenders, and more over the course of my life. I wasn’t letting myself simply proceed as I would normally in the course of troubleshooting anything, because I had never worked on a real boat before. I made it into something it wasn’t, in my mind. I KNOW this happens in Wi-Fi support often.

I ended up needlessly replacing (or tearing into):

  • Every ignition component (some two or three times)
  • Fuel pump
  •  Carburetor
  • Shift cable
  • Electronic shift module
  • Throttle cable
  • Exhaust flapper valves
  • Fuel lines

I’m sure there were other things that I hosed up along the way, too. I broke things trying to fix things- but then again, I was dealing with an exotic marine situation so my buffoonery was OK, right? Well, no- it’s not OK. I’m somewhat embarrassed of my conduct, and I can’t describe the frustration I felt over two seasons of fighting this problem. But again, I have seen people approach wireless support in this same scattered, desperate way.

Anything and everything feels like a WIRELESS problem when you have a problem and happen to be using Wi-Fi. Those not trained or acclimated to the Layer 1 and Layer 2 implications of Wi-Fi can do really dumb, desperate, nonsensical things that they would NEVER do on wired networks. For some reason, we all have things that make us forget what we should know when we most need it. For me, it was this boat. For other folks, it’s troubleshooting Wi-Fi.

After replacing component after component, fiddling with this and adjusting that, I was SURE I had a bad carburetor. There was simply nothing else it could be. So I ordered a pricey replacement… and it changed nothing. Floundering around out in the middle of the lake after putting the new carb on the engine, I was livid. At me, at the boat, at the Boat Gods, and pretty much everyone and everything. I called my wife, and admitted defeat. I told her that we’d have to tow the pig off to a marine mechanic, and take our chances that we could find one that was reputable. But as I was limping the Baboo back to the dock, I had an epiphany. Two thoughts collided in my brain at the same time, and they would lead me to resolution.

I was filthy from repairs, hot from the sun, and pissed-off low-down feeling. I had dozens of hours, and at least a thousand mostly wasted dollars on this escapade. At my lowest, one part of my brain told me “Come on… you’re better than this.” And another asked “listen you schmuck, how would you approach a seemingly complicated wireless problem?” It might sound cheesy, but I was recharged. I pulled up at my dock with a plan. I WAS GOING BACK TO BASICS. This damn boat was the client, and I had a client problem. And it was a similar problem to hundreds of other boats/clients that I had read about online. The solutions were usually proven to be simple, and I empowered myself at that moment to start over, with simple in mind.

Early on in the troubleshooting process, I had pulled the fuel pick-up tube from the gas tank (a 60-gallon monster built into the floor of the boat). I had EXPECTED to find a filter screen at the bottom, but didn’t. Not knowing better, I assumed at that early point that there was no such filter on THIS boat. I was wrong- and simply looking closer at that pick-up tube a second time revealed that the filter was INSIDE the tube where you can’t see it. And it was gummed up with crud pretty good. It was letting enough gas into the system to allow for starting and low-speed operations, but was blocking the increased fuel needed at higher speeds. I had “looked” right at the problem before skipping over it because it didn’t match my assumptions, and at that fateful moment I also turned a simple fix (blow it out with compressed air and carb cleaner) into a two-season exercise in grasping at straws.

I’m not sure what specific analogy to make here to wireless troubleshooting, but I do know that THE ESSENCE of my boat problem and what happens when the unskilled or “blame the WLAN” types get involved with wireless performance problems are the same. Sometimes Wi-Fi doesn’t work because non-Wi-Fi components have faults, but if you lock on to blaming the APs or controller early on, you’ll often never find the issue. Assumptions, poor methodology, and not looking at the basics thoroughly and with an open mind can lead you down rabbit holes. It’s not fun when you do it to yourself, and I really should have known better after decades of honing my troubleshooting approaches.

Just like my boat really is not “exotic and mysterious”, neither is Wi-Fi. But to support either, you have to have the right mindset and not be afraid to just use good sense and thorough checks of the basics as you proceed.

But as I’ve just shown here, that is easier said than done- even for the best of us.