Sometimes, the biggest problem with the network is its very existence. Anytime something breaks, the fingers start pointing at the network. Database stopped responding? It must be the network. Client can’t access the Internet? Must be the network. Never mind that what the client can’t access is just their home page and everything else is working…
The problem isn’t so much that the network exists, but that it exists and most users, and even most IT pros, don’t understand it. Now we take that complex system that people already have a difficult time understanding and replace the simple Cat5 cable with… Magic? Arthur C. Clarke once wrote that any sufficiently advanced technology is indistinguishable from magic. For many people, wireless is a magical black box. Actually, it’s usually an opaque white box, but that’s beside the point. Things happen in it, but they can’t be seen and they are not easily understood. The explanations for how it works, or more likely why it doesn’t work, generally involve lots of vague hand waving motions and end with either blaming the client or the network, depending on which side you are on.
Now when something breaks and there’s nothing obviously wrong with the device people trust, it’s logical (from their perspective) to blame the thing they don’t understand. It’s known that it needs to be working for them to do what they want, so that must be what’s broken.
You can read the rest of my thoughts on this on the Aruba Airheads Community.
There’s a joke, “How hard can it be not to install wires?” (See this Dilbert comic) However, it’s a good question, so let’s think through this a bit.
Let’s say you are deploying a new wireless network. Maybe you had it thrown at you already purchased and delivered. You just get to implement it. What fun! Maybe it’s “just” an upgrade, so can’t you just swap things out?
Things you need to consider: What model are the APs? Do you have enough for coverage? More importantly, what about capacity?
To read the reast of this article, check it out over on the Aruba Airheads Community.
Back at the beginning of October, I had the opportunity to be a delegate to Wireless Field Day 8. The Aruba Networks presentation was very impressive and they also were kind enough to provide all the delegates with a number of nifty items, including some Aruba Networks LS-BT1 BLE location beacons.
If you aren’t familiar with Bluetooth Low Energy (BLE), it’s an extension to the Bluetooth standard that allows for low power communications. This is the standard that provides the basis to create beacons and allows them to operate for multiple years using standard button cell batteries. Beacons are not the only devices out there that use BLE for communication, but those are outside the scope of the rest of this post, which you can continue reading on the Aruba Airheads Community.
Below is the video of Aruba’s location presentation, featuring Kiyu Kubo, Director of the Meridian Group at Aruba Networks.
Aruba Networks Meridian Stadium Applications with Kiyo Kubo from Stephen Foskett on Vimeo.
Kiyo Kubo, Director of Meridian Group, discusses the use of Aruba Networks Meridian location technology at Levi's Stadium. Use of beacons is demonstrated and security around the technology is also discussed. Recorded at Wireless Field Day 8 on October 1, 2015. For more information, please visit http://ArubaNetworks.com/ or http://TechFieldDay.com/event/wfd8/.
Are you captive in this portal?
I like to monitor the IETF mailing lists for new Internet RFCs that are published. Many of these are cryptic things like RFC 7675, Session Traversal Utilities for NAT (STUN) Usage for Consent Freshness. I’m not sure I even know what that means. There are some that do make sense to me. Most recently RFC 7710, Captive-Portal Identification Using DHCP or Router Advertisements (RAs) was published and caught my attention.
To find out why, you’ll have to read the rest at this post on the Airheads Community. :)
I wrote another post over at the Aruba Airheads Community. Here’s a taste…
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…
If you’d like to read the rest of it, you can check it out at the Airheads Technology Blog.
I wrote a blog post with my thoughts about the impact of wide channels and SNR when dealing with sticky clients. I discovered some interesting things about how things really work during the course of writing it. Check it out over at the Aruba Airheads Community.
Some complain that the FCC made a mistake in their Marriott ruling and the resulting Enforcement advisory against Wi-Fi blocking. Those who disagree say an organization should be able to control the RF environment on their own property. While that sounds reasonable at first, can we even develop the rules to allow that?
You can read the rest of this post over at the Aruba Airheads Technology Blog.