Are Wi-Fi Networks in General THAT Bad?

Let me start by apologizing for a long absence here. It would seem it was my turn for life for a while. People and animals I love got sick and passed on, and those inevitable changes to each of our existences came knocking on my own door. I also had some demons that poke me at night sometimes to exercise.

But a couple of recent vendor and VAR interactions brought me back here.

Really? You Don’t NEED us?
I’ve been operating in the collective big overall networking universe for at least a quarter of a century now, so I get the rhythm of the music. Everyone has a part, and I begrudge few individuals for playing theirs (except maybe the vendor exec that has the gall to try to explain how sucking my bank account dry with complicated licensing schemes suddenly equals value or perhaps innovation). Still I’m occasionally surprised when I’m presented with some new solution, dashboard, or service that I was doing fine without yesterday and today, but if I don’t get on board my tomorrow will certainly be disappointing for my end users.

THEM: We have it to offer, so you MUST need it. It solves all kinds of problems.
ME: I’m not sure what we’re doing differently, but we don’t seem to have the problems you mention.
THEM: Bah. Everyone has those problems. Lots of them. In mass quantities. The freakin’ sky is falling!
ME: I’m gonna get some coffee now. Good talk, thanks.
THEM: You are pretty lucky then. Everyone else has problems that they need our stuff to find.

I’m guessing I’m not the only one who has been part of that kind of conversation.

Let’s unpack that a bit.
I always find the messaging that “lots of networks are just fraught with endless problems that you need help with” to be a little confounding. Why? I ask myself that, and I think I can answer it- beyond the “I’ve been doing this a while and have arguably seen it all” effect. I offer these:

– We are on what generation of Wi-Fi now? Sixth? Sixth extra special? Shouldn’t the general kinks be worked out by now? With the Wi-Fi Alliance chest-thumping about all their certification programs and the IEEE putting out wireless “standards”, everything should generally just click, no?

No. I’m being sarcastic of course. This many DECADES after the original 802.11 miracle, we’re still dealing with driver issues. And that fuzzy, ill-defined gap between enterprise and consumer end devices, and the denial by groups like the Wi-Fi Alliance that this is a serious problem. After all, there is middleware kinda solutions that make it all right, no? Again, no. Not without paying through the nose in upfront and ongoing costs. Pffft.

So what is the expensive new dashboard, or managed services, exactly delivering? Is it telling me I got driver issues on a given client? Newsflash- I can tell that without the dashboard when a client stops working right after an OS update.

–Shouldn’t proper WLAN design mitigate a lot of what the magic dashboard is supposedly figuring out? Price out Ekahau or iBwave (both fantastic tools) and the training and ongoing licensing for both. They are not inexpensive. Yet, somehow, you can design your networks perfectly using high end tools, and STILL need “help” with all the inevitable Wi-Fi issues you are going to have. Smells funny…

–Speaking of expensive… Have you looked at the pricing on the latest access points? We have reached INSANITY in this area, when indoor Wi-Fi access points list prices EACH top $3K. For an access point. Without the mandatory licensing that The Industry now gets fat on. And for that lofty expenditure, you still need all the professional services and pricey dashboards because that increased pricing solves… nothing? Same problems are still with us, evidently.

You suck, Lee. You’re a real freakin’ downer, man. Perhaps. A lot of gloomy shit has been happening for me lately, but that aside- something is wrong here. Either I’m doing networking wrong, because I don’t have all the problems that I’m supposed to, OR those problems are the bogey man maybe created by The Industry to have more to sell us. We just can’t collectively be this far down the Wi-Fi timeline and be that bad off, can we? If we are, then everyone from the IEEE to the Alliance to vendors have screwed up. And if we AREN’T that bad off, then we’re being bilked for solutions that we really shouldn’t need.

Is there a point here? Whether I’m articulating it clearly or not, something isn’t quite right in Denmark, or in Silly Valley. Or is it just me?

Wyebot Brings Wi-Fi 6, More to Its WLAN Monitoring Platform

