Bummers in WLAN Land

None of the following gripes are the industry's biggest problems. At the same time, they are nuisances and occasionally rise to the level of major headache. Some of these apply to WLANs of all sizes, others are far more applicable to bigger wireless environments. The remainder? They're just goofy. If any one of these were to be corrected or adjusted a bit, the wireless world we live in would be a little sunnier. In time, each and every one of these will "age out" and cease to irritate, but for now they are fair game to call out into the light  of day. I got me a license to bitch, and here it comes, in no specific order:

• Why are those cheap bastards at the laptop factory still putting out 2.4 GHz-only capable computers? It can't cost more than a couple bucks to provide a dual-band adapter in even the cheesiest laptop during manufacturing. Yet you have to look fairly hard, and often get into some serious upgrade dollars, to find a consumer-grade laptop (beyond Macbooks that come with dual-band 11n in all cases) that features both bands. It's almost unheard of in the "Sunday Specials" that feature prominently in the BYOD demographic. We all suffer for the side effects, and it's about time Acer, ASUS, Lenovo, and the other economy-class PC makers stepped up and became better citizens of the WLAN community.


• What's Up With Gartner's Quadrant When It Comes to Wireless Vendors? Gartner has always been a bit polarizing in their analysis of various technology sectors, but they flat out blew it with eliminating the WLAN-specific quadrant in favor of including only "unified" vendors.  It boils down to these:
  
  
  
  • Sure, some vendors make Ethernet switches and wireless APs. But in many environments, switches do little more than provide PoE for APs. Big flippin' deal.
  
  
  • When a company as radio and antenna savvy as Ruckus can't make it into The Quadrant because they don't have switches, there's something seriously wrong.
  
  
  • A Unified Quadrant isn't bad, but it's incomplete and therefor a disservice to the industry. It's time to bring back a WLAN only Quadrant, and a switching-only view IN ADDITION TO the unified Quadrant.
  
  
  
  


• Apple really missed the boat by not including 11ac in their very expensive new iPhones. The Big A should be a better steward of the client device space's future. If Samsung can do it, so can the Gods of Cupertino's Mountain of Cash. Instead of breathing life and craze into early 11ac adoption, Apple cheaped out and disappointed the fans (and wireless admins) that were hoping for more out of Apple's phone, especially for the money.


• Apple's Bonjour. Enough already. Fix it, and do your part to provide some pain relief to the wireless shepherds of the BYOD fields where your gadgets roam free.


• Cisco's Wireless Management System. It's WCS! It's NCS! It's NCS Prime! It's Prime Infrastructure! Whatever it's called this week, it's still buggy, slow, frustrating, and demanding of it's own FTE staff just to keep it breathing at times. To think about putting switches into this same management framework as wireless on very large networks as "unified" gets deeper into the management paradigm is the stuff of horror- unless we see a major overhaul soon. Too much of the WLAN market relies on this sometime-train wreck to not improve it.


• The Fallacy of Interoperability and Standards in the WLAN Space. Sure, we check our wireless devices for the famous Wi-Fi Alliance seal of approval that should mean all is well when devices need to talk with other devices, but there's a lot more to the equation. Consumer-grade stuff often doesn't play well in the Enterprise but nothing on the packaging explains the delineation. And... I can't mix and match enterprise WLAN hardware or features like I can Ethernet switches. This is arguably the way it has to be, but its also a royal pain in the butt at times. Vendor lock is real, for better or worse.

We've all got things that steam our clams when it comes to wireless networking. These are on my short list this week. The world certainly doesn't have to change on my say so, but at the same time time I can squawk about it, by golly.

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

 

 

Features, Products, Services... The Differences According to Aerohive

I recently visited Aerohive's home turf as one of the delegates at Wireless Field Day 5. It was wonderful getting to meet, in person, many Bees I frequently interact with via email and social media.

My own history with Aerohive is built largely on covering their evolution from the early days, writing about them professionally in Network Computing Magazine. As with other vendors, sometimes Aerohive gets the spotlight and sometimes they get compared against when analyzing what competitors are up to. I have my own small Aerohive environment, and have first hand familiarity (not mastery, mind you) with Hive Manager and a couple of AP models.

