It Takes More Than Wi-Fi Compatibility These Days

Given the maturity of the 802.11 family of wireless standards, you'd think that device manufacturers would have it all worked out by now. It seems reasonable that any Wi-Fi capable device should be able to function on the "typical" wireless network, as long as standards-based client and infrastructure hardware is used. But the devil is always in the details, and for us in the Big WLAN Realm, we continue to battle the frustrations that come when manufacturers do things their own way while implementing security settings, drivers, network adapter default properties, and the like. There are only so many ways to configure a corporate-class WLAN, but some days it feels like those making the devices are either unaware, or uninterested in making their devices play well on the business wireless networks their clients are likely to want to be part of.

Let's look at some examples of the daily user and support frustrations that come from the way manufacturers choose to unleash their wireless products. First- let me provide a bit of my own frame of reference; I work with pretty much all flavors of Microsoft Windows, Apple OS X, recent Ubuntu and Red Hat variants, and a variety of handheld devices and their different operating systems. I have a Palm TX, a couple of iPAQ handhelds, a Droid and iPhone within arms length at work, and support pretty much anything under the sun that does or wants to do wireless. My individual huge WLANs are open, highly secure, and somewhere between the two. I certainly don't know it all, but I'm pretty sure that I see it all in the course of my daily duties. On with my rant.

Apple can be quite frustrating on the big secure network. A look at the data sheet for any modern device from MacBook pro to iPad will show that they all are 802.11 compatible- meaning that these devices adhere to the design parameters of the 802.11 standards. A quick glance at the Wi-Fi alliance directory of Wi-Fi certified products shows that all of Apple's hottest sellers meet the Alliance's interoperability criteria and have earned the Wi-Fi logo. But in the real world, on large networks, Apple wireless products are somewhat notorious for "sticky client" behavior where they hang on to an access point or band for far too long when a better one is available.

Depending on the Apple device or given firmware version, they can have a hard time joining a secure network despite having a verifiable good configuration. Sometimes the device is too good at figuring out the wireless settings a given network needs, and by-passes the fact that you might want to only trust certain authentication servers. And too often, support documentation implies that Apple assumes that none of their devices will ever connect to anything in the Wi-Fi space beyond an Apple Airport. Grrrr.

But Apple is far from alone in throwing us curveballs. My Droid- my beloved Android-based smart phone that I believed was the perfect consumer connectivity platform- also recently turned on me. My device shipped with Android 2.1, and was seemingly infallible. There was not an open or secure network that I couldn't quickly configure for and join, given the right credentials and authorization, and I frequently extolled it's virtues to anyone within earshot. Then came the upgrade to 2.2, and I learned that the developers at Google are also capable of mistakes as I shared feedback from other universities about how 2.2 made a mess of using 802.1x for wireless security. And now we're all waiting for a fix that has no ETA. Again, grrrr.

The examples go on and on. Windows assumes that every 802.1x-based wireless client will join an Active Directory environment, and you need to deselect default options to properly configure non-AD machines. Some iPAQs have enterprise wireless security settings built in, others need a third-party utility, and then there those that don't seem to have the right mix but can be cajoled into working if you ignore the warnings that it's not working (read that again, then take an aspirin for the headache it'll give you). There is a current model Nokia smart-phone that takes almost 40 steps to configure for the same settings that take about six on Android or Apple devices, and the right combination is far from obvious.

On Windows Vista, Windows 7 and Apple OS X, the default IPv6 settings (enabled) frequently cause intermittent wireless connectivity issues for those on IPv4-only WLANs. I have yet to get a wireless printer from any vendor to work with a WPA enterprise environment, and most wireless projectors and other peripheral devices that you'd want to use in business setting only support pre-share based security. Grrr. Grrr. Grrr.

The world is certainly going wireless, but simply putting an IP stack and an antenna in a device doesn't cut it today. Here's hoping that device manufacturers will wake up to the fact that their devices will likely end up in quantity on real, away-from-the-home wireless networks, and put a bit more time into developing their products to improve on enterprise-friendliness.