I’ve been using and evaluating Wyebot in different wireless environments for the last 18 months or so. One of the things that I most like about the company behind the sensor product and their Wireless Intelligence Platform (WIP) is their willingness to listen to what tech-savvy customers want, versus just adopting the mindset of “we’ll tell YOU what you need in a dashboard” that comes with competing products. My own requests have helped to shape the product, and I’ve listened in on calls where other wireless processionals have described what they feel is important. Wyebot listens, and iterates where it makes sense while not necessarily duplicating what everyone else is doing, or diluting their core strengths by trying to be all things to all people. This strikes me as a small, smart, agile company with a good product (and some good competition). My past coverage:

• In IT Toolbox, April 2019
• Right here at Wirednot (2.2 software release)

Now, we have a new 802.11ax sensor and version 3.1 code to improve Wyebot’s already impressive capabilities of WLAN/LAN characterization, troubleshooting, and alerting.

Continuous Improvement

Here’s the latest incarnation of the main page in the Wyebot dashboard, to get the juices flowing:

Whether you install Wyebot sensors for long-term monitoring, or use them more in a tactical role for point-in-time troubleshooting, there is a lot to appreciate. I love that with three radios, you get the flexibility of using wireless backhaul from the sensor when no network wiring is available. But what about the new magic in 3.1?

Unfortunately, you have to be logged in to see the details of each feature, but most of these are probably fairly intuitive to those in the business of Wi-Fi. Let’s talk about a couple.

Access Point Classification Feature

The Wyebot sensor does a fantastic job of characterizing a given WLAN environment. You may see a list of SSIDs on your phone or PC, but Wyebot will distill it all down to how many APs are in each SSID (within it’s receive range, of course) along with all of the 802.11-related particulars you’d ever need to know. From there, you can add your own classification- is it a friendly? A threat? an unknown? Sounds simple, perhaps, but this on-the-fly graphical note-taking with security overtones helps keep busy environments straight as you pick them apart.

Available Test Profiles

At the bottom of the list of test profiles, we see a new option- Link Doctor. With this, you exercise core network services and device-to-destination connectivity to get a sense of network health. Run it on demand, or at regular intervals for trending.

Hopefully you get a taste for Wyebot’s look, feel, and general aspirations as a test and monitoring platform. For a more analytical look at the entire platform, check out this presentation from Bryan Daugherty.

What Do I Like Best?

From the first time I experienced Wyebot, I fell in love with a few aspects of the sensor and it’s cloud framework, That affinity continues, and here’s what keeps me smitten:

• As a permanently-mounted sensor, Wyebot would be welcome in any WLAN environment. But to me it has as much value as a pop-it-in short-term analysis tool, almost like a NetAlly hand-held product. Even if you don’t buy into sensor overlays, a Wyebot sensor two on hand could bring unique troubleshooting value.
• You just don’t get as many false alarms with Wyebot as you do with certain competitors.
• It’s awesome to take wireless packet captures gathered elsewhere and to load them into Wyebot, and have them displayed as if Wyebot did the capture. Pretty slick.

Of Malfunctioning Boats and Wi-Fi Support

I 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.

 

Three Inconvenient Truths and Some Conspiracy Theory About the FCC’s Mi-Fi Enforcements

The recent enforcement actions by the FCC against hotels that disrupted private Mi-Fi usage are interesting for a number of reasons. If you’re a Mi-Fi user that travels and you don’t really understand or care about the inner workings of business wireless networks, you likely did some variation of a fist-pump because evil companies must now seemingly mend their dastardly ways. (This blog may challenge the validity of that assumption, so click out of here now if you don’t want your bubble burst.) If you are a long-time wireless admin of business Wi-Fi networks, you are likely scratching your head a bit over several of the finer points of what the FCC is up to these days in going after companies like Marriott and MC Dean. I would guess that some Wi-Fi admins are feeling a bit uncomfortable but can’t quite put their fingers on why that is, but what the FCC’s doing all of the sudden just feels weird. And for those of you that are trying to keep an open mind about what it all really means as all sides of the debate try to be heard, I give you the following to ponder:

