Tag Archives: Wi-Fi

Want Great Wi-Fi? Good Luck With That

It ought to be sooooo easy to achieve great Wi-Fi these days. All the makings are there, right? We got the promise of “Gigabit Wireless” and an endless pipeline of screamin’, smokin’ WLAN hardware. Just take a looksee:

ASUS

Man, that all sounds really nice. Then there’s this:

Xirrus fast

Wowsers, that’s fast. And there are plenty of other fast wireless access points out there from every vendor under the sun, and at every price point. The good times are a’ rolling. All you have to do is spend some money, hang up one of these rocket ships, and bask in the glow of Gigabit Wireless connecting your iPad to Netflix at breakneck speeds. Woo woo!

Yeah, right. If only it were that simple.

The truth is, you may NEVER have this kind of great Wi-Fi. Get used to it. The lofty numbers you see on anyone’s glossy are pretty much out of your reach, and there is not thing one that you can do about it, Bucko. Now let’s talk about why.

If great Wi-Fi is defined by the promise of gigantic, outsized throughput numbers, it’s pretty much screwed before product ships. Why? Because most products that do ship tend to end up in The Real World, which happens to be a pretty cruel place for Wi-Fi signals. Even common sense factors that ought to add up to great Wi-Fi frequently don’t… including:

  • Strong Signal
  • Lots of APs
  • 802.11ac
  • Expensive gear with huge specs
  • Professional surveys and installations

It turns out that strong signals can be deceiving (take the ‘a’ and ‘r’ out of bars and you get closer to the truth on signal strength widgets…). You might have a bucket full of signal showing in your client indicator, but a lot of it could be performance-sucking noise or interference in the mix. Or it could truly be great signal, bolted up to a crappy LAN or tiny Internet pipe (say hello to Mr. Bottleneck) which makes the Wi-Fi feel slow.

Lots of APs carefully laid out and functionally coordinated in a High Density environment can be a good thing. Lots of APs without coordination, like from neighboring WLANs can be a disaster. Here we have interference of various sorts, and even rogue devices and Man-in-the-Middle attackers when the environment is AP-fat but untended.

Just because an investment is made in 802.11ac, that doesn’t guarantee you’ll get anywhere near the vendor’s performance promises. A laundry list of parameters has to click before those big numbers are possible (client type and config, spectral cleanliness, no other clients competing for AP, proximity to AP, uplink quality, LAN quality, all can be contributing factors) and chances are you’ll rarely ever come close to what the hype promises.

I’m a firm believer in the adage “you usually get what you pay for” and expensive gear typically fetches a premium because it’s better made with beefier resources (CPU, memory, radio technology, physical construct, feature sets) than the cheaper competition. But even the best gear can’t overcome the laws of physics when the RF space is hostile, and can’t make the WLAN perform any better if your core services like DHCP, NAT, DNS, and routing are flaky.  Then there’s that pesky ISP connection thing again… your “Gigabit Wi-Fi” (which happens to still be half-duplex so a Gig ain’t a Gig to begin with) might be peppy on the local network, but it becomes a 10 Mbps connection if you’re heading off to the Internet on an ISP connection of that size.

Then there’s the critical professional survey and WLAN design. There are absolute advantages to having a professional originate the WLAN design for a business network. But I can design you the prettiest WLAN in the land yet have it’s performance undermined by bad operational policy, an over-zealous NAC system, crappy code, or some new consumer-grade cheesewhiz client that you insist on providing access to.

By now, you get the point- there are a lot of detractors from “great” Wi-Fi. But it does get even worse… with every new kick-ass, performance-promising Wi-Fi standard, we also have a culture of backwards compatibility and unstructured feature sets. Wireless gadgets from 2001 MUST be accommodated on even the latest gear, and BYOD and IoT bring a flood of odd-ball, often ill-conceived consumer-grade gadgetry to the business WLAN that knock the life out of potentially great Wi-Fi. This trend is only getting worse, with no end in sight.

Enough of the Gloom! All is not lost.

Are you sufficiently bummed out yet? Truth be told, little that I’m whining about here is new under the Wi-Fi sun. It’s just that wireless is getting ever more pervasive, and so the deficiencies in the WLAN paradigm that have always been there are magnified- especially as we see promised top-end speeds that approach fairy-tale quality. I offer that great Wi-Fi has little to do with achieving those lofty throughputs, and is actually about a solid experience that works well for end users and results in very, very few trouble tickets.

