With the recent release of OS X and iOS updates, I have been reminded (again) of how subject we are to the manufacturers of our client devices. In this particular example, I'm contemplating that since the release of iOS 8 and OS X Yosemite, reports of Wi-Fi problems in my organization have skyrocketed. Not that I'm trying to pick on Apple, they just happen to be the current source of trouble. I've had many reports of devices that lose connections, can't connect, or connect and just can't browse anywhere. Things have improved somewhat as updates have been released, but there are still lingering issues.
I bring this up because I have a long-standing roaming problem that seems to have disappeared with the latest iOS update. While I'm pleased that this update has fixed the problem, I don't actually know what actually changed under the hood. The release notes state:
Wi-Fi and Bluetooth fixes
• Fixes an issue where you could be continuously prompted for login credentials
• Addresses an issue where some devices disconnect intermittently from Wi-Fi networks
While there is some promise for issues my users have reported, it certainly doesn't mention anything that seems related to the roaming issue. I'm stuck having to collect debugs and packet captures to try to figure out what actually changed. This is the problem we have with device manufacturers. When an update is released that breaks our users' wireless access in some way, it's difficult to track down where the actual problem lies. It's hard to say if there's a bug in the update, if the update triggered a bug in the wireless system, or if something else completely unrelated to either has somehow snuck in.
I really want to draw a line between the wireless infrastructure and the client so we can lay blame on the client device when a client update breaks the system. However, it is a system that's there for the clients. I have a hard time just pulling a Mordac and saying, "Yeah, your client is broken. Let me know how that works out for you." It's not very good customer service. On the other hand, I'm not sure what else we can do with the opaque nature of these updates when the release notes have a statement like, "improvements to wireless stability." We know something changed, but there's no clue as to what.
Nevertheless, when a device update is released, we are stuck with any problems it creates. Even once most of the big problems are fixed, the little annoying ones that only hit a subset of users will continue. It isn't fun for you or your users when all the Windows and Android devices work fine, but all the Apple devices are having issues. Given that in most organizations 50% or more of the devices are Apple devices, that's a lot of annoyed users if an update is bad. Imagine this scenario in an all wireless office full of Macs!
In the traditional IT environment, at least in theory, updates were tested for your specific environment before they were pushed to the corporate machines. There was a validation system in place. Now the corporate network is BYOD and you never know what you are going to get. Even if the corporate network hasn't embraced BYOD, you probably have a guest network with employee phones and tablets joining, which means more trouble tickets
It would be nice if the vendors providing our clients were more forthcoming about changes and known issues. However, that does not seem to be their desire unless it's a huge issue and they are forced to respond.
Given this lack of transparency from vendors, what can we do? We have to use communities such as Airheads, EDUCAUSE and Twitter to put together our own knowledge bases to figure out what is happening. Unfortunately, the number of people out there who really understand wireless well enough to properly diagnose and articulate what is happening is pretty small, so gathering valid data is difficult. Little real information is available, so there are multiple sites devoted to collecting details about wireless chipsets and implementations. For example, Mike Albano has put together http://clients.mikealbano.com, where he is collecting DFS support details for client devices because the vendors aren't sharing that with us. It has to be gathered from packet captures. Another example is power output. It really shouldn't be necessary to look up every device up in the FCC database and view its certification test results to find its output power, but it is.
Unfortunately, I don't see that there's anything we can do to get the manufacturers of client devices to improve transparency beyond continuing to educate ourselves and our users. The device vendors just won't see the value to them until users cease to be willing to accept mediocrity.