Tag Archives: WLAN Troubleshooting

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.


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…)


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.

Download Free WLAN Troubleshooting Booklet

If you’re interested in the finer points of WLAN support and troubleshooting, have a look at this excellent freebie. It’s actually a slice from the current CWNA study guide, provided by the good folks at Aerohive, delivered as a swanky booklet for your use and enjoyment.

Put it on your e-reader and use the magic of technology to get ya an eyeful of excellent, easy readin’ content, baby!

Download a free booklet about WLAN Troubleshooting | HiveNation.


That is all.