To get to THIS definition of great Wi-Fi, where things just work so well that users could give a fig what their actual data rates are, you have to look at any environment holistically. Solid WLAN needs excellent design, but also excellent LAN and core services, and a decent pipe to the Internet. Good policy, systematic onboarding, and client education are the icing on the cake. However an individual environment shakes out, great Wi-Fi is as much a well managed state of being as it is an exercise in big numbers.


Please note: Andrew von Nagey is running a very quick survey on WLAN Vendor Selection Criteria through the end of July. Please consider contributing, and sharing what is important to you when WLAN shopping. Thanks!

WiTuners Wants to Optimize Your WLAN

Some days it feels like there’s nothing new under the wireless sun. But every now and then a unique offering wiggles its way onto your radar, and if you’re the curious type you just have to dig a little bit beyond what meets the eye. Recently a Wi-Fi colleague asked me if I’d heard of a startup called WiTuners, which is the impetus for this blog. It turns out, I had not heard of WiTuners. But, being both a crack analyst and master sleuth, I set out to find out more about this intriguing company with the peppy website.

My first question about WiTuners was “are they still in business?” or are they a ghost ship like Nira Wireless seems to have become- having a flashy website and interesting premise but no update announcement in like a bazillion years. I looked at the WiTuners Twitter account and saw little to no activity over the past year and figured that this company must be a mis-fire. But then I put my powers of interrogation to work and asked them via a webform “hey, are you guys still in business?” The reply came quickly and decisively, and my inquiry was met with an inquiry- “Sure we are. Who the hell are you, and why do you ask?” (or something to that effect). And that’s how I came to know Luke Qian, President and CEO of WiTuners (and long time wireless industry veteran). We exchanged a few emails, and eventually connected via telephone so I could learn a bit more about this company that promises to help you optimize the performance of your pricey WLAN. (Luke conceded they’d gotten inattentive to their Twitter thing, and the account has since gotten much more active.)

Please note: I have yet to try WiTuners, and this blog is in no way an endorsement of the capabilities offered by the company. But WiTuners is an interesting story, and I salute anyone who attempts to bring a new performance angle to our important WLAN environments (well, except for these guys.)

So WHAT IS WiTuners about? I can’t say that I yet fully understand the model, but I do grasp large parts of it. When you’re done reading this blog, pop over to this WiTuners page to hear it in their own words. Here’s a stab at it:

  • There are no hardware components, only software
  • Survey and planning utilities are available
  • There is a cloud approach to much of what WiTuners does
  • It’s aimed at both MSPs and enterprises
  • WiTuners doesn’t replace RRM and such, it complements it
  • Optimization can be done on demand or automagically with continuous monitoring
  • You can see proposed optimizations before invoking them after doing a quick audit
  • The framework does not replace NMS, though it does promise certain life-cycle and system monitoring capabilities
  • SNMP figures largely into what goes on here, leveraging standard MIBs to “significantly reduce … costs of WLAN deployment and maintenance while simultaneously…[providing] better WLAN performance.”
  • Is compatible with Cisco, Aruba, Extreme, Ruckus, Moto/Zebra, Juniper, and other modern WLAN systems
  • Optimizations can be proven by reported decreases in channel utilization or by the survey tool with boots on the ground
  • WiTuners aggressively keeps up with code/MIB updates from the vendors they support

This list is far from an eloquent portrayal of the WiTuners model, I realize. I’m providing it more to spark your curiosity in case you’d like to learn more than to act like an expert on the offerings as I’m still trying to wrap my head around the whole thing. WiTuners is a well-funded startup, and Luke is a good ambassador for the company if you get a chance to talk with him (it turns out that Luke and I know some of the same people in the WLAN industry). WiTuners expects to become more visible to target customers later this year.

Whether there is room and demand for the WiTuners optimization services remains to be seen, but anything that promises to make busy WLANs perform better is at least worth hearing out. 

wituners

For me, I’d have to see WiTuners in action before I could pass judgement. But I would be curious to hear what you think about the notion of WiFi system optimization as a service offering. Please leave a comment, and thanks for reading.

In Appreciation of White Box Guest Access