Aerohive has been a major player in minor-but-growing cloud-managed wireless network space that includes Meraki (Cisco), AirTight Networks, and PowerCloud. 

Ah, cloud-managed networking. I've become a fan where I use it (and I do use it in a number of sites). I like that one of the running campaign themes of cloud-based networking in general is reduced hardware counts with no convoluted licensing schemes. 

Though Aerohive has done a good job with pushing the value of "here's a new feature, and you'll just get it with your next Hive Manager upgrade at no additional cost!" message to customers, I was taken a wee bit aback during the Field Day briefings on Aerohive's IDManager and Client Management services because they were called "new products" that require licensing.

Both offerings will no doubt be welcomed by existing Aerohive customers, and are easily marketed at prospective customers looking for a robust, all inclusive solution. My own little private shock at the licensing requirement doesn't detract from my overall opinion on Aerohive, and after thinking about it , I know where the surprise comes from: we've gotten so used to rich feature sets being "free" that we instinctively expect the gratis model to apply to any and all "features" Aerohive develops. Which really isn't fair to Aerohive, but is how we've been conditioned on the customer end.

I wont pretend to understand why Aerohive has "given" so many enterprise-grade services away to date that others license for, but draws the line at IDManager and Client Management. Nor do I care enough to get hung up on it, as other vendors seem to be licensing their Onboarding services as well after hearing their briefings. 

For those keeping score at home, here's a breakdown of some of what is included with Aerohive's Cloud Manager and licensed APs under the heading of "it's just in there":

• Spectrum analysis
• Application visibility and control
• Statefull firewall
• QoS
• VPN
• Partner MDM hooks
• Planner software(free to non-Aerohive customers too)
• Bonjour gateway software (also free to non-Aerohive customers)

And what you have to license seperately:

• Client Management (license blocks of 100)
• IDManager (tiered licensing, starting at 250 guests)
• StudentManager (blocks of 1000)

 

 

 

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.

Fictitious Bands of Silicon Valley

I'd go see any of these...

Heatsink

Chuck Chipset and The Floating Points

3dB Down

Maggie Yagi From Venus

Coaxial Maneuvers In The Dark (CMD)

Standing Wave

Kilowatt Rage

Billy Bridge and the Links

Buggy Code Rex

Rebecca Radius and the Authenticators

The Analyzers

Tommy Harmonic (featuring Feedback)

Miliwatt Flatts

Downtilt

Auntie Bracket and the Mount-notes

Samantha Spectrum

Paul Predictor and The Heatmaps

 

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.

What I Hope To Get From Wireless Field Day 5

Being selected as a delegate to a Tech Field Day is a bit like winning a Golden Ticket to Wonkaland for us tech types (instead of chocolate, there is a lot of wireless fodder to enjoy). I'm pleased as can be to be going back for my second Wireless Field Day event, having attended WFD4 and soon, WFD5.

Given the Silicon Valley's prominence in the IT world, a trip there is something akin to a pilgrimage for those of us too far away (by both distance and circumstance) to get there very often. And that touches on my first goal for Wireless Field Day 5: simply being immersed in the tech-rich backdrop of the San Jose area. I'm not a tremendously spiritual person, but there is a powerful vibe afoot just under the surface "out there", and it bubbles up time and again throughout the few magic days that are Field Day.

The corny stuff aside, here's some of what what I hope to get out of my time at WFD5:

• Reconnecting with organizer Stephen Foskett and my fellow delegates. Most of the group was at WFD4, but there will be three new-to-me faces among the delegates, as well as Stephen's expanded staff. These folks are sharp, down to earth, a pleasure to do the event with, and extremely deep in wireless networking knowledge. This alone makes the trip worth it.


• In general, I'm looking forward to all of the companies that are presenting to give us a glimpse behind the curtain at what they are about to release, what they are thinking on a number of fronts, and what they want to know from us, the delegates. Expected hot topics: 802.11ac, analytics of various sorts, new tools and optimization methods.


• Speaking of tools and optimization, 7Signal is sure to be a delegate favorite. I'm guessing we've all seen at least snippets of their case studies and what they recommend to make good WLANs even better. I hope to hear clarity on this topic, and to get a sense of whether 7Signal gear is more affordable than it seems and to hear about optimization tweaks that are real-world applicable.


