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.

How WLAN Vendors Can Solve The College Dorm Problem

Ladies and gentlemen of the WLAN industry, here are the problems with wireless networking in college dorms, and a head start on how you can develop a solution.

Problems:

1. College dorms are usually covered by the same enterprise 802.1x network used on the rest of campus, but are really more residential feeling at the operational level.
2. Wireless printing doesn't work where you have hundreds of anything-goes printers with no coordination on the same WLAN- and consumer-grade $40 printers don't support enterprise security.
3. Game consoles and Bonjoury toys also are fraught with problems and usually need yucky work-arounds on the business network usually found in dorms, or get relegated to the wired network.
4. Rogues get installed to get around what campus WLAN can't easily provide
5. Ditching the enterprise WLAN and letting students bring their own wireless routers is a recipe for chaos and angst from the RF and support perspectives.

Solution:

It's not cut and dry, and my enormous cranium hasn't yet formed the whole solution. But it starts like this:

1. Keep all the benefits of a centrally-managed solution. RF coordination, central monitoring and configs, etc- whether cloud-based or local not so important here.
2. Study PowerCloud's Skydog network paradigm. Everything about it doesn't fit the dorm challenge, but a lot of it does. If you can treat each dorm room as an apartment, with a dedicated SSID or some other compensating control (not all dorm rooms would need their own AP) we'd be off to a good start
3. Maybe use elements of Ruckus' Secure Hotspot in a way that lets a single student or roommates have all of her/their gadgets in a little "private WLAN" all somehow using the same private PSK.
4. Make sure any one student's most common gadgets can all interact in their own little WLAN space (even Bonjour toys and printers), that it's all easy to self-setup, and can be administered by WLAN admins if trouble hits. 
5. With all device types accomodated, the reasons for rogues are eliminated.
6. Make sure students can't get to each other's stuff, but allow for on-demand temporary access when sharing is desired.
7. Make sure that however it all gets put together, the RF environment is still well-coordinated.

There- that was easy. Now someone just needs to build the code and interfaces... 

 

 

Here's What I Want NOW From My Wireless Management System

When it comes to the management and security of wireless networks, I want a lot of things. I want new things, and I want legacy things that aren't going away to get better. I want slick, I want fast and I want effective. I want powerful, feature-rich, and a say in what features are worth devoting UI resources to. I want it all, baby- and here's my latest rant on the topic. You're going to love this.

Before I drop the bomb, lets set the stage.

I had the privilege of hanging out with the fellows from 7signal at the recent Wireless Field Day 5 event, and seeing how they do WLAN RF health characterization,  as well as getting a peek at what AirTight is up to. Being a long-time Cisco wireless customer, my mushy brain cant help but bring everything back to my vendor for comparison; but more on this in just a bit.

In my spare time, I've been having more fun than a person should be allowed to with the addicting Wi-Fi Pineapple (along with some tricks from the much-revered BackTrack Linux.) And at work, we're gearing up for thousands of students to flood back into the dorms, which means Rogue Hunting Season is neigh. Put all this together and feed it into the "It's Easy For Me To Demand Things From Other People That I Can't Do" engine, and out pops the following wireless support and security gem:


Wouldn't it be cool if...