“Guest Access” means different things to different people, and organizations. Certainly if you’re a traveler using hotel or conference Wi-Fi, you have a general set of expectations and desires. If you’re a company or a school, the guest wireless service you provide is likely shaped by organizational policy. And for many of us, the guest environment also tends to act a s a catch-all for client devices that don’t fit on our secure WLANs- a place for “free passes” and MAC exceptions. But the devil is in the details, and I have found finding the right guest access feature set can be difficult.

What you WANT may not be what you can HAVE

Having designed a number of guest environments for large and small networks, I’m always astounded to engage a WLAN vendor on the topic and to find how far their guest offering is from what I’m looking for (more on that in a bit). Worse, seldom do I hear “what are your requirements?” as it tends to be more like “this is what we think everyone should want and accept”.

Simplicity? Fat chance… 

Guest access can also have a lot of moving parts, depending on how it’s implemented. Overall functionality tends to be broken up and scattered across access points, controllers, RADIUS servers, credential stores, web servers, and sometimes switches. It all has to click, or you have problems. And for me, despite the typical complexity of guest services, I still find myself frustrated at features that are not included.

What worked for my environments

Years ago, for my big honkin’ 3,000 AP environment (and our small branches alike), we arrived at a desired feature set that went more or less like this:

  • Our guest SSID would equal a single dedicated guest VLAN
  • 24-hour individual self-sponsoring is a must
  • Alternatively, ANYONE authorized to use our wired or secure wireless network could sponsor a guest
  • For self-sponsoring, a ten-digit mobile number capable of accepting a text must be provided and within seconds a password would be sent
  • For large events, a shared account could be generated
  • All accounts were time limited with role-granularity
  • The system would have easily configurable firewall rules and (generous) rate limiting capabilities
  • On the admin side, we could add MAC exceptions and login-bypass
  • The system would provide NAT to preserve public IP addresses
  • Reporting would be easy, as would user quarantine (rarely used)
  • ALL OF THIS WOULD HAPPEN UNDER ONE HOOD-VIA A SINGLE INTERFACE
  • A programmer would not be needed to stitch it all together
  • Ideally, it would have vendor support (for a number of reasons, open source not desirable)

Going back those several years, our WLAN vendor (Cisco) didn’t come close to being able provide what we wanted. In their defense, nor did any other market leaders at the time. We heard that Colubris Networks had a gateway that might fit the bill, but they had just been bought by HP and try as we might, we couldn’t locate anyone that could talk with us about what we were looking for.

Then we found Bluesocket (now Adtran) and their BSC Controllers. When I first contacted Bluesocket, we came to the mutual realization that they could do about 75% of what I wanted. They weren’t really initially open to developing the self-sponsored texting and “anyone authorized can sponsor a guest” features. So… we thanked each other for our time, and I kept searching. Then a week or so later Bluesocket called back, and said they were game for a bit of development, and saw the value in what would become a feature set that they were able to market to others. They were able to do everything I was looking for in a single, kick-ass box in a matter of hours.

What Bluesocket was able to deliver after actually listening to our requirements has been in play for us for lots of years. We’ve served thousands and thousands of guests with it, along with using it as a mechanism for supporting wonky devices like Google Glass (turn head, spit) that weren’t built with enterprise security support, and so can’t be on the WLANs we’d rather they used.

It’s been absolutely great, and I know of at least three other schools that pursued the same guest access model after experiencing ours.

Looking forward

Our old Bluesocket boxes are getting, well… old. They are appliances, and Adtran seemingly has no desire to virtualize what we need into an OVA or the like. In fact, on newer Adtran wireless products, what we appreciate about the BSC has been moved to Adtran APs that we’ll never buy, so the research for a suitable replacement starts again.

The thing is, we absolutely love what we get out of our aging guest solution, and in a perfect world, I’ll find a similar third-party, one-box bolt-on for our big Cisco WLAN. (I will give Cisco another chance to catch me up on how their native guest access services have improved, but I also know that my requirements are firm). I have also inquired to Adtran one last time about the possibility of somehow preserving this wonderful magic, but the silence thus far is pretty telling.

Which brings me to Meraki. The features I need for my guest environment are pretty much included in the WLAN side of the Meraki product line, and we use it with great success in our Meraki-enabled branch sites. But… to bolt the Meraki capability up to my Cisco WLAN in a way that would replace Bluesocket, I’d need the guest features made available in the Meraki MX security appliances and not just in the AP feature set. I’m hoping to get Meraki’s ear on this anyway, because guest access needs also do tend to pop up on the wired side occasionally, too. Right now, wired guest needs are a gap in the MX.

