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