1. “Our Premises, Our Airspace to Keep Healthy” Since Late ’90s

The 802.11 Wi-Fi standard dates back to the late 90s. For over 15 years, wireless network administrators, security managers, and CTO/CEOs have been writing and enforcing policy about signals that compete with their WLAN systems and the use of “rogue” access points not put in by “Central IT”. Many of these policies pre-date Mi-Fi’s existance, but often address off-my-wire ad hoc (peer to peer, my laptop to yours) direct connect rogues that both interfere and bring their own security concerns. This is an entrenched technical cultural issue. Though Mi-Fi doesn’t meet the textbook definition of IBSS ad hoc networking, it does share the properties of being a competing Wi-Fi signal and it’s own security risk in that if you know what you are doing, you can bridge “isolated” networks to each other pretty easily. Rogue ad hoc is just as important to rogue on-wire by most WLAN policies I’ve reviewed- for both RF interference and security concerns.

All of these (and plenty more) are scraped from easily-found published private network policies on the Internet:

If there are cordless phones, ad hoc or peer-to-peer WAP’s in the prohibited frequency, [we} will attempt to notify the user in writing and ask them to remove the device.  If the device is not removed within 24 hours, [we] will take necessary actions to stop the interference of the device.

This policy covers any devices and users to adhere to the rules, regulations and policies concerning security and prevention of interference.

Due to possible interference from other sources within the 802.11 wireless 2.4GHz frequency range, [our] wireless spectrum should be kept clear of unauthorised transmissions.

Interference means the degradation of a wireless communication signal caused by electromagnetic radiation from another source. Interference can slow down or eliminate a wireless transmission depending on the strength of the interfering signal.

Interference or disruption of other authorized communications that result from the intentional or incidental misuse or misapplication of wireless network radio frequency spectrum is prohibited.

In the event that a wireless device interferes with other equipment, [we] shall resolve the interference as determined by use priority.

So, those of us administering wireless networks tend to recognize that solutions enforce policy, and the policies that guide WLAN security and interference management are nothing new. They are so ingrained in the Wi-Fi psyche from the system side that WLAN vendors and companies that train new WLAN staff are all on board with the philosophy that you can do what you need to to keep your own airspace clean and healthy for the greater good of your users, and to enforce YOUR OWN policies. And… this culture has been in place under the FCC’s own nose for all these years. Mi-FI devices are easy to lump into the spirit of long-established Wi-FI policies, with no malicious intent in doing so.

2. Non-Accommodation Equals Disruption, Too- To Users.

In convention centers where big events are going on, the Wi-Fi network will be made up of dozens (if not hundreds) of extremely low-powered WLAN cells. These cells only have limited channels to use, so staggering channels meticulously and controlling cell size is pivotal to network operation (and event success, in many cases). Along comes a Mi-Fi, with it’s often bad-neighbor config that blasts out a strength that may be an order of magnitude stronger than the conference Wi-Fi cells. As the Mi-Fi disrupts multiple cells (that other conference goers are trying to use), those same cells are also interfering with the Mi-Fi device. In these scenarios, there are typically no “free channels” so mutual interference is a fact of life.

So… I go to use my Mi-Fi at a convention center during an event, and lo and behold, it doesn’t work well. All I know from the headlines is that the FCC says it’s OK for me to do what I’m trying to do, so if it’s not working well, the stinking hotel must be trying to block me! I better report them to the FCC! It’s an outrage!  Except it’s not- it’s physics at work. So what comes next- convention centers needing to ask Mi-Fi users permission to use specific channels?

3.  The FCC Is Closing Many Field Offices, Which May Impact It’s Ability to Enforce. 

The agency is calling it an efficiency move, but what impact the cuts will have on the agency’s ability to enforce it’s own rules remains to be seen.

Let’s Play the “What If” Game A Bit