If Meraki can accommodate, a big MX would snap in nicely where my Bluesocket sits now for guest access. If not, I’ll have to consider things like pfSense, Packetfence and other one-offs that I’d rather not get into after being happy with a commercial solution. Or, I’ll have to rethink our requirements, which would really suck, as they really are what we consider requirements, not just nice-to-haves.

There will obviously be more to follow to this evolution.  I am curious if anyone else is facing a similar situation, and how you might be approaching it.

(Please- I’d love your comments, just don’t blast me with pointless “you should switch to vendor X for your WLAN!” type feedback.) 

Are WLAN Vendors Selling Illegal Jammers?

This won’t take long. Jammers are illegal in the US.jammer1Go here for full page.


Marriott got busted for using jamming, as cited on both pages 1 and 2 of the FCC’s Commission Document.


Marriott’s “jamming” used tools like this, which are part of the WLAN system in use by Marriott (and countless other customers with similar systems by multiple WLAN vendors):

mitigate


Can the average, reasonable person then conclude that what the WLAN industry calls “mitigation” is actually “jamming” as per the FCC?

If so, can the average person also conclude that illegal jamming tools are being being sold by the WLAN industry as part of today’s typical business WLAN system?

I’m not sure what other conclusions can be reached, but I’m no lawyer.

And the latest- from 1/27/15 which seems to confirm. Of course, now we need “commercial” defined.

Ethernet Is Done. It’s Time To Get Serious About Wireless.

Did you happen to see the PR on the Microsoft Surface Pro 3?

Image

Evidently, there is a killer among us. A laptop killer. Laptops have Ethernet ports. If Microsoft’s new $800 assassin kills the laptop, it also kills the laptop’s Ethernet port. Goodbye, Ethernet, we hardly knew ye. Don’t let the door hit you in the ass.

As I look around at the many computing devices I have in my immediate vicinity, I see other models that have already started chipping away at the TRADITIONAL laptop’s tenure, like these:

Image

For the record, that’s an iPad, a Chromebook, a Nexus 7, and a MacBook Air. Nary a one of them has an Ethernet port…

This is where some of you are thinking “Lee, you’re daft. Microsoft is touting the Surface Pro 3 as a laptop killer, not an Ethernet killer”. And though you’re right on that point, there is a nuance here that should be appreciated. 

There’s a certain significance to Microsoft trying to “kill” laptops with it’s new tablet (of course, you need to buy the add-on keyboard if you want to actually put bullets in the gun that will do the killing, in this case). Why? Well, because for the last several computing millennia, Microsoft has gotten fat off of it’s operating systems running on… wait for it…laptops! With the messaging that accompanies the Surface 3, MS is saying “we now commit our client access future to the tablet.” And tablets don’t have Ethernet adapters.

Right now, the client access world (forget about game consoles and the whole IoT malarkey for now, we’re talking “people clients” here) features:

  • Smartphones
  • Tablets
  • Laptops
  • Desktops
  • Thin clients

And not much else. Though desktops and thin clients typically are connected via Ethernet, they certainly don’t have to be as there are a range of wireless adapter options in this space. And if Microsoft fulfills its (rather silly) prophecy of making laptops extinct, the list of devices that come with stock Ethernet capabilities shrinks even further. To me, when I add a keyboard to a Surface 3, it just became a laptop again. But now it’s like the Chromebook and MacBook Air; a laptop with no Ethernet.

None of this rises to the level of epiphany, I realize. At the same time, Microsoft’s message that it’s willing to contribute to the erosion of Ethernet by killing off a class of device that ships with Ethernet adapters in favor of another class that doesn’t is worth holding up to the light and contemplating. For many of us, Ethernet switches have already become glorified VLAN-capable power blocks for our wireless access points. And I personally can’t recall the last time I’ve plugged a laptop into the wall to get on the network.

History will show that The Age of Mobility and The Age of Ethernet For Access absolutely had to have had overlap as technology evolves. But it’s interesting that Microsoft is beating a drum pretty loudly that leads further away from the wire and deeper into wireless.

