Tag Archives: Wi-Fi

A Wi-Fi Look at the GoPro MAX

That’s right, I said MAX. A hip guy like me isn’t going to have something called MIN junking up my life. I’m top shelf all the way. The GoPro MAX is a fascinating action camera that does what other GoPro cameras like the Hero 10, 9, 8, 7… all can do (which is a lot) PLUS lets you get freaky, like so:

You can do a heck of a lot more with a 360 camera- like Google street view kinda stuff. And… you can also control the camera via GoPro’s Quick app with a combination of Bluetooth and Wi-Fi (it’s also got GPS in there, and voice command capability. It just impresses the heck out of me, but each one of these works against the battery life.)

So… what does it actually DO for Wi-Fi?
Being a wireless professional, I can’t leave well enough alone and simply enjoy the magic. I gotta know what’s in play with the MAX and it’s Wi-Fi capabilities. Anything and everything you’d like to know is here, but stay with me and I’ll boil it down for you.

It’s dual-band- works in both 5 GHz (.11ac) and 2.4 (.11n). It appears to default to 5 GHz, and it uses a whopping 80 Mhz channel width. That’s right, I said 80… Don’t believe me? Well maybe this will change your doubting mind:

For giggles, here’s the 2.4 GHz side of the MAX doing it’s thing:

It’s always interesting to me to see how they craft the WLAN antennas in various tight squeeze products, and the MAX is definitely a tight squeeze product. The complete take-it-apart views are here, but this is the antenna view from that series:

What about about power? This little guy isn’t as skimpy in that department as I expected it to be, at least not in some frequency slices:

I see no way to manually manipulate channel, channel width, or power output settings. So far I love the control via Wi-Fi, but I can also see where if you get a number of these and other late-model GoPros also doing wireless ops together at an event, they certainly could impact the business/visitor WLAN in a noticeable way. Such is Wi-Fi life.

Now if you’ll excuse me, I need to make a bunch of goofy round pictures that only I find interesting…

Wanna Blog? Then Blog Already

This post was created for a ten-minute talk for the Wireless LAN Professionals Conference (2018). Want help getting started in blogging? Hopefully this blog lights a little fire for you, and I’m always happy to answer questions if you reach out.

Want to blog about Wi-Fi?

1. Take the first step. Writing, like public speaking, puts you “out there” for praise and criticism. If you’re gonna do it, do it.

2. Be yourself. Your words, your thoughts, your style. It’s OK to be inspired by others, but the world needs YOU, not you copying someone else. Write from YOUR experiences and discoveries.

3. Have something to say, but don’t force it. When the time is right to get your shareable thoughts out, you’ll feel it.

4. Put a fresh angle on the topic, whatever it is. Find something else to lead with that others aren’t discussing, some under-told feature or use case, etc. It’s OK to write about what others are writing about, but find some way to make it fresh, even if just subtly so.

5. Write often enough to stay relevant. If you last wrote back in 2015, chances are you’ve fallen off of most people’s radar. Every few weeks is OK, every few months is acceptable. Beyond that, don’t expect a lot of readers. Bonus- the more you write, the better you will get at writing.

6. Blogs aren’t novels- people have limited reading time. Don’t write more than you need to on a topic.

7. Promote, and be promoted. Get proofreading help early on if you need it; your blogging “advisor” will likely promote your blog.

8. Don’t be thin-skinned, and keep your ego in check. BTW- none of us know everything. And “experts” aren’t omnipotent- know the difference when interacting with people.

9. Any comments/feedback are worth responding to (almost). Stay respectful, and try to foster healthy dialogue. But it’s better to delete hyper-caustic comments than to reply with rancor.

10. Money can be made writing for the right outlet (or company) but generally it takes a while to build up to that- and you might have to know someone to get in the game. Unless you’re truly gifted, you won’t get rich with blogging. But you might develop a nice side income, and get other writing gigs.

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.

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.


Extreme Networks Makes the Case for 802.11ac Wave 2

With Wi-Fi technology constantly improving, it’s easy to stop paying attention to what incredible things are really happening for WLAN users. And incredible things are happening. With the arrival of 802.11ac’s Wave 2, we see new wheels put into motion for wireless users, and paths that the wireless industry had started down being turned into legitimate highways. 802.11ac Wave 2 is big news, and businesses are benefiting from its transformative nature, as over-viewed in a new eBook published by Extreme Networks.