I, and others have voiced a fair amount of concern about not only what the FCC is doing with it’s new tactic of huge fines, but why it’s being done with very little substantive guidance. Even two of the five commissioners at the FCC don’t seem to agree, or to get what the agency is supposed to be accomplishing with their new fundraising campaign. With lack of leadership from the FCC, the WLAN community is left to speculate about what they could be thinking in DC. Here are a couple of theories to ponder:

• What if the FCC really is clueless about how important Wi-FI has become to businesses of all types? What if, while we as IT organizations have been doing our best to write and enforce good WLAN policy, and have bought WLAN tools that help us to enforce those policies for the greatest number of people on our premises that rely on Wi-Fi, the FCC in it’s ivory tower was oblivious to it all for the last 15 years? What if an out-of-touch FCC is thinking one thing, while the rest of the WLAN community is basically thinking something else?  It might explain the rush to crank out big fines for what amounts to the same policy that private WLAN environments have been enforcing for the last 15 years. Because the hotels were charging big fees, they have cast the whole thing in a stinky light (and deserve to be called out on it), but the issues for the rest of us are made murky because of the FCC’s Mi-Fi related hits on the hotels and convention centers. It would seem that we all need help (that the FCC has no interest in providing) in:
  • Re-writing our business policies to accommodate Mi-Fi while still preserving our own business continuity
  • Understanding whether the hotels were only in trouble because they were trying to charge (what everyone seems to agree was too much) for their own Wi-Fi (it sure reads that way at times)
  • Or coming to grips with- if it’s what the FCC is saying- Mi-Fi must be accommodated everywhere under all circumstances regardless of collateral damage from it’s interference
• What if the FCC is just using these headline-grabbing fat fines to sew paranoia as a way to augment their enforcement capabilities as they reduce field offices and employee head-count? Uncertainty and paranoia can certainly be force-multipliers when you have the ability to name your price when handing out fines, and the bigger the fine the harder the impact of the tactic. The new-found interest in taking issue with practices that many companies have had written into their IT policies since Wireless Day 1 times out nicely with the cutting back of FCC field offices. It’s just a thought…

My personal sympathies are absolutely with those users who didn’t want to pay what the convention centers were asking for Wi-Fi. But there is so much more to the whole picture than that, and it needs to be talked about.

My related articles on this:

• At Network Computing
• At IT Toolbox
• An Open Letter to the FCC

Code Suck Regulation: Should We Fine Vendors For Major Code Bugs?

Tell me if this sounds familiar- you spend top dollar on brand-name networking gear, only to put in into service to have some major future bork out and cause your organization significant embarrassment. You’ve researched the product, have been cajoled into buying from a vendor that swears you’re getting a great piece of gear, and yet something catastrophic makes your deployment go sideways. You engage tech support, verify that your topology and configurations are OK, yet the suck storm still pummels the networked landscape. You’ve found yourself in The Bug Zone.

Ever been here? It gives a bloke or blokette a powerful lonely feelin’. With users in pain, managers who may or may not be sympathetic, and the little voice in the back of your head asking “what could I have done differently?” that ultimately answers itself with “maybe I shoulda cut this vendor off after the last dozen major code issues. But like a victim of domestic abuse, I keep going back for more, hoping it’ll get better.” 

Does this ring familiar with anyone?

I’ve heard from a lot of individuals in the greater IT community of late about all of the many bugs they have hit, and 75% of the time the lament is accompanied by something like “the rush to get ever more features under the hood is making the whole damn thing a time bomb of suck, and it feels like QA is being short-cutted in the name of getting it to market faster”.

What if, in our support contracts, we added a section that gave us a weapon against major code bugs? Perhaps we need to become our own CSRs (Code Suck Regulators) and have it in our agreements that any major code bug that is verified to cause network downtime or significant user impact when a half-baked feature sends the network into a tailspin results in a fine of $1,000 a day until the bug is resolved by the vendor?  Would code development maybe slow down a bit and QA labs be better funded, staffed, and used? Would major bugs drag out for weeks and months if the meter was running at each affected customer site? I’d also suggest making vendors keep all of their verified major bugs in plain view of the world on a vendor-neutral website that requires no login to see bug details and impact, with posting a mandatory requirement enforced by somebody or other- or again, fines are levied.

