This morning, I tweeted the message below without much context:
With the 280 character limit of Twitter (hard to believe it used to be 140), sometimes it’s difficult to fully express an idea or the context behind it and instead of trying to create a messy, multi-threaded tweet, I just left it there as food for thought. But here on my blog, I can elaborate further on why this situation stood out to me and how it applies to you, the reader, who’s most likely in an IT related role.
This is not meant to be a bash post or anything like that, but more of a “public service announcement” for anyone who might have to deal with this scenario in the future and cannot find a ton of info online; I know I couldn’t.
I was on a work-related call today regarding a project to bring in a vendor that was going to leverage the 5 GHz Wi-Fi channels that we typically leave out of our channel plans for their own autonomous Wi-Fi network to provide connectivity for their client devices. Those unused channels are in the UNII-2e (or UNII-2C for the initiated) band, specifically 112-132. That’s not a small amount of spectrum that we give up, but we do it as part of our partnership with vendors who need the spectrum in order to provide their own networks for their solutions. I know what you’re thinking… We picked those specific channels because traditionally they’ve been known to have more problems than others with DFS events, but I can neither confirm nor deny that! Those channels were selected before my time here so I’ll claim plausible deniability on that one :). Anyway, nothing new for us there and back to the story…
It was noted on the call that Meraki does not allow channels 116-132 to be used and my antennas (wireless pun) immediately went up. “Hold up, flag on the play! That CAN’T be right. Are you sure?” is what I was thinking to myself. Admittedly, while I have worked on some Meraki tasks and troubleshot a few things since starting here, I have not completely delved into the world of Meraki to say much, if anything, definitively about their solution. So I kept my mouth shut and scrambled to log into our Meraki dashboard, trying to confirm what was said by someone who wasn’t even on our team; surely they had to be mistaken. And then I saw it…
I’ve been doing less and less Python development since moving to a new company back in June. At my previous employer, I worked on Python command-line scripts and a custom-built web app fairly often that assisted with daily, monotonous tasks as well as troubleshooting. I really enjoyed the process of learning more about Python and developing tools that helped not just myself, but also my team.
So you’ve got that fancy new AP from VendorX with all the speeds and feeds, including multi-gigabit capability. Are you taking advantage of the increased speeds? How do you keep track of all your APs and the speeds they are linked up at? I found this interesting tidbit about LLDP when I was doing some investigation on an infrastructure insight that RUCKUS Analytics provides…
I was recently asked to do a predictive design for a warehouse. Sounds innocent enough, except the floor plan was a picture of the floor plan made in an Excel spreadsheet. Up until this point, I had never dealt with something like this, but it immediately reminded me of this exchange on Twitter between Eduard Petrov and Vasco Costa a day or two before receiving it:
Client fingerprinting, in my opinion, is one of those features that many people don’t think about until they either need it, want it, or it’s broken. It’s not as sexy as other Wi-Fi security related topics such as 802.1X or micro segmentation and it’s certainly not going to prevent a client from operating correctly on the network if it’s not available (or can it?). However, it does help provide insight into your Wi-Fi client base which can be valuable in terms of knowing what device or devices are popular and making sure your Wi-Fi supports them well. Additionally, it is possible to tie access controls to clients by their device type which can affect what they are able to do on the network. With that said, it’s probably worth knowing how client devices are identified from their manufacturer down to the OS version and more importantly, the methods your Wi-Fi vendor uses to identify them. In this post, I’m going to discuss how client fingerprinting is done in general, how RUCKUS does it, and how one method of fingerprinting that we use today is changing due to security concerns.
No, I’m not quitting my career as an IT professional to start a R&B group, but hopefully the title of my blog post captured your attention enough to get you here. Now let me explain.
Earlier this year, RUCKUS released SmartZone (SZ) 6.0. There were many new features and improvements like a completely redesigned web UI for example, but another minor feature made the cut as well: AP Hostname Advertisement