• You could take one of your in-service APs and turn it into a virtual client that associates with other APs? (stay with me, I know you've heard this part before)


• Synthetic testing with said virtual client was possible: do my DHCP and RADIUS servers work? Can I reach the Internet? Can I reach other locations, from each of my SSIDs?


• The virtual client AP could report on nearby rogue networks, after I set a min threshold value, (getting closer to the money shot) and tell- Is the SSID open or protected?


• My virtual client could associate to the open SSIDs, and report back what the public IP is of the rogue?  (I could find it then through MAC or ARP tables if on my own network- doesn't need to be automated)


• Here's the LAGNIAPPE, baby- If the rogue SSID was encrypted, I'd like my virtual client to execute Aircrack-NG, Reaver, Fern, or whatever. Somehow, the power of my management system harnessed to this virtual client/pen testing-mode AP would give me a big-assed, infinite dictionary from hell and lots of power to crack. Then I could go back to the "find the public IP" step, which to me is the ultimate and definitive "game over" versus a lot of wireside detection systems that are so-so with their success rates.

I know there are lots of ways to do "wireless support", but I am enamored with the force-multiplying capabilities of a well-constructed virtual client mode for installed APs (as I imagine them working). I've been beating the drum for Cisco to consider basic virtual client functionality for years, to no avail.

But now I want even more- I want a "virtual client AP meets BackTrack Linux, and they have offspring" mode.

I'm not asking for too much, am I?

Get To Know MetaGeek, Look at Your WLAN As You Really Should

MetaGeek is one of those companies you love crossing paths with. Their staff have titles like Hacker, Geek, Firefighter, and so on. Everyone from MetaGeek I've ever met, be it at events like Interop or more recently Wireless Field Day 5, speaks with pride and openness. Their presentations and pitches never feel rehearsed, and you know that this is a company made up of believers in MetagGeek's products and future. And- they always have that "Idaho Vibe" that you gotta love, once you know how to recognize it.

At Field Day 5, I had the pleasure of meeting Chris Woerz and Stoney Tuckness, as they demoed the MetaGeek line, talked about some of the decisions that went into the specifics of their approaches, and queried us Field Day delegates  about what we would like to see in future products and feature sets. Chris and Stoney work fast building rapport with the crowd, and it's obvious that those in the room adore the MetaGeek line.

About MetaGeek's Offerings

I've used the original Wi-Spy, the freebie InSSIDer on every platform that will run it, and Eye PA in my wireless networking duties. At Field Day, Stoney proclaimed that MetaGeek likes to provide "kick ass visualizations", and I can attest that they hit that target. Whether you want to see simple spectral views on what's happening in Wi-Fi's 2.4 and 5 GHz bands, a unique, powerful visual front-end to 802.11 packet capture, or advanced interference detection integrated with Cisco's respected CleanAir, MetaGeek has you covered. Every good WLAN engineer wants there to be no mystery to what's going on with the RF in their environments, and Metegeek nicely demystifies the complex.

Cool, fairly-priced tools are one thing, but then there's general knowledge about wireless networking. I'm guessing  a fair number of MetaGeek customers aren't aware of the online forums the company provides. Here you'llfind  a wide range of information on WLAN in general, and lots of tips on using MetaGeek's stuff. It's worth the visit.

As the 802.11ac clouds gather over the WLAN landscape, things in the RF domain are about to get much busier, and more complicated. Understanding what's going on truly benefits from seeing  what your RF "looks" like through the lens of good tools. If you have no MetaGeeks' utilities in your toolbox, you're missing out on powerful magic at a fair price.

What Meru and Xirrus Need to Do

I'm not a big deal, but I know a guy who is. And- I have pulled off San Jose's most brazen balloon theft. These two facts combined qualify me to advise multi-national wireless networking companies on communications strategies. Here's my advice for Meru and Xirrus, after visiting with both companies for Wireless Field Day 5.

Both companies are headed by obviously intelligent technologists who are passionate about their product lines. Each has well-spoken customers willing to testify on the effectiveness of their gear. Both are still in business in a pretty competitive space, and hoping to grow their shares of the WLAN market. And both have unique technical stories that set them apart from their industry peers.

And here is the problem.

For years, I've listened to a number of briefings with Meru and Xirrus and always walked away with a nagging sense that each is actually a bit uncomfortable talking about their  "specialness" to any depth when dealing with Classically Trained WLAN Types. Xirrus does the array thing, and Meru rocks the single-channel architecture groove. Both companies want to talk about their bigger stories, but many of us don't feel satisfied with terse "trust us, it works" explanations on features that are radically different from industry norms. So... briefings grind to a halt because tech-analysts want to know why we should accept that these companies have actually found a different way to do things. But the companies' speakers obviously don't want to spend their camera time on these years-controversial details, and neither party quite feels great at the end of the experience.

And here's the fix.

There's certainly a fine line between disclosing intellectual property and being open with those asking pointed questions about your technology. But that line needs to be walked when you build product lines on unique technical approaches. Sam Clements and Keith Parsons are well within their professional purview to challenge Xirrus on how they can pack so many antennas into such a little box without them creaming each other, especially when other vendors sometimes bash Xirrus for their designs. And Chis Lyttle is proper in asking a few times for more info on Meru's "special sauce" even if it slows down Meru's onboarding demo. Tech people want to hear what tech people want to hear, and neither company tends to want to get into the nitty gritty that would get us all to shut up already and let them get our full attention on their latest announcements.

Each company should embrace the living hell out of their uniqueness. Lead with it, don't tap-dance around it. Stick it in our faces with good, digestible white papers and diagrams that clear up the mysteries once and for all without giving away IP. That way, when we all get together again, Xirrus and Meru can not only deliver the Message of the Day, but actually get us to listen to it instead of badgering them for information on the little things they do that many of us have been trying to comprehend for years.

We'd all be better for it, especially Meru and Xirrus.

Wireless Is So Not About Wireless Networking Anymore

Lee you fool, you've gone mad. How can wireless not be "about" wireless? 

Before you run off to another blog, let me clarify: today, as we stand in THIS SPOT in the wireless networking universe, never has the WLAN paradigm been so complicated. Yeah, we still need to get APs out there and provide access to wireless clients, but sitting through the sessions at Wireless Field Day 5 has me waxing philosophical. 

Like frogs in a pot, we've all been slowly boiling in increasingly complex waters over the last few wireless years, and it's easy to not notice that it's happening. Having sat through excellent sessions with WLAN vendors (Aerohive, AirTight, and Motorola- with Xirrus and Meru on deck) and toolmakers (Fluke Networks, MetaGeek, and WildPackets- with 7Signal later today), it's safe to say that to be in the wireless game today means being more diversified in skills and general IT sensibility than ever before. 

As the 11ac tide starts to rise, we're all faced with decisions:

• When do we start taking our own networks to 11ac?
• When do advise our customers to move to 11ac?
• Is moving to 11ac a given for everyone?
• Is 11ac the juncture where we consider changing WLAN vendors?
• Is 11ac the juncture where we look more at cloud-managed options?"

These are easy enough to grasp, and behind each of these questions there are other questions regarding the states of our installed network wiring, what generation switches we're running, what version of PoE we're on, etc. But these issues are rather pedestrian compared to what else is afoot right now under the umbrella heading of "wireless networking".

While marketing departments still like to lead with "we have the best APs! Look how freakin' fast we are!", there is a lot more to consider as our WLANs modernize.

Along with the radio technology and bandwidth sides of 11ac, we're facing an onslaught of factors to grapple with- like:

• a slew of analytical capabilities and ways to use that data
• device onboarding that can be as nuanced as your mind can dream up
• the ability to assign access privileges to device types, user types, application types, locations, times of day, and combinations of any and all of these
•  application visibility and taking action on what you see
• the system administration of complicated management systems that frequently fall on WLAN types (somebody has to keep them up)
• the increased number of bugs that come with the floodwaters of new features
• a procession of ancillary services and servers that don't directly have anything to do with client devices talking to APs, yet each is part of the bigger picture

You can make the point that none of these really have anything to do with 11ac per se and are better suited for policy and staffing discussions, but here are my counter points to that:

• To "go" to 11ac, you likely have to upgrade code on controllers, management systems, or whatever magic is afoot in cloudland
• When you upgrade, you get lots and lots of features that you didn't ask for- you're already buying them (unless they take stand-alone licensing, which is its own story in inconstancy across vendors)
• The more features you use, the more you have to troubloeshoot, debug, define policy for, educate users and support staff on, and watch over for issues
• The ancillary services in use for our WLANs frequently take more effort to keep on the rails than the wireless environment itself does
• Almost any part of the environment has the ability to convince users that the WLAN itself is borked, when the problem may actually be off in the hinterlands of the ecosystem 

Put it all another way- 11ac makes WLAN more complicated, but the accompanying backdrops and backstories of our networks are also getting dizzyingly busier. So busy in fact that they can make talking about 11ac itself seem like the easy part of the equation.

I'm not bitching, mind you- but just taking note. These are complicated times for wireless networkers, and sometimes "wireless" really has nothing to do with wireless.

 

The Little Adapter That Could... WildPackets Gives Us First 11ac Capture/Decode

As we all sail into the 802.11ac years, we're getting antsy about tools that will support this rather complicated and nuanced standard.  How do you support and troubleshoot an environment made up of clients each using any one of dozens of permutations of spatial stream counts, data rates, and channel widths in wildly dynamic environments?

There has been a fair amount of buzz around early-shipping 11ac access points and clients with lots of philosophical buzz about uplinks, PoE requirements, and such. But not so much of substance has been said on the "and here's how you'll troubleshoot it" front. Here at Wireless Field Day 5, we spent Day 1 with a couple of network tool-makers and got perspective on where Fluke Networks and WildPackets are both going for 11ac support. Each sessions were great, with more to follow on Fluke Networks in another blog. Here's what went down at WIldPackets.

The short of it: Wild Packets provided delegates with a nifty little USB adapter that can do legitimate 802.11ac packet analysis on their latest (7.5) OmniPeek.

I recently wrote about 11ac troubleshooting and WIldPackets a bit in my Network Computing blog, and it was great to have the opportunity to sit in WIld Packets' conference room and get a demonstration from a master- Director of Product Marketing Jay Botelho.

Each Field Day Delegate was outfitted with the Linksys AE6000 mini USB adapter, the custom WildPackets driver that makes it all work with the all-important promiscous mode capabilities, and an eval copy of the latest OmniPeek. From there, Botelho showed the process of 11ac support with OmniPeek, discussed the challenges of 11ac when tackled at the packet level, and got the delegates each equipped to do their own captures.

Fellow delegate (and Wireless Jedi) Keith Parsons documented the process for getting this arrangement to work on a Mac laptop running Parallels- a very good read.

The Thing About Code

Code is amazing stuff. Good code puts people into space, runs super-colliders, and keeps the Internet ticking. Bad code on the other hand, winds up on wireless controllers.

OK, just kidding.

Maybe.

For the life of me I can't understand how vendors keep crappy code listed on their download pages, often at the top of the list, for customers to find. You know, the kind of half-baked stuff that everyone from sales engineers to tech support cringe at when you tell them what version you are running. Which often also happens to be the same code that others from the same company declare to be "the good code", and recommend that you go to to get past some other problem with earlier buggy code. Ever been there? It pretty much sucks, yet this rhythm seems to have become an operational model for some vendors.

This is where we pause, and I read minds. Quiet please..... quiet..... shhhhhh. I'm picking something up..... ah yes, got it. The "testing" fallacy- I'll address that..... wait, one more coming.... what's that? Oh, sure- the release notes thing. Let's talk about both of those.

I hear an awful lot of "test, test, test!" from colleagues and respected industry folk. And I do agree that nothing, including code, should be rushed into to. But please tell me- other than just being a mantra, what does "test, test, test!" really mean? Does it mean load the code on a test box, configure it the way you'd use in prod, throw clients at it, and then wait for smoke and screams? OK, that's acceptable. Or maybe it means that you should actually take what I just mentioned and add whatever new features that interest you into the mix, and make sure they don't create problems. Fine, yes- this too is arguably reasonable.

But guess what vendors? If you expect us (and evidently some of you do) to be your crowd-sourced QA departments, let's call it what is and put warning labels on code:

"Caution: we either don't quite know WTF this code will do in many environments, or we have some inkling, and it ain't pretty. But we're putting it out there anyways so you can be our debug squad. Stuff that has always worked now may crash, but it's worth it because this is NEW code."

We buy the hardware and code, pay for support on it all, eat the pain and suffering that comes with the shaky code, and the vendor gets to say "you really need to test new code and let us know what you find". Everybody wins- except for the customer.

We don't know what modules and packages were added and changed, and we're not programmers with access to source views to that which is causing us pain. (Funny how we don't tend to have these problems in the mobile network world.)

Then there are the release notes. Hats off to vendors that are open an honest about their shortcomings with their code. But... when the same bugs are listed for years, you start not to pay attention. And some unresolved issues sound minor, but can bring the house down. Others sound apocalyptic, but actually happen so rarely or have minimal real impact that they can be safely disregarded. But they are all listed in the same terse "you figure it out, and good luck with that" manner. The onus is unfairly on the customer to wade through it all, and that is wrong for COTS gear- would be different if this were all open source.

So how do "we" fix this?

• Stop putting out shitty code. Plain and simple. Just stop. New features aren't worth instability- client access is the key mission of the WLAN and if the WLAN is melting down from crappy code the key mission is compromised


• If code is found to be crappy on a catastrophic scale, PULL IT. Don't leave it up for others to find. And reach out to customers pro-actively like an automotive recall to let us know about it. Many WLANs these days have million-dollar plus price tags- we deserve better.

It's time to stop the code insanity.

Good Pineapple, Bad Pineapple, Educational Pineapple

Years ago, I got certified in CWSP and also taught wireless security for a while. I took an amazing class from SANS back in 2008, and had the honor of having Joshua Wright as the instructor. I've written a fair amount of wireless policy, designed networks that use 802.1x, VPN, Encryption Gateways and almost any other mainstream (or slightly off the beaten path) security method available, and have done the PCI and HIPA wireless things. I got really good at finding rogue APs through network clues, combined with "other" elements of information that many in wireless might find atypical (thank you, ten years in a fascinating Air Force career field). I like to think that even though it's not my current core competency, I generally "get it" when it comes to wireless security.

But my goodness, what a pineapple is teaching me.

OK, it's not a real pineapple- it's a cute little router warmed over with bastardized Open-WRT firmware. And it's teaching me (and reminding me of many things I'd forgotten) a lot about general wireless security.

Part of the experience, as I contemplate why I'm enjoying this evil little toy so much, is where it falls on my own timeline. My Linux skills used to be a lot stronger than they are now for lack of use, phishing is becoming commonplace, and I'm part of a society that is generally both more mobile and hyper-willing to jump on any open WLAN they can find. For me, the Wi-Fi Pineapple is providing hours of entertainment and serving as a self-guided training course of sorts in wireless security, penetration testing, and being an absolute pain in the ass to those nearby.

Once you get set up (spring for the thumb drive, it's pretty much essential), there are roughly a couple of dozen "infusions" or packages to install. Some amount to stand alone hacks/tricks, others work in concert to pull off the likes of a sophisticated phishing attack.

I'm basically working through the list, getting competent in each infusion as I go. This is accomplishing the following for me:

• making me dust off past Linux command skills


• making me think about why what I'm doing is working, or not


• taking my brain to wireless places that I don't have to think about day to day


• making me much more paranoid and careful about using public Wi-Fi


• helping me to understand the mechanics of a number of wireless attacks


• putting me in a better position to participate in, defend against, and converse about wireless pen testing by making the attacks easy to do and demonstrate


• providing great fun- who doesn't like Rick-rolling family members?

Those who are deeper into real wireless security or have good scripting skills might wave off the Pineapple as something you can do yourself for cheaper and without the pre-packaging. I don't debate the point, but I also know that I find great value in the support forums and slew of Pineapple related videos available all over the Internet. I like that the Pineapple is a starting point, and that lots of people who try to use it get frustrated- it shows that you still need to think and experiment at least somewhat. Your experience, curiosity, threshold for cheap-thrills, and general knowledge will have direct bearing on how much value you get out of the experience.

This little unit is great fun, but after playing with it I can say this: the thought of a secret army of Pineapple soldiers out among the common folks in public wireless cells is a bit disturbing. It's worth reading about, if for nothing more than knowing what kind of relatively-easy-to-use potentially bad stuff (it's just a tool, it only becomes bad when the user opts to go that way with it) is out there.

Pondering WLAN Innovation

The modern wireless network, regardless of who creates the components, is certainly getting complicated. But is it innovative?

Asked another way- does sheer complexity equal innovation? And who decides what constitutes an innovative feature or component? Is it the vendor? The customer? A developer thousands of miles away from both?

Here's where I pause, and assure readers that what follows is not meant to bash any company, I'm simply pondering what innovation means to today's WLAN, and whether it couldn't perhaps be stewarded along a bit more collaboratively as the world gets increasingly more dependent on the fruits of our wireless labor and our systems get fatter with features.

There are a lot of definitions of Innovation, and some pretty fascinating reads on the topic. For the purpose of what's on my mind, I'll call innovation a good idea that serves customers well with some meaningful market duration while making the originator a profit. Simple enough. If I had to give innovation a formula, it might look like:

(Good Idea + Customer Acceptance) x (Time on Market + Affordability) =  Amount of Innovation
Or something like that.

Back to the question of who decides what constitutes innovation? If a new feature or product is marketed as "an innovative new offering", my first thought would be "how do you know it's innovative if it hasn't proven itself in the market yet?" Time judges innovation, not the person who came up with the idea. Sure, HP's TouchPad was an engineering accomplishment, but if it was really innovative, it wouldn't have tanked, would it have? Or maybe it's too harsh to say that "failed innovations weren't really innovative after all" (Perhaps some would-be innovations come along at the wrong time- again, I'm just pondering.)  Whatever- it's heady stuff to contemplate at the analytic level.

Back to wireless networking. I look at some of the systems I use (both for client access and WLAN management) and see a mix of innovation and feature bloat. Sure, there are nice aspects that bring value to the typical customer, but also ill-conceived features that obviously were never presented to a WLAN Admin Focus Group. Because they are all packaged together, you have have to tolerate the non-innovative distracting stuff to get into the innovative features, It's just the nature of the beast. Maybe this overall affect could be improved. Maybe we should start hyping BYOI as much as we hype BYOD.

What's BYOI? It's Bring Your Own Innovation- and we need more portals for it between customers and WLAN makers.

Wireless network administrators know what they need. Arguably, they can be serve as the advisory panel for features likely to be good innovations, and also judges for when an innovation has "expired" and needs to be replaced (why I am thinking of Apple's Bonjour protocol?) Sure, vendors give us hyper-complicated systems bursting with graphics and endless menus, but that doesn't mean we've been given innovation. And innovations don't have to be crazy disruptive and life-altering for the entire WLAN space, they can just be simple little changes that we'd buy more of because they are needed.

Without a clearly defined method of getting feedback and feature requests to decision makers within WLAN companies, it is my conjecture that innovation suffers. Meraki came close to getting it right with their Make a Wish mechanism (i remember being thrilled when I asked for alerting on DHCP pool exhaustion and then it showed up shortly after), but even after I made my wish, there was no way of knowing whether it was heard. Or whether others had asked for it as well. For many big companies, the culture seems to be "you the customer can just wait for us to innovate on your behalf, and if you feel like getting frustrated feel free to talk to your SE who also has no clue what's coming". Again- no bashing; the WLAN industry is generally amazing. But some of us would like to influence the innovation we pay for and help the mothership to realize when they get it wrong in the name of innovation.

Wouldn't it be cool if each vendor (or the industry itself) had a portal for  "What Admins Love and What Admins Hate About The Current System"? Ideally, it would be visible to at least other customers of the same system so we could see what our peers are also thinking. And if once a year, the feedback was aggregated, sorted, and put in a Top 5 of Loves and Hates with vendor commitment to answer them in some meaningful way ("Yes, we see that 98% of you hate the new Flash Interface, we'll try to work on that by 12-months out", or "75% of you would like to see ______ but here's why that is technically impossible" kinda stuff). Or if not a feedback dashboard, some mechanism that accomplishes the same thing.

We The Wireless People would love to have more of a hand in innovation, for everyone's benefit. We're closest to our clients, we know what we need, and we know what we don't. And if it doesn't get used, it isn't innovative.

With 11ac, The WLAN Industry Owes Customers A New Kind Of Network Switch

I realize I'm beating the 11ac thing up pretty good lately, but I think I finally hit on what bugs me about the way the new hot technology is being brought to market. What I'm about to describe is more of a BAN issue (BAN=BigAss Network, where APs are counted in the hundreds or thousands) and not so much of concern for smaller environments.

802.11ac is being delivered in rather bizarre (for the customer) "waves".

• Wave 1: Data rates to 1.3 Gbps. You'll do fine (for most new first wave APs) with a single Gig uplink, and many new APs will work on 802.3af POE, not yet requiring .3at. Fine, good. No real squawks.


• Wave 2: You get the joy and cost of recabling your environment to add a second Gig uplink, doubling the number of switchports in use for the WLAN and configuring Etherchannels, and depending on what vintage switches you have- upgrading them for latest POE standard, all to help get to data rates likely to realistically be between 2 and 2.5 Gbps best case.

And this is where I say "time out". I'd like the WLAN makers to bear some of that Wave 2 logistical pain. And I want them to get creative to take the onus off of the customer. Here's what I want:

• In simplest terms- I don't want to use two cable runs. And I don't want the complexity and risk of 4000 more Etherchannels for my APs. But I still want the benefits of 11ac Wave 2.


• I would like the WLAN vendors to put their brilliant minds (and that I do mean sincerely- these guys and gals accomplish amazing, amazing stuff) to work to come up with a new switch or mid-span injector. Here's the requirements:
  
  
  
  • No feature bloat. May not even need to be VLAN aware.
  
  
  • Provides lots of PoE
  
  
  • Somehow puts 2 Gbps of uplink to an AP on a single UTP run without requiring me to configure a port channel
  
  
  • Cost effective (by customer standards), no licensing BS, and ultra-reliable
  
  
  
  

Spare me the lecture that there is no such thing as 2 Gig Ethernet, and that what I'm asking for would be based in no existing standard. The WLAN industry has long since turned it's back on standards and interoperability, which is why vendor lock prevails. Other than PoE and what comes out of the antenna (and even that can be a dubious discussion), the mention of standards is a joke in the WLAN industry as each vendor authors their own technical magic. So be it- I just want new magic and don't care that it's not exactly Ethernet in the middle.

I'm OK feeding this new component a 10 GB uplink that it then divvies up into auto-configured 2 Gbps AP uplinks of some proprietary protocol. Or feeding it 2 single-gig ports on my wireless management VLAN that it then magically muxes into a 2 Gbps, big powered uplink that connects via a single wiring run (of excellent quality, of course) to each AP. At that point, all of MY work was done in the closet, and I didn't run a slew of new wires for my wireless network.

If we don't get something disruptively creative on the wired side to go along with 11ac, pretty much any TCO discussion on new 11ac ownership presented by WLAN vendors will be incomplete at best, and poppycock at worst. I've seen both announced and unannounced 11ac products- and the prices are pretty steep (well, except for Ubiquity). But we're supposed to believe that 11ac lets us draw down the wired network considerably, and so be willing to buy into a higher premium for wireless. But... adding lots of new switchports and cabling runs (not trivial in many environments,  can add hundreds of dollars in cost to real TCO for each AP) has to be considered.

As a customer, I feel OK asking- because the customer is always right (well, except when they're wrong). So... when will my new non-standards-based 2 Gbps mega-PoE switches arrive?

About Wirednot

Lee Badman (that's me) is a long-time wireless and networking professional. I also blog professionally for Network Computing Magazine, for whom I've written hundreds of short and feature-length articles through the years.

Not everything I'm interested in regarding wireless makes it to print in Network Computing, and so the Wirednot Blog provides me an alternative venue to cut loose a bit.

Follow me on Twitter @wirednot, and feel free to comment on anything you feel like here. I do the Linked In thing, but I don't take it real seriously.