OK- I get that the networking industry and all of it’s various niches doesn’t, and won’t, ever work this way. At the same time, it’s mildly fun to think about not being victimized anymore by companies that don’t feel like they really care about their code quality after you’ve used their stuff long enough to see definite trends in significant bugs. And I am talking about SIGNIFICANT bugs- the ones that are devastating to network performance, and your organizational and personal reputations, and not just horrible misspellings or cryptic broken-English error messages on a webpage.  Maybe fines aren’t the answer, but if you’ve got a better idea on how to change trend of Free-Flowing Suck when it comes to code, I’d love to hear it.

(This is where some of you are thinking- bah, just do better testing before you deploy the code that you say sucks. My reaction: yeah, good luck with that. There’s only so much you can test, and only so far you should have to go to be the vendor’s QA department.).

An Open Letter to the FCC

Dear Chairman Wheeler and Commissioners,

In response to the recent Commission actions relating to Smart City  and Marriott blocking of Wi-Fi hotspots, as a WLAN professional I implore you to recognize that these actions are creating significant amounts of confusion for enterprise Wi-Fi environments and those of us who keep them operational for the millions of business clients that use them every day.

The running theme of late very much seems to be “you can’t use Wi-Fi mitigation techniques to deny individuals the use of their paid-for cellular-equipped personal hotspots” (my own words). But from here, the questions start.

DA 15-113 Enforcement Advisory states clearly “Willful or malicious interference with Wi-Fi hot spots is illegal.” That seems pretty cut and dry, until later in the document we read “No hotel, convention center, or other commercial establishment or the network operator providing services at such establishments may intentionally block or disrupt personal Wi-Fi hot spots on such premises, including as part of an effort to force consumers to purchase access to the property owner’s Wi-Fi network. Such action is illegal and violations could lead to the assessment of substantial monetary penalties.”

Given that most of us doing Wi-Fi are not lawyers and very much want to stay within legal boundaries, these questions hang over the WLAN space:

1. What constitutes an “other commercial establishment”? Would these be hospitals? Universities? Does it even really matter? If not, why call out just hotels and conference centers?
2. There is emphasis on Wi-Fi blocking being frowned upon especially when it is used to try to force those using hotspots onto an expensive WLAN service. What if blocking ISN’T used to try to push hotspot users onto a pay Wi-Fi service, but to try to eliminate a hotspot that’s significantly interfering with an organization’s private Wi-Fi and business operations- especially if a free Wi-Fi option is available to the hotspot users?
3. Are hotspot users free to bring their devices anywhere and everywhere regardless of the interference caused by those hotspots?
4. In  DA 15-113, and other FCC documents (including those related to Mariott), blocking of Wi-Fi is increasingly implied to equal “jamming”. Does blocking Wi-Fi with either wide band noise in the traditional sense OR network frame manipulation in fact now constitute jamming?
5. Pretty much all major WLAN vendors sell network management systems that include the very mitigation tools that were used by Marriott and Smart City to block hotspots. Are these tools legal under any circumstances? (If frame manipulation now equals jamming, it would seem not.) If they do have an envisioned legal use, in what situations can they be used without an administrator needing to worry about running afoul of the law? This is perhaps the absolute murkiest aspect of the entire Marriott/Smart City situation to those of us who bought these tools on good faith from our WLAN vendors. If blocking of Wi-Fi is illegal in every situation, why are these tools allowed on the market?

Without clear guidance, there is broad room for misinterpretation of what the FCC both is and is not saying on this general matter. PLEASE consider revisiting DA 15-113 and providing greater clarity on the above questions, for the benefit of all concerned.

Kind regards,

Lee Badman

TLPS- Chapter Something or Other

The ex partes are a flowing at the FCC in regards to TLPS. Here’s the latest  from engineer-turned-investor Greg Gerst, and like the previous filings, it only adds to the intrigue of the TLPS situation.

Here’s where you can find all of the filings to date on the wannabe WLAN offering from Globo Gym.