• With Meru Networks in the lineup, I'm guessing I'm not the only delegate hoping to walk away with a better understanding of their "secret sauce" for single-channel virtual cells, and whether there is more than just bluster to their occasional hubris (as I've covered in my Network Computing column). To a certain degree, the same goal applies to Xirrus- I've covered them a number of times but never quite got totally comfortable with the array thing. But I keep an open mind...


• For Aerohive Networks, I'm both looking forward to updates and just as much to meeting the likes of Andrew von Nagy (perhaps the most approachable and willing-to-share senior tech guy from any vendor) and his homies. Aerohive just seems to have a different culture, and it'll be nice to spend time in it for a couple of hours. (my latest Network Computing piece on Aerohive is here).


• AirTight Networks will be interesting because they are "new", at least as a wireless access player, in a very competitive market. I have a Network Computing piece on AirTight now running, and also recommend this piece by Man-of-Action and  fellow Field Day Vet Matthew Norwood.  Hearing their story in person will be pretty neat.


• MetaGeek, WildPackets, and FlukeNetworks are all fairly significant players in my wireless world for tools. I've been a MetGeek fan from the days of the original WiSpy, and also frequently use EyePA and InSSIDer for Office (best blog on this one from another fellow delegate, Sam Clements). I'm looking forward to hearing any new announcements from the tools folks (gotta be something in this mix about 11ac) and maybe picking up a tip or two about how to better use the products I already have.


• Finally, Motorola always stokes my interest because they usually have a somewhat unique story and understated approach versus the "aggressive" marketing of other industry players. I'm a fan of many Moto business units (as a radio and Android guy, that's a given), and caught up with the WLAN folks at Interop in Vegas just a couple of months ago to hear their opening 11ac story. I gotta feeling they'll have something new for us.

It'll be a busy week at Wireless Field Day, and my eyes and ears will be open. Standby for updates.

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.

What's Up With Cisco's 5760?

So the new 5760 Controller is here. It's IOS based, it supports 1000 APs, it has 10 Gig interfaces at long last... what's not to love?

Plenty, actually. At least right now.

Cisco's wireless controllers are fairly complicated beasts, especially on large networks that use multiple SSIDs with differing feature sets across each one. With each code release, more features get unleashed, which ups the complexity in exchange for capabilities like RF Groups, application visibility and control, rate limiting, and Clean Air. This complexity pretty much demands that multiple controllers and lots of APs serving huge volumes of clients be managed by the likes of WCS, NCS, Prime NCS,  Prime Infrastructure, Supreme Excellent Unificated Management Suite, or whatever we call Cisco's wireless management platform this week. It can be challenging to stay on top of Cisco's endless parade of new features, capabilities, bugs, interface changes, gaps between CLI/Controller UI/Management UI, licensing changes and other nuances, but that is the nature of the beast. We can do complex, even quirky.

For wireless controller code, we have other challenges. Some versions are to be avoided by even Cisco's recommendations (?) while others are the darlings that we all love. If you want stable code, that's not always the same thing as the latest code. You have to talk to SEs and TAC to find out what code is preferred, and what is the other stuff. (Who uses the other stuff, and why is it even out there?) Then there is the dance between controller code, Prime Infrastructure code, and the Mobility Service Engines. They all tend to have mutual dependencies. Complex, quirky.. again, we can deal with that.

Back to the 5760 Controller.

A controller that supports 1000 APs is aimed at big environments. Big wireless networks tend to require trending, configuration templates, and reporting- you know, management type stuff. This is why we all have PI or one of it's earlier versions. But... the 5760 isn't compatible with current PI (1.3). So, for now you get real-time views of client and AP behavior at best, if you can scrape what you need directly out of the 5760.

In fairness to Cisco, they did include the fact that the 5760 would not be managed by Prime until PI 2.0 in their January 2013 announcement on the new controllers.

At the same time, SEs and sales folks that know their customers' environments arguably have a duty to say "you know... you can't manage this thing in your version of PI- are you sure you want it?" That it was even released "unmanageably" is pretty confusing to me when I contemplate trying to support thousands of clients on a 5760 with no NMS after years of running a big WLAN.