Whether the Surface Pro 3 sells well or not is almost irrelevant, in my mind. It’s the message that comes with it that means our WLAN environments just got that much more important to network users. This should resonate with network designers, helpdesks, and bean counters alike. 

Interesting times…

 

– 

 

Contemplating Lofty WLAN Things To Come

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

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

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

Yet my head hurts.

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

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

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

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

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

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

 

Mersive’s Solstice- A Nice Alternative To Complicated Presentation Paradigms

UPDATE: https://wirednot.wordpress.com/2014/02/20/so-close-yet-so-far-with-mersives-solstice/ my take on Mersive’s pricing.

Mersive is a company that only recently made it to my radar, but I’m glad they did. I covered their interesting Solstice product for Network Computing back in March ’13, and was so smitten with the promise of what Solstice could do that I nominated them for Best of Interop award consideration. Fast forward to today, and I’m liking Solstice more, as it has gained some polish and added features.

Here’s a quick summary of the problem that Solstice solves, as I see it: since wireless became mainstream, users have wanted to walk into a projector/display-equipped room and quickly mirror the screen on their laptop, tablet, or smartphone to the in-room display for all to see.

Options to accomplish this have been clunky at best. There are ad-hoc wireless connection protocols and thingys that don’t play well in the enterprise for a number of reasons, and that paint the single user that might leverage them into a corner of sorts where they can only project (usually while causing interference to the corporate WLAN) and not be on “the network” at the same time. There are new Wi-Fi direct hardware options that also create odd little islands of radio noise where used. Then there is Bonjour, the limited, dated protocol that requires what I consider to be ugly rejiggering of the LAN/WLAN to make desired display functions work only for select Apple devices.

In other words, there has not been an easy-to-implement, OS and network friendly (and agnostic) way to solve the simple paradigm of letting users show what’s displayed on their devices on the big screen without plugging in.

Back to Mersive and Solstice.

The cats at Mersive are computer scientists and display experts that understand getting pixels where they need to be, and generally don’t give a rip about hardware. Mersive’s software magic powers most of the biggest, most impressive video walls you’re ever likely to see, and they approach the boardroom/classroom display problem differently from all of the clunky alternatives that came before.

If the goals are:

  • Require no additional hardware
  • No network changes and make it work across subnet boundaries (piss off, Bonjour)
  • Let any mainstream OS project to the central room display
  • Don’t let the users in one room hose their neighbor’s display
  • Make it simple to use
  • Keep it affordable

Then Solstice’s latest (1.2.1) hits the mark *almost* perfectly. I have been experimenting with it for a couple of weeks, and like what I see. I have the server software installed on my mocked-up “podium PC”, and free Solstice app software on several Android and iOS mobiles, along with Win 7 and 8 laptops all on different wired and wireless subnets on the same network.

And it just works.

There is the briefest of learning curves, excellent documentation, adequate security, and it all is simply an add-on to what you already have for network topology. Specify the name or IP address of the Display server from the client device, hit “connect”, and display away. Reliably,  for both pictures and video, or for the whole device desktop.

You can get a little fancier with Solstice’s operation, and allow for several users to collaborate by all projecting their content to a common display simultaneously (it is touted as a collaboration tool) and do a few other advanced options that may or may not fit for individual use cases.

Though I am only  kicking the tires right now, I can say that after years of fighting the display paradigm fight, I have found the best weapon I personally have ever seen in Solstice.

Did I mention that you don’t have to touch the network to make it work?

It’s not cheap at list price of $3,500 per server instance, but then again, this is a quality solution that instantly takes care of a number of display headaches.

Oh yeah- and you don’t have to touch the network. Me so happy.

Google and Apple Should Be Giving Network Admins A Cut

It’s a bit curious how at least part of the relationships between device providers and customers are catalyzed by unsung heroes in the equation: wireless network administrators. The contemporary model seems to go like this:

  • Big company teases out an upcoming product release with well placed leaks and sneak-peaks
  • Media fan-boys and fan-girls promote the living bajeezus out of the new devices before and after release, rarely mentioning   their technical shortcomings in any meaningful way
  • Customers fall in love with the new toys; usually the romance starts on the home network
  • Customers high on their new-found gadget love rush into the work environment with their slick new products.  And banking on the accuracy of incomplete articles like this, get frustrated when said gadget doesn’t spring to life on the business network
  • A call goes out to the WLAN admin, who has to decide whether a one-off work-around and likely violation of  organizational policy is in order to get the device in service