And here’s my coverage of the drama so far (start at the bottom and read up for proper historical order.) It’s utterly fascinating stuff. I’m obviously not in favor of FCC approval based on the way TLPS has been spun and packaged, but it’s reads like a mystery/drama/who’s really telling the truth saga regardless of what side of the issue you’re on.

Contemplating Lofty WLAN Things To Come

Don’t think me pie-eyed, or off-kilter. The following comes from having a good long break at the holidays, crappy weather, and lots of books to read. Books on wireless. Books on Software Defined Networking. Books on IPv6. Management books. Some cloud networking articles. And a book about American nurses and medics trapped behind enemy lines in Albania during WWII. (OK, that last one has nothing to do with this post.) Put it all together, and dare to let the mind wander forward… and you may start feeling the same dull, painful throb in the head that I’m feeling.

Why the angst on my part? I’m a WLAN architect, system admin, troubleshooter, advocate, defender, and realist. I’m also a network engineer that has to have a solid grasp of things on the wired side of the enterprise. I’m fairly innovative, and regularly have to create solutions where there are no obvious solutions to be had, and also am trusted to know where creativity ends and folly starts. I love my work, and also am cursed/blessed with being a big picture guy.

My boss is rightfully pushing my colleagues and I to get up to snuff on SDN. Like many, we’re starting with a Data Center-centric SDN philosophy as we get used to the idea. We’re also pecking at IPv6, despite artfully using private IP addresses, short DHCP lease times, and the occasional NAT for efficient preservation of our Class B network (yes, I know IPv6 isn’t just about IP address counts). We’ve ventured into the cloud a bit for various things, and are individuals in an organization that know why, how and when to evolve (personally and a s a team) for the most part. It’s an absolutely fascinating time to be a networker, given the new technologies at hand. Each of us that like what we do should thank the IT Gods for letting us be witnesses to this transformative period in networking history.

Yet my head hurts.

I think I can boil it down to this: if you contemplate out a few years, it’s really hard to see where all of the “new stuff” comes together, at least for me right now. To bulletize the comets of thought shooting through the night sky of my cabin-fevered mind:

• IPv6 is mature, and has been in development/trials for some time. It’s “standards based”, and once you learn the basics, the scariness fades.
• IPv6 on big wireless systems? Not so clear cut, and largely dependent on the WLAN vendor, their version of code, and which way the wind is blowing today.
• SDN got it’s start as better way to do Data Center networking, then the adventurous dared to stretch the paradigm out into the LAN as well. But where LAN meets WLAN, even in this age of “unified networking”, the end-to-end SDN crystal ball gets muddy.
• SDN is quite immature. It may shake out as well-designed framework built on standards (akin to Ethernet or TCP/IP) or it may fragment and get as ugly from the “every man for himself” perspective as how WLAN vendors do things under the hood.
• The Cloud is becoming more acceptable for WLAN management and Networking-as-a-Service, yet it can still feel like a one-off depending on how you implement and how far you go with it.
• WLAN and mobile networks are very much cutting into Ethernet’s turf, yet there are pockets where Ethernet will likely stay predominant for many years- even if Wi-Fi surrounds the corded network devices.
• There are things more easily done on the LAN (multicast, for example) that WLAN vendors and engineers still struggle with doing- without causing other problems.
• As we approach the heyday of 802.11ac, we’re still trying to sort out hype from reality and the WLAN industry continues to flat-out botch the message on how to cable for 11ac and what comes after Wave 2 (you may disagree), which complicates planning in large environments.
• The WLAN industry is sooooo silo’d and proprietary right now. System A is not compatible with Systems B or C, and and every vendor has their own way of doing things from the AP’s antenna stub back into the WLAN core pieces.
• Unification of wired and wireless is at different places for different vendors, not all WLAN vendors have switches, and where a vendor has both it again gets funky for interoperability.
• With data breaches aplenty happening and bound to happen as mobile device counts skyrocket and everything gets connected to something that has a target on it’s back, more regulatory influences are no doubt coming to a network near you.

