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.

>>> 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.

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.

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.