The UI on the controller itself currently looks like a knock-off of the 5508's interface (it actually strikes me as a phishing-kinda cheesy copy of a real UI). And... many of it's features are buried in the CLI, no exposure in the UI.

Speaking of features, AVC was a big thing when it came out earlier on other WLC versions- huge actually. Once you turn it on and start using it, you wonder how you did without it. On the 5760, you won't have to wonder- you will do without it as AVC (and other big-deal features) isn't in this biggest, newest controller.

Nor is preferred happy coexistence with 5508 controllers- unless you are willing to drop your 5508s back to 7.3 code, or wait for new 7.5 to come out sometime in the future. If you are on current 5508 code (7.4 train), you won't seamlessly roam your clients with 5508s.

(I won't even get into the HA thing that was touted when the 5760s were announced, that you can't leverage yet either.)

Final word: today, the 5760 is almost like a real controller that you can't yet properly manage. Things are supposed to get sunnier later in the calendar year for some of the limitations described here, but why didn't Cisco simply wait until they had a more fully baked unit to dazzle us with?

This is just a bit weird. Are IOS and the 1000 AP count supposed to be the sparkly things that distract you from all the warts? Complex and quirky are arguably acceptable. Beta-quality and incomplete are other animals completely. Don't we deserve better by now?

 Am I missing something? Would love to be wrong in my analysis...

Bluesocket Lives, Evolves Into Managed WLAN Services Offering Under ADTRAN

Back in the day, Bluesocket was THE commercial captive portal for wireless networks. As WLAN in general gained broader acceptance and the market widened, Bluesocket also started providing access points and morphed their captive portal appliance into a controller (like the WLAN big guns were starting to use with thin APs.) As this was playing out, Cisco, Aruba, and at the time Meru, were largely dominating the market and Bluesocket  didn't generate a lot of buzz anymore. But- nor were they "over".

My Own Bluesocket History

I have covered Bluesocket through the years for my column in Network Computing, like when the company introduced their initial controller offering, and then their virtual controller option. Network Computing also covered ADTRAN's acquisition of Bluesocket in a piece done by colleague Steve Wexler.

