Author Archives: Keith Miller

About Keith Miller

Keith Miller is currently a network engineer for a consulting company on a military base in South Carolina, USA. He was promoted from help-desk technician to network engineer in June of 2010 and has been doing it ever since. Networking is definitely his passion, however he enjoys most things that are IT or technology related. Keith is always looking for ways to improve myself and network with his peers in this industry so feel free to contact him if you’d like to exchange ideas! Twitter: @packetologist

My adventures with 6 GHz and my Pixel 6a phone

I’ve always been someone who has advocated for buying your own tools to test and troubleshoot things. This applied when I was working primarily as a network engineer focused on route/switch, datacenter, and security technologies and it still applies today, now that I’m primarily focused on wireless. In my experience, some companies and/or management are better than others with regards to buying tools for their employees so you cannot always rely on them for help. Investing in yourself and your learning is critical in my opinion so don’t let that deter you. It’s also nice to be able to take those tools with you if you decide to move on to “greener pastures” one day. Unfortunately, not all tools are what I consider to be affordable for the average person, especially if they are somewhat frugal like myself. Just do the best you can, when you can.

With that said, I have purchased a handful of devices over the last 3 years since transitioning into wireless that have helped me do my job much more effectively. The first was probably my iPad Pro 11”. It has helped me with several wireless related tasks, but probably the biggest one was performing surveys with Ekahau. I had never done a survey with a laptop and tray prior to buying it and to be honest, I never wanted to try it either; I was fortunate enough that Ekahau brought this functionality to the iPad just as I was getting into Wi-Fi back in 2019. The second was probably my 2 WLAN Pis (NEO 2s). I acquired one of them through attending WLPC which came out of my own pockets so I consider that paid for by myself and the other one I built via the parts list that the WLANPi team published. I gave my third one away to my friend Dale Tyler at the last WLPC I attended in 2020 because he didn’t have one at the time and “sharing is caring”. 2 was more than enough for what I needed anyway. But those little guys have been so invaluable to me for testing all sorts of things and not just Wi-Fi. The third device that I purchased for myself was an Android device. It started with the Google Pixel 5a last summer when I was working for a vendor and needed to test certain behaviors on multiple platforms. As someone who is fully submerged into the Apple ecosystem, it really helps to have the ability to test, troubleshoot, and understand how things work on the other popular platforms like Android and Windows, especially if your user base is also using them. It can be difficult to know what’s happening if you cannot see it for yourself. So if you are typically team Apple, do yourself a favor and get a “cheap” Android and/or Windows device. If you are team Android and/or Windows, get a “cheap” Apple device. The investment will pay dividends in the long run, I promise.

Getting to the heart of this post, this past summer, Google released the Pixel 6a which included support for 6E. There was a pretty decent trade-in deal available at the time that only required me to come out of pocket like $180 dollars or so, case and screen protector included. I couldn’t pass that up because I knew I would eventually need something to test 6 GHz with and Apple was seemingly dragging their feet (sidenote: Apple eventually released their first 6E supported device, the iPad Pros in Oct 2022). The only problem was, I didn’t have any APs that actually supported 6 GHz and my employer hadn’t yet deployed anything in my area that I could go test with. Which leads me to a few weeks ago. I finally got my hands on a 6 GHz capable AP, the Mist AP45. Here’s what I’ve discovered so far with my Pixel 6a:

For my initial testing, I setup a 6 GHz only SSID. I was pretty frustrated because the phone seemingly never discovered it. It would never be presented in the list of found networks and I couldn’t see it in any of the Wi-Fi scanning applications I was using like Analiti and Aruba Utilities. However, there was a reason for that and I’ll come back to it later.

I then setup a 5 GHz SSID with the hopes that the 6a would be able to discover the 6 GHz only SSID through reduced neighbor reports (RNRs). I’m sure most of you are aware of what RNRs are at this point, but essentially they can be leveraged by an AP to assist 6 GHz capable clients in discovering 6 GHz WLANs faster since there are so many channels and clients can only scan on the preferred scanning channels (PSCs) anyway. It saves the client time and probably some battery life too. Still, no dice. Luckily, I also have a Windows laptop supplied to me by work and have the awesome tool developed by my good friend Josh Schmelzle, lswifi installed. It has the ability to scan beacons and display whether or not RNRs are being advertised with the command lswifi -rnr. And they were! So what gives? Well, after mentioning it a few times in the Wi-Fi Pros Slack and seeing several replies from people stating that they have had no problems with their 6 GHz capable Pixels (6, 7, 7 Pro), I figured it was something I was doing wrong with the configuration of the Mist AP.

Note: lswifi shows “Same SSID” as “Yes” even though the SSIDs were named differently. After speaking with Josh, we believe this is a bug within Mist because the hash for the Short SSID is wrong. I have reached out to them about it. See below:

>>> hex(binascii.crc32(b'Mist-5GHz-Only'))
'0xcb4f27d9'

>>> hex(binascii.crc32(b'Mist-6GHz-Only'))
'0xf2c21b1c'

Btw, if you don’t have a Windows-based device, Adrian Granados’ Wi-Fi Explorer Pro can also show you RNRs:

I started by upgrading the Mist AP to the latest version of 0.12.x on the off chance that there were some bugs present. Still, no improvements. While working with Josh, I realized I had setup the 6 GHz WLAN with higher data rates enabled, starting with 24 Mbps as mandatory and everything else above it as supported; this was done in an effort to mimic our home office high-density environments. To simplify the testing, I reverted the data rate configuration to defaults which enabled all data rates. We had success after that, but it ended up not being related and was more correlation, not causation.

What I’ve found is that the phone somewhat more consistently discovers the 6 GHz only SSID under 2 circumstances:

  1. If I cycle the Wi-Fi NIC on the phone, the 6 GHz only SSID typically shows up almost immediately and will stick around for a scan cycle or two before it disappears again. This works MOST of the time.
  2. If I completely disconnect from my home network (2.4/5 GHz only) which I hadn’t done prior to my more rigorous testing yesterday and today, the 6 GHz only SSID will show up more often, but it does still disappear at times. I’m assuming this is because the phone is either scanning different channels during each cyle or possibly not scanning the 6 GHz band at all. Even still, if I have another SSID broadcasted on another band (e.g. 5 GHz) where RNRs are prsent, things do not dramatically improve so is the device just ignoring the RNRs? And finally, if I’m connected to my home network, it will almost never show up which is what I had been experiencing up until this point.
6 GHz only SSID is missing when I switched from one app to the Settings app
Approximately 2 minutes later, with no changes to the configuration or position of the phone, the 6 GHz only SSID finally appears

At this point, I’m assuming there’s something in the drivers that deprioritizes scanning of the 6 GHz network and when the Wi-Fi NIC is cycled or you aren’t connected to any network at all, the phone goes into more of a “fight or flight mode” where it will scan all bands looking for any available networks to join. Just a working theory, I have nothing to back that up other than the behaviors I’m seeing.

Also, despite what Jiri found in his excellent blog post, my Pixel 6a can discover a 6 GHz only SSID on channel 37.

So what about WLANs that are dual band, meaning something like the same SSID on 2.4/6GHz or 5/6 GHz? Will the SSID be more easily discovered? Will the client device connect to the SSID on the 6 GHz band or one of the other bands? Will it eventually roam to 6 GHz if it doesn’t connect to it initially? I’m glad you asked…

Well, it’s more of the same actually. Sometimes the SSID in 6 GHz is discovered and a lot of times, it isn’t. In terms of connecting to the SSID, the 6a seems to always initially connect on 5 GHz and it takes FOREVER (30+ minutes) to roam. I had trouble getting the RSSI to be stronger from the 6a’s point of view on the 6 GHz band despite turning the 5 GHz radio down to 5dBm and turning the 6 GHz radio up to 17 dBm (actually was set to 21 dBm, but it appears it was limited by the sytem), but putting it approximately 2 feet away from the AP seemed to help.

Pixel 6a took 30 minutes to roam to 6 GHz
RSSI fairly similar between bands despite power settings being drastically different

Moral of this story… Like many have said already, 6 GHz is still a mess and it will probably be that way for some time. Your mileage can and probably will vary and unfortunately, I only have one 6 GHz capable client at this time to test with which makes it even harder to understand what’s going on at times… I haven’t been around Wi-Fi long enough to deal with all the pains of new standards and bands outside of 11ax which really didn’t seem to have much issues besides Intel NICs initially not being able to see the 11ax enabled SSIDs in the air, but from how the industry vets put it, this appears to be par for the course. With that said, it really pays to do testing with as many devices as you can get your hands on, especially if you expect them to be in your environment(s). You don’t want to start troubleshooting these types of issues AFTER the clients have already shown up on your networks! I’ll continue to test as time goes on and if anything changes, I’ll add updates to the bottom of this post.

I’m curious… What has been your experience with 6 GHz device testing so far? Especially with Android devices since they can be so different from one device manufacturer to the next… Feel free to reach out to me directly on the Wi-Fi Pros Slack (packetologist), Twitter (@packetologist), or my e-mail (thepacketologist [at] gmail [dot] com)

Additional information: The Pixel 6a was running Android 13, December 2022 security update at the time of these tests.

Correlation != Causation

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.

Continue reading

PSA: Meraki APs don’t support TDWR channels, period.

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.

Background:

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…

Continue reading

Building a power conversion tool in Python

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.

Continue reading

LLDP and multi-gig speeds


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…

Continue reading