As a wireless architect who builds WLAN environments of all sizes, I see first-hand how modern Wi-Fi enables new workflows and allows businesses to re-invent their processes as wired Ethernet gets pushed increasingly to the margins. Wireless connectivity has become the access method of choice for a huge swath of the business world, and Wave 2 is very persuasive to those who haven’t cut the cord yet. As highlighted by Extreme, it’s not just about signal coverage- or even speed- any more with enterprise Wi-Fi. Wave 2 also brings impressive capacity that further makes the case that businesses truly can run their operations over well-designed wireless networks, while enjoying the benefits of portability and mobility. With data rates topping 1.7 Gbps in ideal conditions, wireless traffic is forwarded with great efficiency in Wave 2 environments.

Extreme’s eBook makes the point that Wave 2 delivers a number of new or improved technologies, and these get even legacy client devices on and off the network quicker. Wi-Fi is still a shared medium, but that notion is getting blurred a bit with Wave 2, for everyone’s benefit. Multi-User MIMO (MU-MIMO) is rightfully getting its share of media coverage, as for the first time we have the capability for a single access point to service multiple clients simultaneously. Like with Wave 2’s impressive top-end for data rates, there are many factors that have to line up for MU-MIMO to live up to its capabilities at any given instant. But even though it may not be leveraged for every client and every transmitted frame given the variability of wireless, there’s no disputing the aggregate performance gains to be had by MU-MIMO. It really is exciting stuff, even to those of us who have seen it all when it comes to WI-Fi.

As businesses of all types consider whether Wave 2 is worth upgrading to, Extreme makes some good points. With more delivered network performance per AP, even for older non-802.11ac client devices, properly designed Wave 2 environments can significantly up the return on investment for the same spend as 11ac Wave 1 or 11n, if you negotiate your discounts right. If you’re sitting on an 11a/g or even early 11n network, making the jump to Wave 2 may be easy if your cabling plant and switches are up to date. Even if they’re not, it’s not uncommon to find that when planning for a new high-end wireless network, you can decrease your wired Ethernet expenditures as you make the jump. Everyone has their own OpEx/CapEx/TCO paradigm to define and muddle through, but Extreme gives pretty good food for thought in their eBook as you wrestle with your own situation.

Yes, Wave 2 has a business story to tell. Efficiency, performance, more-for-the-money, and so on- yes, those are all valid and noteworthy. But the Wave 2 story is also exciting at the user level. BYOD is an established fact of life, and in reality it’s more like Bring Your Own Many Devices for most of us. Our users have a slew of devices of various types and purpose, and 11ac Wave 2 helps with the overall Quality of Experience. Better cells are a tremendous asset to the end user, especially when those cells can self-leverage their best qualities for different device types.

Just remember that Wave 2 isn’t a design, or a deployment scenario. It’s a really awesome technology to be used to solve business problems and to facilitate business operations. As Extreme points out, Wave 2 is part of a bigger technology evolution story that features not just better Wi-Fi, but also switching developed just for 11ac, new analytics capabilities, improved security options, the Internet of Things, and (depending on your needs) impressive SDN and cloud tie-ins. Nothing under the network sun evolves in a vacuum, and Wave 2 fits very well with other advanced enterprise developments. Whether it makes sense for you to consider the move to Wave 2 is ultimately your call (and you’ll like get there at some point anyway). Extreme’s eBook on 802.11ac Wave 2 is an easy read, and does a pretty good job of telling the story of Wave 2 from a few different important angles.


FTC-required disclosure: I was compensated to review and comment on the 802.11ac Wave 2 eBook referenced in this blog, by PR company Racepoint Global. I have no direct business relationship with Extreme Networks, and in no way claim to be an Extreme Networks customer or representative of Extreme Networks. 

The Soon To Be Famous Cocktail Napkin Wi-Fi Big Picture

Get it while it’s hot… Print this baby out and put it on the break room fridge. Staple it to the helpdesk manager’s forehead so he sees it when he looks in the mirror, or have it printed out on a T-shirt that’s two sizes too small, so it accentuates your six-pack abs. What you’re looking at is the proceeds of a discussion I recently had, where I pontificated about how most “wireless” problems really aren’t wireless problems, even though ALL network problems “feel” wireless to the average user.

The Wi-Fi part of the story certainly can be temperamental on occasion, sure. But on a well-designed Wi-Fi network attached to a well-designed LAN, the overwhelming majority of user problems are going to be individual issues. When things do spin out– and multiple Wi-Fi users feel the pain– that’s when you want to turn to this masterpiece created on my enormous iPad Pro to remember just how complicated “Wireless” can be. (I missed “captive portal” as problem source…)


How Does Ekahau ESS Stay Current For APs and Antennas?

