Tag Archives: Bad wireless code

The Horrible Bags We Hold For WLAN Vendors

Conventional wisdom says that “you get what you pay for” and “buy the best that you can afford” when it comes to quality in networking gear. Yeah… if only. Let me share what one of the most expensive solutions on the market gets you if you’re not careful. No vendor names will be named.

The call comes in. “Suddenly in this one area, I can see the Wi-Fi signal but just can’t get on the network. If I walk down the hallway the same device gets right on.” You look and see that the AP serving the area in question has the same uptime as those around it. The radios are on, and there are clients seemingly associated. Channel utilization is low on both radios, and there is no sign of RF trouble. Hmmm.

So you methodically rule everything out, and the end user who trusts that you keep a tight wireless ship waits. You’re both going on the assumption that the WLAN building blocks that you shell out fat coin for should be an operational foundation that you can trust. But when you’ve factored out all of the realistic possibilities, that little voice in your head starts questioning how solid that foundation is.

Too often, the one thing that we have very little control over (code) is the issue, and we find that suddenly there is a very ugly bag in our collective hand.

Welcome to the bug zone, Axl Rose.

Welcome to the bug zone we got fun and games
We got everything you don’t want- honey, you’ll call us names
We are the people that can’t find code you actually need
If you got the money honey we got your disease
In the bug zone, welcome to the bug zone
Watch it bring your Wi-Fi to it’s sha na na na na knees knees
I wanna watch your network bleed

(Sorry, Guns ‘n Roses- love you guys)

Maybe you open a support case, or take your angst to private channels where you share information with other wireless professionals who live the same pain are happy to compare notes. However you get there, you do get there… and then you find this sort of thing:

Yikes. Freaking yikes. The fix? (Always) migrate to new code.

That word “migrate” is kinda funny, too. Sounds adventurous… leave where you are, and go to someplace new.  Kind of exotic, even.

But there are no guarantees that Someplace New is any better than Where You Were, especially when it comes to expensive WLAN systems. Yet we find ourselves migratin’ all over the freakin place, outrunning one bug after another. Sigh…

Which brings us to yet another song, by the great Moe Bandy:

You always leave me holding the bag
Don’t you know it’s gettin’ purty heavy to drag
You think it’s funny but it ain’t no gag
How come you always leave me holding the bag

Indeed.

The Memo

How many times have you done something that you shouldn’t have, out of ignorance? Have you ever went down an erroneous path because you missed some key bit of information that would have taken you in another direction? Was there ever a case where you “didn’t get the memo”?

I’m guessing a fair number of vendors and device makers in the last few years haven’t “gotten the memo” either. As a public service. I hereby present The Memo, for all of those companies doing business in the mobility space who missed it.

The Memo

We’re in the year 2014. Now that we’re moving to the age of 802.11ac, it should be noted that we’re into the fifth generation of wireless access technology as we collectively know it. WLANs are set up for client device access, and thousands upon thousands of users rely on those WLANs. If basic access doesn’t work, all of the fancy features you’ve bolted on to the wireless network are worthless.

1. This being said, the days of tolerating poorly written and tested code are over. We should all be better at this by now. Whether it’s drivers on Lenovo Ideabooks, the keychain code in Mac OSX, wireless controller code, or whatever– when it’s shitty, people suffer. Real people. Thousands and thousands of people, and the admins that support them. Developers need to partner with those of us who have our toes in reality and understand that “little mistakes” and “misjudgments” create havoc for those who are stuck with them.

So, let’s be done with catastrophic code failures, and actually start testing our code for real, okay? Like before  it goes out the door as opposed to relying on end users to find our bugs for us (usually in very unpleasant ways).

2. When a bug is found, we have the opportunity to be perceived as caring, responsible technical professionals– or complete buffoons. For large, secure, high performance expensive WLAN environments used by thousands of customers, these “recommended workarounds” do not make the author look like a caring, responsible technical professional:

  • Disable WMM
  • Don’t use enterprise security
  • Don’t use 5 GHz
  • Don’t do things that you know you have to do in a real network environment

Make this sort of recommendation to paying customers in 2014 where wireless networking is a critical service to most users, and you are casting yourself as an out-of-touch, insensitive individual who probably isn’t in the right career field. Worse, your employer sends strong signals of cluelessness. The message counts.

3. There is no line between consumer and enterprise devices anymore, at least not in the minds of end users. If you’re going to sell wireless printers and projectors, make sure they work on typical enterprise secure wireless networks. Ad hoc technologies should be killed. Any video mirroring device, TV-style streamer, wearable technology, or resident of the Internet of Things WILL find it’s way into the Enterprise, and you know it. So make them flexible enough to actually work on secure wireless networks that exceed a single Class C in size. There are only so many variants of secure wireless. Google it- and figure out how to make your products work on business Wi-Fi networks. Then go back to #1 above and make sure you test.

4.  Networks are sophisticated enough, don’t add to the administrative burden with ill-thought out management services, complex and/or frequently changing licensing paradigms, or other detractors that keep WLAN administrators away from the business of administering WLANs, Because… this is 2014 and thousands and thousands of client devices use the network and our focus should be on them and not the constant baby-sitting of ill-designed servers that violate bullet point #1 above.

5. Above all, it’s about devices being able to reliably connect on standards-based networks. Without good drivers, good code, and good protocols that were written and tested for 2014’s large critical wireless networks, the rest is bullshit. All the slick features and applications are moot if people can’t connect and stay connected. Wireless connectivity on enterprise-grade networks should be the one thing that all parties prioritize, and treat as Purpose #1.

There- now we all “got the memo.”

I realize there’s an element of preaching to the choir for those reading this blog- but for corn’s sake, we seem to have settled into a groove where we tolerate and accept failure and poor performance by vendors “because it’s wireless”, and because “wireless is complicated”. Again, bullshit I say. Do it right, or don’t do it.