Gone are the days when a big box connected to a bunch of Ethernet switches that connected to a handful of APs, and the entire thing was easily diagrammed out and explained as a single system.  This I know.

I also know that coming is a time where wired and wireless aren’t so delineated, where SDN reaches across the LAN-WLAN airgap, where it all runs on IPv6 (with implementation and feature parity across the vendor landscape) and big parts of it may be in or managed by the cloud. There’s an assumption that one day it’ll all be truly seamless, any and all applications will run and configure the same on both sides of the LAN/WLAN continental divide, and it’ll be so well designed that even the office secretary can manage the Enterprise without knowing anything of underlays, overlays, Dual-Stack Pattywacks, distributed or centralized Fruited Planes, address lengths, spatial stream counts, or any of the other network marshmallows in our new bowl of Lucky Charms.  

I know it’s inevitable, but my mind just can’t yet grasp how (or when) it’ll all come together.

Ah well- too much daydreaming can be a bad thing… time to go shovel the driveway.

 

Look A Bit Beyond WLAN RF

The RF part of wireless networking is often what keeps good IT folks from really getting proficient with WLAN, and many good WLAN types never look beyond the frequency ranges used in 802.11 technologies to see the bigger RF world that we live in. It’s understandable, especially for those without some sort of professional or hobbyist background with signals. The world of WLAN spectrum can be hard enough to wrap your head around, but every now and then there is value in seeing the bigger “comms” picture. The more you understand about the way different frequencies behave in the most basic sense (and what services use those frequencies) the more comfortable you’ll become with really understanding the more mysterious parts of both access-type WLAN and point-to-point bridging.

There are masters’-level classes on RF and radio technologies, tech training courses, and infinite online tutorials and calculators covering all the variety that falls under the broad heading of “learning about RF and RF systems”. This is one of those areas that you never, ever stop learning about. And once the bug bites, it’s not uncommon to become a radio-technology junkie who’s interested in far more than just the goings on in the 2.4 and 5 GHz slices of the electromagnetic spectrum.

Let’s look at just a bit of information on “commonly used” frequencies:

• How long are their wavelengths
• What are their natural “free space path loss” characteristics (how they “fade”)
• At a common power and antenna config, how do they behave compared to each other?

Sounds like heady stuff, yes? It’s really not that bad- so stay with me here.

The following frequencies have meaning to me, and certainly to many of you as well. I’ll give you the wavelength of each, and tell you how much the signal fades after 1 km based on these values applied to each frequency:

• 100 mW (or 20 dBm) of power
• Simple 3 dB antenna at the transmitter and receiver

Whether the signal would be usable (any signal left after path loss)

(Table created by me, there is some minor rounding done)

Again, we see that with same power and antenna gain/sensitivity, the frequency in play makes a dramatic difference to what’s available (or not) at the receiving end.

The frequency is a product of wavelength;  the lower the frequency gets, the longer the wavelength is. Lower frequencies also tend to require bigger antennas.

But this little exercise is of limited practical value, beyond helping to understand basic aspects of RF behavior at each of the frequencies I chose to show. High gain antennas, increased power levels (some technologies like Wi-Fi are limited to miniscule power levels while other technologies measure their outputs in Kilowatts), and environmental factors all influence the basic RF goings on at each frequency. Modulation types, quality of engineering, CPU and other silicon behind each given technology all also define performance of whatever technology is in play for a given spectrum. As I mentioned before, it does get complicated.

One of my favorite communications-oriented RF tutorial sites is at National Instruments. Although the American Radio Relay League (ARRL) is often thought of as a ham radio organization, they have a wealth of resources on all sorts of RF-related technologies and industry happenings.

If you’ve never built an antenna of some sort or another, you should. Whether it be a simple project for Over the Air TV or something weird for wireless penetration testing, its worth doing at least once. Research it, build it, improve upon it, and see how altering it changes the performance of whatever your application is (could be using a scanner to hear the local police comms or doing your own point to point wireless bridging), it’s fascinating to design and build something RF-related, at least once. You’ll find that seemingly unrelated wireless disciplines really do enhance the understanding of the actual wireless part of wireless networking.