EkahauSo I’m sitting on a bench at the mall, and this guy plops down on the other end. I can hear him sobbing a little. I’m thinking “poor bastard, must be a death in the family, or his wife split…” But then I hear his kid about 10 feet away say to a pal “my dad is a complete loser- he doesn’t even know how the world’s best Wi-Fi survey and planning tool gets updated for new APs and antennas!”

Then it hit me like a ton of bricks: I really don’t know how it happens, either. I’m a loser too!

But there’s a big difference between me and Sobby Bench Guy. He’s not a gonzo bloggist with a license to ask the tough questions. That’s my turf, and that’s just what I did to get my mind right on the topic. I put on my Interrogator Fez and went gunning for everyone’s favorite European guy, Jussi Kiviniemi. Sure, he’s Ekahau’s VP of Wi-Fi Tools, but I don’t mind running in those circles now and then. I grilled Dr. J pretty good, and he gave me what I was looking for. Read on.

Q. How long does it take to get a new WLAN AP or antenna added to ESS, once Ekahau
has the technical information?
Jussi: Depending on load & urgency, it takes 1 day to 3 weeks to get it done. It’ll be published in next sw release (sw updates about every 2 months).

Q. Does Ekahau have a strategy for retiring old APs or antennas from the software
Jussi: Good question. Not really. Happens organically through Wi-Fi vendor acquisitions. We actually should probably take out the 802.11b stuff if we haven’t already 😉

Q.  How does Ekahau find out about new APs/antennas from the major vendors?
Jussi: It varies. Today, they often send the new or upcoming stuff proactively. That’s good for their business too. If not, we ask. Often customers ask us, then we ask the vendor. 

Q.  Why is it advantageous for vendors to get their stuff into ESS?
Jussi: A lot of their partners use our tool (we are tool of choice for Cisco, Aruba, Aerohive,…). And they often want to design using the actual stuff as it is more accurate. 

Q.  What’s the oddest antenna you’ve seen in ESS?
Jussi: At first, the Xirrus arrays were different. I wish we had the planner already back in the Vivato days, that would have been interesting. Also, the Ventev floor mount stuff is refreshing. 

Q.  Any other thoughts on the topic of adding products to ESS?
Jussi: I highly encourage the public and vendors to contact us to tell us which APs or antennas they are missing. It’s a free service to add them. Twitter, web site form or wifidesign@ekahau.com all work. 

We also add things like multi-SSID MAC combining as one radio, and multiple radios into one physical AP.  This requires specs from vendors too. 

And there you have it. Just a little behind-the-scenes information on how a great tool stays fresh. I’ll echo Jussi’s last point: if you see something missing, give Ekahau a shout to get the program updated. ESS is huge tool in the WLAN industry’s toolbox, so keeping it current is a win for everyone.

Additional Resources:


A Crazy-Assed Idea For Business Wi-Fi

Free your minds. Are they free? OK then… What I’m about to describe is a notion so profoundly bold and stupid that I know some of you reading will think that crazy bastard just might be onto something here. We’re talking Wi-Fi, in the business setting. Where big dollars flow for infrastructure components, and where there is a precision of approach and knowledge that goes into doing Wi-Fi “for real”.

Read that last sentence again.

<pause, for dramatic effect>

What if there was another way of doing enterprise-grade WLAN that didn’t put cables in hard to reach places using expensive pathways? That didn’t need that precision approach? No, I’m not talking about meshing wireless.. that’s old news.

What if we were able to leverage the wired computers that so many businesses have, by using wizardry like Connectify to provide wireless connectivity? Add a decent WLAN adapter to your typical GigEthernet-connected PC, use magic software, and BAMMY! You got a Wi-Fi hotspot! In a business, it’s BAMMY! x100, or 500, because there’s lots of computers!

<deep breath>

So that was fun to contemplate about for about 5 seconds, but then the WLAN professionals among us start thinking “bah, what an idiot. What about channels, and power, and proper AP placement, and fast secure roaming, and big areas where there are no PCs  that still need WLAN coverage?” And there are many other problems too with this idea.

But remember… we’re talking bold and stupid.  And that makes many things possible in conversation.

What if some whizz-kid developer took the Connectify paradigm and blew it out to infinite scale, and magically coordinated all those new PC-hotspots with orchestration sorcery that could manage the RF environment, and let these new soft APs actually be part of a hybrid architecture that included real access points for areas where there are no PCs?

Here’s where I admit two things:

  • This isn’t completely my idea. A pal named Andrew who happens to be an Active Directory God planted the seed when we were talking about Connectify as we both learned about it for the first time.
  • I just had a decent shot of Jameson’s.