Let’s talk about the Chromecast specifically. First and foremost, I love mine. It gets a tremendous amount of use at home. On the work WLAN, it’s not so pretty. Many enterprises disallow ad hoc wireless networks, and the Chromecast needs ad hoc connectivity for at least some of it’s functionality. Then there’s the same issue that Google Glass, early AppleTVs, cheap wireless printers (and not so cheap wireless printers), and a raft of other popular devices that users want to bring to work suffer from; they don’t do any sort of real wireless network security. If you have a mechanism in place to provide MAC exceptions on open or PSK-based network (which isn’t always the case), you can accommodate some of the toys. Unless, like with Bonjour-based devices, mDNS requirements and home-centric network requirements cause you to jump through more hoops on your carefully-designed WLAN. We won’t even get into legacy client chipsets that need data rates that most of us vacated five years ago to gain better performance from our expensive wireless networks.

No matter the exact tech details that lead to tension between consumer devices and business WLANs, there are only two paths to resolution:

  1. Device makers stop screwing over network admins, and bake in compatibility for ALL networks, not just the one behind my cheesy little Linksys router. Or…
  2. Wireless network solutions come with enough sophistication to let toy-toting users get their own limited devices on the air, while also preventing the devices that can use real security from following the toys down the same logical path, while bridging multiple operational realms so the full-blown secure client can interoperate with gadget that has to be handled differently.

Hats’ off to WLAN vendors that are moving their own cheese closer to #2, but that sort of sophistication comes with a lot of cost to the customer and complexity that wouldn’t be required if #1 was simply provided by the Googles and Apples of the world.

As it is, there are a lot of WLAN admins out there right now struggling to accommodate wonderful new devices that we should all be celebrating for what they bring to our users, but we really are getting the short end of the stick. If we can’t accommodate the Chromecast or whatever, we’re viewed as obstructionists that can’t appreciate disruptive new tools. If we can get them going onesy-twoseys, we stand on a slippery slope of support nightmares when the devices misbehave (or lose their settings on power down), or when all of the sudden we’re making MAC exceptions and special ACL/firewall rules all over the place and bypassing our own security perimeter to accommodate the inadequate devices.

So uh, Google and Apple- please pick up a WLAN calendar- the industry is fast entering the 5th generation of WLAN technology. So why are two of the richest companies on the planet still putting out products that can’t go past 2nd generation security?

If you’re not gonna spend the bucks on finishing  development on the products that you absolutely must know are going to find their ways onto our business WLANs, how ’bout putting us WLAN  admins on your payroll? After all, your success frequently comes down to our creativity in addressing your shortcomings. 

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.

I Friggin’ LOVE You, Ruckus ZoneFlex 7055

Image

Why aren’t the other WLAN makers doing this? Why isn’t MY wireless vendor doing this?

I have ran an awful lot of UTP in my day. Those of us who grew up installing UTP before wireless came along know that network wiring isn’t just copper in the wall. When properly installed by trained professionals, premise wiring is as much a component as anything else in the enterprise network environment.

Where solid, well-provisioned cabling systems are getting less used because wireless is fundamentally changing our access habits, we have an easily overlooked investment at the ready. So why do we have to run more wire for wireless access points when we’re often just a few yards away from perpetually unused UTP runs in the wall?

I get that ceiling-mount APs are the preferred methodology where possible. But holy smackers, sometimes getting there takes huge money, new pathway, hazardous materials abatement, and dancing with a labor union or two. In the right setting, an AP designed to leverage existing wall-plate network jacks would be the cat’s ass, baby.

Ruckus gets it, and just announced their sweet new ZoneFlex 7055 access point.

With dual-band 11n, 2×2 MIMO, support for 16 SSIDs, a Gigabit uplink port and four Fast Ethernet ports all powered by 802.3af PoE, the 7055 brings a lot of capability at a list price of $369. Yes- three hundred and sixty-nine dollars… Shut up!

The ZoneFlex 7055 will also power an IP phone, and mesh other locally-powered 7055s that just can’t be located where cable exists, which amounts to a pretty empowering feature set.

You already own the wire, you might as well use it.

And with that, Ruckus hits one of my top-three requests for WLAN makers!