Wireless Standards Just Aren’t Enough

First the love:

Anyone in the wireless game, like really in it, knows that wireless networking is incredibly complicated under the hood. That the IEEE and the Wi-Fi Alliance could herd enough cats to get us to where we are today- enjoying our 11ac honeymoon- far from the days of early 802.11 is amazing.

Let’s pause for a moment and think about how far we’ve really come, because it is impressive indeed. From a technology that was an expensive accessory at one point, with low data rates, high prices, and anemic security, to being the preferred method of access today for most of us, with rates and security features that are fitting for any environment (when installed right), wireless has grown up.  A huge thank you to everyone involved, as you’ve given me the best job in the world- that of a WLAN professional.

Now the lament:

As impressive as the modern WLAN is, somehow we ended up with some crazy market fragmentation and mindsets. Even though interoperability testing mostly keeps the wireless train on the rails, we still end up with enough in-place chaos to make life pretty miserable for wireless clients and support staff at times.

Maybe we try too hard for backwards compatibility. Perhaps device makers are lazy or out of touch, or could it be that the BYOD comet just hasn’t caused enough pain to really get everyone’s attention? For sure, the fuzzy, often-bludgeoned distinction between consumer and enterprise-grade components doesn’t help matters.  Here’s what I mean:

– In a world where we’re talking about “Gigabit Wireless”, we still have device and instrument manufacturers churning out chipsets that need 1 and 2 Mbps data rates to behave right. These devices are frequently intended for networks that aren’t likely to have those rates enabled.

– Printer manufacturers have far deeper roots in the business environment than does wireless. Yet, we can’t get printer makers to understand what their devices need to do for desired functionality on the “business WLAN”.

– What we call BYOD is actually BYOD/T; that is bring your own device AND TOYS to the WLAN. If it works at home on the living room network, you know damn well people are going to want to use them at work. Like AppleTVs and Google Chromecasts. To the uninitiated, you look at the specs on the packaging and see “compatible with 802.11n/g” or whatever, and jump to the conclusion that it must work because that’s the kind of network we’re using. The  warning label that should say “check with your networking department before buying this for office use” never makes it to the packaging.

But… rather than having to explain to users why this gadget or that can’t work on the WLAN, or killing ourselves to put in hyper-complex, house-of-cards-quality work-arounds, wouldn’t it be nice if somehow the Community of Wireless Client Device Makers could get with the times and build compatibility for both consumer and enterprise networks in to begin with?

Just supporting enterprise security would help immensely, and likely add little to the device cost. (I’m astounded at how out of touch the business printer/projector makers seem to be). There are certainly other nuts to crack as well before everything is perfect between the WLAN and BYOD/T devices, and Apple could be an absolute leader here. Bonjour has long had it’s day, as I’ve bitched to anyone who will listen.  “Apple TV is perfect for the boardroom” provided that you have one small flat network and one boardroom. But when you have hundreds of boardrooms/classrooms and complicated LAN topologies, devices like the Apple TV are a supreme pain in the assbone. If Apple could do right by the customers who continue to fatten the company’s immense bottom line and give us something better than Bonjour for their devices in the workplace, maybe other device makers would follow suit. (Did you know that higher ed is begging Apple to provide relief from Bonjour headaches?)

Maybe we need tighter “categories” from the Wi-Fi Alliance- with devices that are labeled either “Enterprise Ready” or “Consumer Grade”. This would give incentive for the lower-end stuff (including Apple’s Bonjour-based devices) to step it up. It would also give a clean delineation for networkers to point to for device support. If done right, We could say “if it’s got the Enterprise-ready label, we support it” and if not, don’t bother bringing to us. Everyone would know where they stand, as the criteria that goes into an “Enterprise Ready” compatibility testing program would be based on far more than just whether radios can talk to each other. It’s a nice thought anyways.

Ah well- end of rant. Now if you’ll excuse me, I have to go explain why Chromecast doesn’t work on our 802.1x-based WLAN.