In my mind, it all makes absolutely perfect sense as I picture people a lot smarter than me whipping up the code that makes my strange vision work.

Laugh if you choose… but as a technologist who likes to daydream I have to think that maybe something like this isn’t as silly as it might sound to the ears of Wi-Fi folks that have always done it “the old way”.

What do you think? Is this bold and stupid? Just stupid? Bold and maybe not so stupid? I’d love to hear your opinion, or your own crazy idea.

Update: One of the really smart guys out there in WLAN thought leadership has already been down this road! 

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

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

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

What SHOULD I be getting for throughput?

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

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

Example 1- Wired Connection on Robust LAN

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


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

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

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

Example 2- Wireless. A LOT More Complicated

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

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

Speed5          Speed6

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

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

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

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

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

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


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

Speed 9


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

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


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

  • MCS value
  • Channel width
  • Number of streams

(chart from WirelessLAN Professionals web site)

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

Let’s go back to this.

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

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

But wait- there’s more!

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

Use this methodology, please! 

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

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

A WLAN Doer Contemplates the Cisco/Apple Partnership

I’ve been in the wireless game with Cisco products since long before thin was in. These days, I support many thousands of access points and tens of thousands of Wi-Fi clients on those APs. At least half of those client devices are Apple products, and in some spaces in my environment, as many as 85% of all clients are Apple. Obviously, I hope for the best of outcomes from the new Cisco and Apple partnership, as my customers would benefit from those positive outcomes. There’s no meanness intended in what follows, just reflection on days past and what I hope comes of these two market leaders becoming more collaborative.

Code Counts as Much as Hardware

Cisco and Apple both put out beautiful hardware with premium price tags. Many purists who worship either or both companies have a hard time believing that anything defective could come in hardware that is so robustly built, pretty, and expensive. If my iDevice isn’t working, your network MUST be to blame. And if my WLAN is acting up, it must have been designed wrong because Cisco code isn’t cheap… and it comes from the market leader, by golly. Both Cisco and Apple are at the top of their games as measured by volume of devices in many large and small WLAN environments. And both frequently, too often, put out mediocre (or horrible) code that leaves people like me holding a bag full of smelly network pain.

In Cisco’s case, their WLAN controller code is just short of being chronically buggy, and a culture of “get it out the door and let our customers QA it!” seems to rule the product line. (Greg Ferro sums it up nicely in the opening paragraph of this article.) It’s not uncommon to spend days on the phone with TAC only to find out that randomly rebooting controllers or some oddball client behavior is actually a known bug.

For Apple, you never know what you’re going to get related to Wi-Fi behavior with OS and iOS upgrades and patches. Release notes are scant, and it seems that the Wi-Fi area of Apple devices is always being tinkered with back on the mothership. From a history of sticky-client behavior to curve-balls in how you are “allowed” to configure profiles to decidedly non-enterprise quality gimmicks like Bonjour, it has been an interesting ride administering business networks that have lots of Apple wireless clients on them. (This is not just me ranting, the Apple support forums are chock full of frustrations with Wi-Fi client behavior through the years.)

Features? What About Standards (and stability)?

Cisco networks also have to support a lot of non-Apple client devices. Making Apple’s consumer-centric AirPlay/Bonjour feature sets work in large business enterprises can be a nightmare. And though Cisco (and other vendors that do similar) mean well with mechanisms like band-steering and load balancing across APs, these enhancements cause their share of problems in the Wild West of widely varying client types found on big WLAN networks. It would be nice to see more focus on standards-based interoperability and feature sets rather than vendor-proprietary juju.

Looking Forward

I used to marvel a bit at Apple’s mastery of talking out of both sides of their corporate mouth when it came to their place under the network sun. Sometimes they were unequivocally not an Enterprise company, and sometimes they were. It seemed to depend on the audience, and how well their unyielding way of doing things fit into the general networking landscape where they were trying to gain specific market share. Now, with the Cisco alliance in play, Apple is emphatically stating that they are an Enterprise player. Hopefully, the company gives strong consideration to what that means to all of the users who love Apple gear but get frustrated because too much of the “Living Room, Single Class C Subnet Network” mentality is in play.

From the Cisco side, ideally my Wi-Fi vendor won’t skew their already frequently-frustrating code too far in the Apple direction at the expense of the rest of the client devices that have no use for Apple-specific features. Also ideally, Cisco would also find a way to end the code bug madness before it starts tweaking WLCs to do magic things for iDevices, lest bugs beget bugs.

This could be absolutely wonderful for environments like mine, or it could just be more of the same- but disappointingly amplified. I’m crossing fingers that both companies get it right…