On the personal front, I helped pre-ADTRAN Bluesocket develop a new guest access feature set that perfectly fit the needs of my University when our native Cisco wireless guest option was anemic by comparison. To this day we still  use the Bluesocket portal for guests, and though it may be a bit dated, it still has amazing administrative flexibility and works great for letting guests self-sponsor or be sponsored based on cell phone number as user name. (I made more than one plea for both Bluesocket and ADTRAN to spin this off as a separate product but they didn't bite.)

Bluesocket also donated controllers that I took to Haiti on a humanitarian IT visit  that serve as the functional heart of two networks on University of Haiti campuses that me and my fellow volunteers created.

You could say I have a bit of a soft spot for Bluesocket given my history with the company and their products.  But after the ADTRAN acquisition, the already small player in the WLAN space seemed to get even quieter. But wait...

With their latest announcement, ADTRAN's Bluesocket may be on to bigger things.

Following similar recent announcements by Meraki and PowerCloud, Bluesocket is throwing their hat into into the cloud-managed hosted WLAN ring.

ADTRAN calls their new offering ProCloud, and it hopes to empower channel partners, integrators, and service providers with the ability to provide hosted enterprise-grade WLAN offerings to customers built on established the Bluesocket vWLAN magic-in-the middle.

Also announced are ProStart (installation, service, and training for customers that can't do their own wireless for whatever reason)  and ProCare (customer-selectable maintenance support options.)

See ADTRAN's page on ProCloud,     and Business Wire press release.

Wireless is certainly a competitive landscape to begin with, and the expanding managed WLAN pot is starting to simmer with interesting players jumping in.  Though I get that ADTRAN and competitors see the hosted WLAN thing as an easy service-add for partners that don't yet really offer wireless, I hope those who follow this path all don't lose site of the fact that "easy wireless" doesn't  automatically equal "good wireless" and that proper design and policy are still the cornerstones of successful WLAN.

I wish ADTRAN and my old Bluesocket friends best of luck in their new venture, and I'm sure I'm not the only one who will be following how managed wireless services will impact our industry.

MetaGeek inSSIDer for Office hands on

Playing with my own copy, also provided by MetaGeek- I could do no better than Sam's write up. I encourage you to read it, and have found great value over the last couple of weeks in inSSIDer for Office, even in environments that are "too big" for its intended use. This one is a keeper.

Remembering Back When Wireless Was Edgy

For those younger IT types that grew up with wireless, this quick trip down memory lane might be little more than a yawnfest. But many of us remember when wireless was new, edgy, and fraught with mystique. This piece is for us geezers.

Back in the day (that day being around the late 1990's/2001-2002ish), wireless networking had a whole other vibe. It was a relatively expensive technology, and usually served as an "accessory" to the wired network. Or it provided point-to-point bridging alternatives to leased lines. To "do" wireless, you had to understand networking and have a solid working knowledge of RF. Early access points were way too expensive (and client counts were too thin) to warrant dense deployments so you had to know your stuff when it came to antennas, power settings and how to manually manage a given RF domain.

But aside from "I do wireless for a living" aspects of early Wi-Fi, there was an adventurist culture attached to wireless networking that has arguably faded away (or maybe it's just matured, too?). Some of us got into "war driving", seeking out wireless networks for the pure joy of finding them and seeing what we could learn about them. People did unholy things to Pringles Potato Chip cans and woks and old satellite dish antennas in the name of shooting signals further and hearing them from longer distances (which was part of the overall security threat package to early wireless.) The really geeky among the wireless-curious wrote WEP cracking tools, and the rest of us felt ten feet tall when we actually made those tools work for us to divulge what their owners were trying to protect. Again, it was just a different time, and there was a lot of thrill factor associated with wireless.

So why bring it up now? Depending on how you measure such things, we've had a few generational evolutions from the good folks of 802.11ville, and the connected world has certainly "gone wireless". WiFi is so commonplace, it's no longer just the realm of specialists- though the same skills are still needed as before (and then some) to really pull off "wireless done right" in a complicated world.  Sure, the past has passed.

But, I recently stumbled across something cool on the web that got me a bit nostalgic...

Anyone remember these days? Or these? Being a "radio guy", the notion of creating your own antennas and making signals go long distances is one of the things I've enjoyed through the years. At the same time, today's systems tend to be more micro-cell-ish and so  I had somewhat put this chapter of the Book of Wireless away in my mind's library.

A couple of days ago, I was researching something unrelated when I came across the WiFi Shootout links from the the 2004-2008 time frame. As cheesy as this sounds, it was kinda like looking at a photo album of my children, or at least children that I was quite fond of.

Ah, how far our wireless baby has come, and what a thrill it has been watching it grow up. *Sniff*.

Now be honest- how many of you have a tattoo that looks like 

this?

 

Gimme A Wireless Virtual Client Function, Already!

I'll start this post with two admissions:

1. Of late, I've been interested in the capabilities of 7Signal.

2. Long before 7Signal came to the WLAN space, I've been beating the drum for my WLAN vendor (and all vendors) to deliver what I call virtual client functionality. 

On 7SIgnal, I'm struggling with sticker shock and trying to figure out where it's very cool capabilities stop and where they overlap with tools like Cisco's CleanAir (which isn't cheap either). I am hearing good things about 7Signal from current customers.

About that virtual client thing, it is something 7Signal can do (along with a slew of other cool  things). But by now, I also think this is one of those capabilities that should be built into enterprise WLAN systems. (If I'm not mistaken, Motorola comes closest to having something like this.)

Quick note to vendors- you give us one innovation after another that you think would benefit your clients. Thank you. But how about this one that is long overdue? Your customers that actually run the WLANs of the world would LOVE you for it.

Here are two versions of what I'm looking for:

Simple version:

• I can do all of this through my wireless management system
• I can schedule the function to run at regular intervals and report on it
• I choose one of my installed APs to put into "Virtual Client Mode"
• Through the wire, I can have my Virtual Client connect to each of my SSIDs and exercise the likes of RADIUS, Credential Stores, DHCP/DNS, L2 and L3 paths via ping, traceroute, etc, rate limiting, throughput tests, whatever
• All of this is coordinated in a way that doesn't disrupt the existing client environment

Advanced Version:

• All of the above, PLUS
• I can manually choose any AP within a given range
• I can tell the virtual client to test itself against every AP it can hear within a certain range

You probably get the gist. The payoff- I can "be" in buildings or at sites that I don't have to travel to. The Virtual Client would be a force multiplier, and in many situations would bring far more value than seeing pages upon pages of rogues and interfering signals from neighboring WLANs that I couldn't react to if I wanted (hallmark of many current systems).

I can't believe that I'm about to say this- I get tired of the sometime extreme feature licensing that has come to be all too common in the WLAN industry. But I'd actually pay (a fair price) for GOOD virtual client functionality. 

Am I asking for too much? Are there WLAN vendors beyond 7Signal that are natively doing this that I don't know of?

Why is Aerohive the Only WLAN Vendor On Twitter?

That's right- I don't see any other WLAN vendors on Twitter.

Like really "on" Twitter.

Sure, I see lot's of other WLAN vendors with a Twitter presence. I follow as many as I can. But it's all so much marketing and promotion of webinars and other droll foofah. Not that these communications don't have a place, but there should be so much more... like what Aerohive does.

No, this isn't an Aeorohive suck-up session. They have innovative product and a fresh story that stands for itself. But what also sets Aerohive apart is how their senior tech folks interact  with us geeks on Twitter, in a way that is not only welcome but also sorely needed in a wireless world that grows ever more hyper-complex.

When folks with titles like Chief Wi-Fi Architect, Senior Wi-Fi Architect, and Director of Product management routinely engage customers and non-customers alike on social media, the information exchange is dynamite. This is what all vendors need to be doing. Aerohive has either purposefully or without realizing it empowered their wireless power people to get the message of their solutions out as vigorously as the marketing team does- but even better, they are providing guidance and facilitating discussion on topics that customers of ALL vendors have a stake in. In other words, Folks like Devin, Andrew, and Matthew are also upstanding citizens in a fairly small wireless community, and we all benefit from it.

As we all march towards 802.11ac, more complicated feature sets, unification of everything under the wireless banner, and an immersion in the Sea of Mobility, we need more Twitter-style interactions from vendors' tech folks. Sure, it's risky letting non-marketing employees talk directly to customers and potential customers. But to those of us that read the whitepapers, do the webinars, and visit the vendor booth at the tech shows yet still want more engagement on topics that shape our thoughts and strategies, the more informal interactions we have with the tech folks are invaluable. Sometimes it's technical nuts and bolts stuff, sometimes it's theoretical or contemplative, and sometimes it's silly. But the mutual shaping of perspectives is valuable on many levels.

Come on, wireless vendors, you all have some amazing minds behind closed doors. That's evidenced by the insanely cool products and features that you put out. At the same time, we can't typically reach them- and they can't reach us. It's not your model. You give us division names for Twitter handles like "xxx mobility" and "yyy solutions"... fine, they have value. But we also want to interact with named people on occasion. Like Devin, Andrew, and Matthew. People who not only represent their employers well, but who are passionate about wireless networking and want to share that passion with others.

To balance the risk of letting your tech folks off the reservation a bit,,, you'd get better reads on what matters to those who use and manage wireless networks, we'd better understand why you chose some of your product decisions and feature sets, and powerful relationships at personal levels would get built among WLAN professionals. Yeah, it might feel weird in the beginning, but if Aerohive can pull it off (and quite nicely, I might add), so can you.

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?

Could Cabling For 802.11ac Revolutionize The Low Voltage Industry?

Caution- at first read, the following may seem a bit nutty. I'm OK with that. Let it sink in...

As I wrap another interview with a major wireless vendor, once again I hear that 11ac access points will require two Gigabit uplinks bonded as an Ether Channel to handle all of that high-rate data traffic goodness that comes with the pending WLAN standard. Let's pause for a minute- think about the wiring now in place for your APs. Most of us have a single Gigabit (or Fast Ethernet) run to each of our APs. Which means 11ac is going to MINIMALLY force us to add another wiring run per location, or redesign the whole pricey cable thing from scratch (maybe not so big of a deal in small, modern spaces- but an absolute nightmare in large environments, historic buildings, etc.).

Bottom line- UTP (that's 4-pair network wiring for the uninitiated) will be added for 11ac. Yes, you will be runnin' some wire, Jack. Here's where I want you to wander into the Land of Imagination with me.

Why just run two wires to each AP? Why not run three? If you're running wire anyways, what the heck? I'll bet you're wondering what that third wire is for, huh? It's for emergency LED lighting. Or small Crystal Eye-style CCTV cameras. Or paging/muzak speakers. Or heat detectors. Or femtocells. Or a bunch of other distributed devices that are already part of the Low Voltage landscape- except in my vision, they are now somehow integrated into the access points that are all over the place. So when you device-out a new space, you have a common cable plant and decidedly less pathway and location complexity.

How does this get done, like from the component build perspective? I don't know- I'm not that kind of engineer, So it's easy for me to simply envision it and let someone else say the words that poo poo the notion. In my mind, I take my new 11ac AP out of the box, I attach one of a dozen different low-voltage device modules, connect three wires,and I hang it. Back in the closet, two wires go to my Ethernet switch, and one patches off to an emergency lighting system. Or the third wire also patches into the switch on another VLAN for CCTV. Or for the fire system. Or whatever.

Yes, WLAN makers would have to get cozy with folks in other industries pretty darn quick to come up with this sort of model as 11ac rolls out and we all start planning for the new wiring runs needed for it. Heck, I'll even give 'em until Wave 2 to get it done.

If I'm paying through the nose for new access points AND new wiring, why not get something truly practical, innovative, and cool out of it? Architects/space designers would love it- they tend to hate all of the devices that are mandatory on the walls and ceilings of business environments.

OK, maybe it is a bit nutty. At the same time... maybe there's something to this idea.

So- How Much Interference And How Many Wires Would You Like With Your 802.11ac?

Like many other wireless architects and admins are probably doing right now, I spend a fair amount of thinking time these days on matters surrounding the fast-coming 802.11ac wireless standard. To the WLAN Industry's credit, I don't think the 11ac hype machine has been quite as foolish as was 11n's a few years back, but there is still a lot to sort out here. I recently wrote about the challenge of knowing when to get into the 11ac game, depending on your budget and sense of adventure, but recent conversations with a few industry bigwigs have me scratching my head even more.

Two points to consider beyond just when you move to the next great thing in WLAN:

-  Many of us have invested hundreds or thousands of cable runs in our current wireless networks, each supporting up to 1 Gbps. Where asbestos abatement, new conduit and cable tray, and building permits are required, running cable for an AP can often cost more than the AP itself did- even for market leading Cadillac-grade access points. How drastic does our "investment" in our installed cable change with 11ac? Surely, a single 1 Gig uplink won't be enough for an 11ac AP.


-  There is no free lunch for any technology. To get to the promised data rates of 6.9 Gbps for the second-wave of 11ac, we'll need to use crazy wide channels and reduce the 5 GHz spectrum to potentially the same state of overuse as 2.4 GHz suffers now (even if the FCC burps up more spectrum). And if your ultra-wide 11ac channels happen to be physically near my legacy 11a/n deployment, you'll probably get booted from my list of fake friends on Facebook.

Let's talk about each a bit more.

On the cable thing, if you are familiar with the likes of the TIA-568 cable standards and know folks that run cable for a living, you know that an installed UTP run is a "component". It's the bedrock of the OSI or 5-layer model, and it gets installed methodically and to exacting standards (and often at great expense).

If you had the foresight to provision a robust cable design as part of your 11a/g dense deployment back in the day, you likely didn't have to do much with cable when it came time for 11n. You were able to leverage your investment, and replace an old AP with a new one for the most part, because both a/g and 11n do well on Cat 5E, 6, and 6a cable and Gig uplinks.

Alas, unless we're all being sold snake-oil by the WLAN industry, dual band-11ac APs will need more than 1 Gbps of connectivity (we'll save the related PoE discussion for another time). But how much will we need? A 2 Gbps Ether-channel? A 10 Gbps uplink? Either way, we should be concerned. Most of us can't afford to rebuild our wireless cable plants from scratch. To me, the lofty claims of what 11ac will be able to deliver point to 10 Gbps uplinks, but I'm hearing from a growing cadre of industry voices that the expectation is two 1 Gbps will do OK. Please, someone explain the math behind this, if what we're hearing from 11ac marketers isn't a recipe made of 2 parts truth and 3 parts pure county horse manure.

Regardless of whether we have to run an additional cable and burn an extra switch port per 11ac access point, or get into some sort of 10 Gig PHY that likely doesn't yet exist, the physical layer aspects of second-wave 11ac need to be watched as closely as anything.

On the wide-channel thing: again, we're being told to expect to use 160 MHz channels to get to data rates of 6.9 GHz. Yes, we don't HAVE to use them, and can settle on 80 or 40 MHz channels and lesser data rates. But if we buy into the promise of 11ac, we need to be ready to pull the trigger on 160 at some point. And where we do, each one of our wide channels will be quite unfriendly to any of our 5 GHz neighbors' APs that run in 5 GHz using 20 or 40 MHz channels from 11a or 11n deployments. In multi-tenant environments where lots of companies can see each others' signals strongly, there is a lot to contemplate here. Will we be good neighbors?

Takeaways: I don't have answers. But I do know these issues have to be considered along with all of the huge promises of performance gain that 11ac is supposed to provide that are being bandied about. Between the Wave 1 versus Wave 2 quandaries, and the conversational recklessness of the highest-end claims of 11ac's capabilities that are being spit out by marketers, never have we had to be more on our guards about what a new wireless technology will REALLY mean for large WLANs.

So... When Do You Jump In On 11ac? Like Really?

The blogosphere is awash with speculation on how 802.11ac is going to transform the way we use wireless, and what the new WLAN will do for productivity. It's great stuff, and needs to be talked up. We see early releases of actual 11ac draft product, great whitepapers from the Big Guns, and even better blogs on 11ac from some of the best wireless minds in the industry. If you're not getting a working knowledge of 11ac by now, it's not for lack of available information.

Never has WiFi been more complex, more promising, and more confusing. I don't mean technically confusing; if you're a wireless professional, you'll wrap  your head around the technical side of 802.11ac. Some of my own frequent talking points on 11ac:

• yeah, the standard promises up to 6.9 Gbps data rates. But 11n also promises up to 600, and we'll never see it. Real initial 11ac offerings are still going to be measured at speeds slightly better or even the same as 11n's best


• the 5 GHz-only thing is great for everyone, and will help de-congest the ugly 2.4 GHz band


• early client devices have to be watched- a 3x3 11ac Macbook pro will run circles around a TP-Link 1x1 USB adapter, but they both "are" 11ac. Real client throughputs on 11ac are going to be all over the place


• the Wave 1/Wave 2 thing is really gonna be a weird one for people who have to plan when to jump in, and killer features like Multi-User-MIMO don't materialize until the second wave


• Regardless of how 11ac plays out in the trenches, Ethernet needs to start being more aggressively marginalized. Limited budgets can't support competing access technologies, and mobility will become more of  trump factor when dollars get spent

This brings me back to my question- When do different organizations start migrating to 11ac? This is the part that is confusing.

Talking with Cisco and Aerohive back a few months, the topic of life-cycle came up in relation to 11ac. If you have old gear and have to upgrade, first-wave 11ac might make sense in that you can skip right past 11n. But if you are like me, and have a fairly recent 11n build-out and no real performance pain points, it's just not as easy of a paradigm. Stop-gaps like Cisco's 3600 AP 11ac radio module help bridge the technological generation gap between 11n and 11ac deployments, but at an estimated $500 a pop list price, may not be worth the cost. Upgrading twice to 11ac for the first and second waves is a thorny proposition.

For small environments, lesser AP counts do remove some of the complication. But when you have hundreds or thousands of access points, you can't help but scratch your head when it comes to thoughts of moving to 11ac.

Personally, I am hoping to see a first-wave AP emerge that is somehow upgradeable to a full-fledged second-waver. But I'm also aware of the complexity of putting these things together, and building a 4x4 AP that can "expand" to the likes of 8 streams isn't likely. Also, close monitoring of client device types in use (we're a huge BYOD environment) will be a must while we watch how new 11ac devices trickle in.

For now then, I guess it's still a game of watching and waiting. Hopefully soon we'll see announcements from the WLAN makers that somehow help those of us driving really big WLANs to see a sensible path forward that doesn't include a "buy THIS 11ac AP today, then buy THAT 11ac next year" recommendation.