At IE, our wireless practice engineers often are called on to troubleshoot a network that’s gone awry, for some unknown or unforeseen reason, resulting in a negative impact to the business. The WLAN has been run through multiple support calls and RF surveys to show that good RF signal exists and the RF cell is stable. Vendor support centers may have been contacted, but with little to no actual onsite visibility, the vendor online support engineer has no real way to identify the issue. Quite often of late, this has been the result of a change to the network that may’ve been intended to improve the behavior of one client’s device at the cost of older legacy devices on the network. One, or multiples of, new Institute of Electrical and Electronics Engineers (IEEE) standards have been engaged and legacy client devices are suffering. These standards are varietal configurations of 802.11r, k, v, and w. I will briefly describe what each of these IEEE roaming and protection standards is and how they could potentially cause issues with your WLAN client devices.

I took some time off one Friday morning and went fishing on Lake Murray. Despite being off, I had a couple meetings that I needed to attend, one of which required me to participate via Cisco WebEx on my laptop. I wasn’t about to let a little bit of water stop me from participating, nor was I about to let one meeting stop me from enjoying a day out on my boat. So, I grabbed my Cradlepoint IBR1100 router with Verizon SIM card and loaded it on the boat along with laptop, tackle box, and fishing rods. We pushed off before 8:00 AM; it was a beautiful peaceful morning on the lake. I plugged the router’s vehicle power adapter into the boat’s 12v power socket and had the wireless network up and running within 3 minutes. I popped open the laptop, looked up fishing reports, checked the weather, and streamed music thru the IBR until my meetings started. Once it was time for my meeting, I jumped on WebEx, screen-shared, and participated in the meeting as if I was in my office. All the while the kids fished and had a great time. When my meetings ended, I put the laptop away and went back to fishing. A great morning on the lake, productive and fun.

Update: as of July 2024 we have successfully implemented these updates. Stay tuned I'll release an updated report soon! By now, just about everyone has heard of the coming 5G standard for mobile devices like phones and tablets. Interoperability and the coexistence of 5G in the enterprise space with existing WiFi technology has been a serious concern for some who fear 5G LTE will mark the end of WiFi as it encroaches on unlicensed spectrum. I don’t see it that way. For over a decade I’ve believed that the true mobility sweet spot will be realized when we have complete interoperability between cellular-based devices and WiFi. Allowing enterprises to offer 5G throughout their network on licensed spaces, owned and operated by the carriers, allows them to easily transition latency and security sensitive applications on and off of their networks. The interoperability of 5G and WiFi is not only convenient but necessary to provide adequate data backhaul for the increasing bandwidth demands of data-hungry end-users.

We received quite a few interesting looks at last year’s OctoberTekfest, when we unveiled the KegBot and Hack for Beer challenge. A couple of hours into the challenge, we developed a crowd of folks gathered around the booth. Some people came to watch and cheer on their friends, while others took notes with hopes of decreasing the amount of time it took to “Pwn Beer.” The most interesting thing that happened, at least from my perspective, was that all of the folks that came to the booth experienced all of the excitement and frustration associated with executing a hack to a networked system. Many folks took note that some of the methods used to hack the KegBot, leveraged vulnerabilities and configuration issues that could have been easily mitigated. Several conversations started that examined the ideas of: What if the firewall placement changed? or What if the admin’s workstation had been patched, or not left on or unlocked? This is the true value in the whole demonstration. The process forces us to think about the issues that allowed the hack to happen in the first place. The beauty of the demonstration is that it was conducted in a controlled environment, no real data was ever at risk, and we all learned a lot.

Welcome to KegBot, Part 2! If you read my last blog, you know that we’ve set out to build the most awesome IoT device ever; an automated beer dispenser we call the KegBot! If you didn’t get a chance to read it, you can get up to speed on the first several hurdles we tackeled here.

The face of something very familiar is changing. Within a few years you may not recognize the “face” of your data center because many of the technologies you’ve relied on for the last 5-10 years are being disrupted.