Sigh… Stop me if you’ve heard this one- A wireless device maker sells something to an unwitting customer on, shall we say, some stretched truth. The pitch that led to the sale isn’t quite the proverbial pack of lies, but certainly left out key information that may have doomed the deal if the customer had a clue about what questions to ask (or had involved their IT staff before writing the check). A fairly limited-capability WLAN client shows up, and suddenly the network has to flex itself in unsound ways to accommodate devices that arguably shouldn’t have been purchased. Can anyone relate?
Security “Lite”… or is it Security “None”?
Here’s my current problem child.
That’s a time and attendance clock. It’s networked, and it talks to a server out in the cloud. It can use a wired Ethernet connection, or dual-band wireless (we’ll talk about that in a moment). Yay! Cloud! Yay! Wireless! Perfect for just throwing several dozen in and and off they go, because you have a wireless network- it’s a slam dunk, baby!
But it’s not a slam dunk. Because the network it’s likely to land on very well might just be an Enterprise-secure WLAN. That means it doesn’t use living room grade pre-share-based wireless security. Yet the best you will get out of this particular time clock IS living room grade security. It doesn’t support 802.1X authentication or WPA2-Enterprise CCKM encryption.
What happens if you don’t have, and don’t want, a PSK-only Wi-Fi network in a large secure enterprise environment just because someone made a questionable purchase of a WLAN feature-constrained time clock? You don’t have a lot of choices, and the couple that you do have smell and taste bad. Ah well- at least it’s DUAL-BAND WIRELESS.
Yeah… sure it is.
Radios in a Lil’ Faraday Cagey Kinda Thing
I was pleased to hear that the clock was at least an 802.11ac device. Because the environment it will work in does NOT have a PSK network and the clock can’t do enterprise security, it will go on an open guest network with MAC exception so it can bypass the guest gateway (relying on application-layer security to encrypt the data involved). So, I needed the wireless MAC address to set up the exception on the test unit. It was not printed on the clock or packaging, so I opened the device to see if I could find it inside.
I did locate the WLAN adapter’s MAC address, but had to remove the adapter to read it. The clock uses a StarTech USB433WACDB which is in fact dual-band .11ac in spec. But the environment needs to be right for wireless thingies to work to their max performance spec, and things are far from environmentally right in this clock enclosure. The little USB adapter has no external antenna that might help the situation, and sits behind a circuit board and a metal plate inside the clock, with the back of the enclosure and ultimately the wall that the clock will mount on behind it.
Given the RF-unfreiendly location of the adapter inside the clock, I was curious if it would connect at 5 GHz. Here’s where I will admit that my testing was not exactly methodical, but I’ll tell you what I saw and did.
This clock came to life about five feet away from a dual-band access point in the same room, with a couple more dual-band APs beyond other walls but still within range. It first connected on 2.4 GHz. I moved it right next to the AP, and it again connected at 2.4 GHz. I disabled the 2.4 GHz radio on that closest AP, and the clock connected to a farther away AP, using 2.4 GHz. So… it doesn’t look good for “dual band” here. I did not sniff packets to see if the clock is trying in 5 GHz, so I can’t say that maybe it’s not a driver or dodgy band-steering issue. But I can say that in initial testing the clock certainly doesn’t appear to be realistically dual-band despite the adapter spec.
And so it goes…
At the end of the day, this is far from my biggest problem. I’ll hold my nose and get the clocks to work, but it is work calling out the reality that not only are not all wireless clients ready for the business WLAN, sometimes they aren’t even what they claim to be at all in spec because of the way they have been built.
We are collectively in the 5th generation of major Wi-Fi technology with .11ac, with .11ax around the corner. Our WLAN infrastructure systems are advancing with rediculously rich feature sets beefed up with every code release, yet the client device makers seemingly operate on another planet where getting in sync with business WLAN requirements doesn’t seem all that important, given that these clocks are just one very typical example.
Ah well. I realize that nothing told in this narrative is news, but at the same time it needs to be talked about once in a while. Part of that discussion is hoping for better days on the client device front. And part of it is channeling a rant into a story that you can share with others so that they know they are not alone in their own frustrations.
wirednot 