Jiri Brejcha - Wi-Fi Technical Solutions Architect

iPad Pro Wi-Fi 6E Preference of 5 GHz over 6 GHz

You may have read my 6 GHz discovery test of the new Wi-Fi 6E iPad Pro. This time we ask the “Hey Siri, what is iPad Pro’s favourite band?” question.

Since Apple hasn’t published any documentation that would cover this subject, I configured a tri-band SSID on Catalyst 9136 AP. The SSID name is the same for all 2.4 GHz, 5 GHz and 6 GHz bands. Now, what band does iPad prefer?

Setup

Wi-Fi 6E iPad Pro 11-inch (4th generation) running iPadOS 16.1
Catalyst 9136 Wi-Fi 6E AP
C9800-CL cloud controller running 17.9.2

Max transmit power and 80 MHz wide 5 GHz channel

All 3 bands are enabled with manual Power Level 1 (PL1), which forces the AP to use highest permitted Transmit Power.

In this case, the 6 GHz SSID had the strongest absolute signal strength (RSSI) of the 3 bands.

2.4 GHz enabled, PL1
5 GHz channel 36, 80 MHz wide, PL1
6 GHz channel 5, 80 MHz wide, PL1

The iPad prefers the 5 GHz band and joins using this band.

Reduce transmit power on 5 GHz radio

Let’s use the exact same configuration as above and reduce 5 GHz radio’s transmit power to the lowest, Power Level 8 (PL8). Will that make it prefer 6 GHz?

2.4 GHz enabled, PL1 (RSSI on the iPad -31 dBm)
5 GHz channel 36, 80 MHz wide, PL8 (RSSI on the iPad -55 dBm)
6 GHz channel 5, 80 MHz wide, PL1 – strongest absolute RSSI (RSSI on the iPad -30 dBm)

Yes! The iPad Pro prefers 6 GHz every single time. As you can see, the 6 GHz RSSI is 25 dB stronger than the 5 GHz one, which is why (as far as I can tell).

Narrower 5 GHz channel

We are using the the same configuration as in our very first scenario, but 40 MHz we will reduce 5 GHz channel width to 40 MHz.

2.4 GHz enabled, PL1
5 GHz channel 36, 40 MHz wide, PL1
6 GHz channel 5, 80 MHz wide, PL1

Using narrower 5 GHz channel makes the iPad connect using 6 GHz instead.

Disable 5 GHz radio

This time we disable 5 GHz radio and see if 2.4 GHz or 6 GHz wins. I have high hopes for 6 GHz, you?

2.4 GHz enabled, PL1
5 GHz disabled
6 GHz channel 5, 80 MHz wide, PL1 – strongest absolute RSSI

Indeed, the iPad prefers 6 GHz.

Now, let forcefully shut the 6 GHz radio on the AP. iPad moves to its only available option, the 2.4 GHz radio and happily lives there. We now reenable the 6 GHz radio. The iPad doesn’t automatically jump back to 6 GHz, although 6 GHz has stronger RSSI. When we disabled iPad’s Wi-Fi radio, and reenable, it connected on 6 GHz.

Make 2.4 GHz stronger than 6 GHz and disable 5 GHz

Can we make 2.4 GHz appealing enough to the iPad so that it would prefer it over 6 GHz? Let’s disable 5 GHz radio, keep max transmit power on 2.4 GHz, and reduce 6 GHz transmit power to the lowest Power Level 8 (PL8).

2.4 GHz enabled, PL1
5 GHz disabled
6 GHz channel 5, 80 MHz wide, PL8

The 6 GHz RSSI (-45 dBm) is now weaker than the 2.4 GHz RSSI (-33 dBm) by 12 dB. Is it good enough reason for the iPad to prefer 2.4 GHz?

Not really. It connected on 6 GHz 2 times out of 3. Once it connected on 2.4 GHz.

Summary

When 80 MHz wide 5 GHz channel is used, the iPad prefers 5 GHz. If 5 GHz drops below a certain threshold, and is much weaker than 6 GHz, it then prefers 6 GHz.

It prefers 6 GHz over 40 MHz wide 5 GHz channel.

It doesn’t use 2.4 GHz unless it has no other option.

Please take these tests with a pinch of salt. Ideally I would repeat each of them 10 or so times. Time is of the essence and I only repeated each test 3 times.

Google Pixel 6 Wi-Fi 6E Scanning and 6 GHz SSID Discovery

I’ve done some SSID discovery testing with Apple’s first Wi-Fi 6E capable client, the new iPad Pro. Let’s compare it to Google Pixel 6 smartphone running Android 13.

Same as in the iPad test, we are going to test how well the 6 GHz SSID discovery works and learn a thing or two about Pixel 6.

Discovery with 6 GHz only SSID

Let’s configure Catalyst 9136 AP running 17.9.2 release with 6 GHz only SSID. This is the only SSID this AP broadcasts. There are no 2.4 GHz or 5 GHz SSIDs enabled. They only way for the AP to discovery the SSID is to scan the 6 GHz channels. We refer to these methods as in-band discovery.

Reduced Neighbour Report (RNR), which normally uses 2.4 GHz or 5 GHz beacons to tell the client about 6 GHz SSIDs, is not available to us, because we don’t have any 2.4 GHz or 5 GHz SSIDs on the air.

We are using 80 MHz wide 6 GHz channel 7, which uses primary channel 5. That is a Preferred Scanning Channel (PSC), which means that clients should scan it. Our 6 GHz only SSID is called Cisco 6.

Channel Number allows us to configure the Primary channel

Unfortunately, our Pixel 6 won’t discover the SSID.

But, if we move the AP to channel 23, which uses primary non-Preferred Scanning Channel channel 17, the smartphone discovers Cisco 6 instantly! How bizarre.

I went through the “test all lower 6 GHz channels” exercise and here is the outcome.

When I use these primary channels, Pixel 6 will happily discover the 6 GHz only Cisco 6 SSID: 13, 17, 21, 25, 29, 33, 53, 57, 61, 65, 69, 73, 89

Using these primary channels will make the smartphone not discover it: 1, 5, 9, 37, 41, 45, 49, 77, 81, 85, 93

Here is graphical representation of this. Credits to Keith Parsons and the WLAN Pros team for creating this chart.

For the record, on some channels it took little longer to connect.

Changing channel width to 20 MHz, 40 MHz, or 160 MHz did not help with SSID discovery. Which makes me think that Pixel 6 does not scan these channels at all.

Here is what is happening on the 6 GHz channel when we only enable 6 GHz SSID (with no 2.4 GHz and 5 GHz) on the AP. The AP automatically starts broadcasting FILS frames to help the client discover the 6 GHz SSIDs.

6 GHz only SSID plus 5 GHz only SSID and out-of-band discovery

Now the torture is over and we are calling 5 GHz for help. We will use out-of-band discovery.

By keeping the 6 GHz only SSID enabled, and adding 5 GHz only SSID, we will allow the AP to tell the Pixel 6 about 6 GHz SSIDs in its 5 GHz beacons. There is a Reduced Neighbour Report (RNR) Information Element (IE) included in the 5 GHz (and 2.4 GHz beacons when we use 2.4 GHz), which is the preferred way of discovering 6 GHz.

RNR IE in 5 GHz beacon informing the client about 6 GHz AP

The client failed discovery on primary channel 5. Let’s use that this time and see if RNR fixes discovery for good.

Yes! We see both SSIDs instantly. By enabling 5 GHz (or 2.4 GHz) SSID with the same or different SSID name, Pixel 6 can now discover all channels. This is the preferred way of discovering 6 GHz networks.

RNR IE in 5 GHz beacons helps the client discover 6 GHz SSIDs

Note: When RNR is active, the AP will automatically stop sending FILS frames and there is no way (and no reason, because RNR is a much better method) to force-enable FILS.

Summary

With 6 GHz only SSID (without 2.4 GHz and 5 GHz), Pixel 6 will only discover it using in-band methods if we use primary channels 13, 17, 21, 25, 29, 33, 53, 57, 61, 65, 69, 73, 89.

After enabling 5 GHz (or 2.4 GHz) SSID, Pixel 6 discovers the 6 GHz SSID by looking into the RNR IE in the 5 GHz (or 2.4 GHz) beacon frames.

I am very happy with how well the 6 GHz discovery using 2.4 GHz or 5 GHz beacons works. It definitely is production ready. The test with only one 6 GHz only SSID on the AP is more of a corner case. Most customers I work with, if not all, will also deploy 5 GHz alongside 6 GHz, so there is absolutely nothing to worry about.

Packet capture or it didn’t happen 😉

Download 2.4 GHz an 5 GHz RNR, 6 GHz FILS, and 6 GHz unsolicited probe response packet captures from here.

Download WLAN Pi Profiler report and packet capture of 5 GHz association request, and also 6 GHz association request. We can see client’s capabilities in these frames.

Bonus: Add second 6 GHz SSID and see how it impacts RNR

Same setup as before, we have 5 GHz only SSID Cisco 5 and 6 GHz only SSID Cisco 6, but this time we add an extra 6 GHz only SSID Cisco 66.

Both 6 GHz SSIDs are now advertised to clients using the RNR IE in 5 GHz beacons.

Both 6 GHz SSIDs advertised using RNR IE in 5 GHz beacons

iPad Pro Wi-Fi 6E Scanning and 6 GHz SSID Discovery

iPad Pro 11-inch (4th generation) is the first Apple device to feature Wi-Fi 6E. With the significant amount of new 6 GHz spectrum, active scanning for 6 GHz SSIDs is not practical. Other methods are being used instead. Let’s see how iPad Pro actually does it.

If you are an Android user, I’ve also tested Google Pixel 6 and its 6 GHz discovery here.

Setup

As of writing, iPadOS 16.1 is the latest version and that’s the one I am using for all tests here.

The access points in this test are Catalyst Wireless CW9162I-ROW APs running IOS-XE 17.9.2.

iPad Pro ignores FILS Discovery frames on 6 GHz

I am using 6 GHz only SSID (which doesn’t broadcast on 2.4 GHz and 5 GHz) and 80 MHz wide channels.

Of course, there are Beacon frames sent by the APs every 100 ms or so, and there are FILS Discovery frames sent by my APs every 20 ms. These FILS frames are automatically enabled on Catalyst Wireless APs in DNA persona only when the only SSID enabled on the AP is a 6 GHz one (and there is no 2.4 GHz or 5 GHz SSID). At this point, we need FILS, because at that point FILS is the only method for 6 GHz capable clients to discover 6 GHz networks.

6 GHz beacons every 100 ms and FILS frames every 20 ms

Think of FILS frames as of condensed beacons. They are nearly 4 times smaller than Beacons.

Unfortunately, the iPad completely ignores the FILS frames, and it has no in-band (6 GHz) method of discovering 6 GHz networks. That results in no visibility of the 6 GHz only SSIDs on the iPad, and we can’t connect.

The 6 GHz only “Cisco 6” SSID isn’t being discovered by the iPad

Airport Utility doesn’t show the 6 GHz only SSID either.

iPad Pro only uses Reduced Neighbour Reports (RNR) for discovery

Let’s keep the 6 GHz only SSID Cisco 6 enabled, and also enable a 5 GHz only SSID called Cisco 5.

If we now do a packet capture on one of the active 5 GHz channels, we will see 5 GHz beacons. These beacons contain Reduced Neighbour Report Information Element, which announces to the client device “there is a 6 GHz AP on channel 5”.

RNR in 5 GHz beacons allows the iPad discover the 6 GHz SSID.

iPad sees both the 5 GHz “Cisco 5” and 6 GHz “Cisco 6” SSIDs

Airport Utility also reports both the 5 GHz only and 6 GHz only SSIDs.

By doing a packet capture on 6 GHz channel number 5, we verify that the AP only sends 6 GHz beacons every 100 ms or so. There are no signs of FILS, which is a good thing. By default, FILS is disabled. It only gets automatically enabled when 6 GHz is the only active band on the AP (with no 2.4 GHz and no 5 GHz SSIDs), because it is then the only method for a 6 GHz capable client to discover a 6 GHz AP.

6 GHz beacons without FILS, because we don’t need FILS, we use 5 GHz RNR

Apparently, the iPad only leverages Reduced Neighbour Reports for 6 GHz SSID discovery.

Does RNR included in 2.4 GHz beacons allow the iPad to discover the 6 GHz only SSID?

Andrew McHale made me to lab this up. Thank you, Andrew 😉 The short answer is yes.

This time we only enable 2.4 GHz only SSID and 6 GHz only SSID and verify that we can see them on the air using WLAN Pi in Remote Sensor mode to WiFi Explorer Pro macOS app.

Practically instantly after enabling these, the iPad discovers the 6 GHz one using 2.4 GHz RNR.

Here is the RNR Information Element included in 2.4 GHz beacons.

RNR IE in 2.4 GHz beacons tells the client to look for 6 GHz AP on 6 GHz channel 5

iPad sees both the 2.4 GHz “Cisco 2.4” and 6 GHz “Cisco 6” SSIDs

Summary

The new iPad Pro with Wi-Fi 6E only relies on Reduced Neighbour Reports (RNR) when it comes to discovery of 6 GHz Wi-Fi 6E networks. It will only discover a 6 GHz SSID, if you also enable the same or different SSID name on 5 GHz (and/or 2.4 GHz if needed).

It ignores FILS sent by the AP on its primary 6 GHz channel.

It also ignores unsolicited probe responses sent by the AP on its primary 6 GHz channel if we enable them explicitly.

It doesn’t actively scan 6 GHz to discover new SSIDs.

I recommend you enable a 5 GHz (or 2.4 GHz) SSID, which will allow the iPad to use RNR Information Element included in the 5 GHz (or 2.4 GHz) beacons. It will help other clients like Google Pixel 6, which I’ve tested here, too.

Packet capture or it didn’t happen 😉

Download 2.4 GHz an 5 GHz RNR, 6 GHz FILS, and 6 GHz unsolicited probe response packet captures from here.

Download WLAN Pi Profiler report and packet capture of 5 GHz association request, and also 6 GHz association request. We can see client’s capabilities in these frames.

Correct Elevation and Azimuth Wi-Fi antenna angles in Cisco DNA Center for ceiling-mounted AP

This question comes up and every now and then. So, let’s put it to bed.

If you have a ceiling-mounted internal antenna AP (with built-in antennas), or external antenna AP with dipole antennas (AIR-ANT2524D), or with short dipole antennas (AIR-ANT2535SD), here are the correct Azimuth and Elevation angle settings.

This is how 0° Azimuth and 0° Elevation look like. Plus “squished doughnut” as a bonus to illustrate the coverage pattern 🍩

Azimuth angle does not matter in this case (it does for directional antennas), because these antennas have the same pattern regardless of how you rotate them clockwise or counterclockwise. Simply use the default value of 0°.
Elevation angle is 0° for this orientation.

Cisco DNA Center Azimuth and Elevation configuration

Special thanks to Christian Gauer for his help.

Will 20 MHz capable Wi-Fi client join an SSID using 80 MHz wide channel?

Let’s take this “Back to the basics” question and test things out.

So, we have this 20 MHz capable Windows 11 Wi-Fi client and we want to see what happens when it attempts to join an SSID that uses 80 MHz wide channel. Will it associate? Will it fail?

Here is my client with Intel AX201 adapter forced to only support 20 MHz wide 5 GHz channel.

My AP uses 80 MHz channel width.

Let’s verify the settings from a Mac. Yes, the AP broadcasts 80 MHz wide “lab5” SSID with primary channel 36.

Finally, what happens if the client device is only capable of 20 MHz channel width? As you can see, it will happily join using Primary channel 36.

More capable client devices that support 80 MHz channel width will benefit from the 4 bonded channels and use the 80 MHz channel in its entirety.

Portable Catalyst 9136 Wi-Fi 6E demo powered by Zyxel 802.3bt power injector

I am building a portable Wi-fi 6E demo in a box solution. What do I use for that?

PoE powered FriendlyElec’s NanoPi R5S runs iperf3 server. Here a quick iperf3 performance review of this little, 2.5 GbE, and mighty Linux box.

My Catalyst 9800-CL controller is hosted on a cloud, so I don’t need any hardware for that. Finally, my Catalyst 9136 Wi-Fi 6E AP is powered by a Catalyst 3560CX 10 Gigabit Ethernet multigigabit switch.

Catalyst 9136 is Cisco’s premium AP with all the bells and whistles including hexa-radio architecture and built-in environmental sensors for smart building use cases. It requires an 802.3bt/UPOE power source to enable 6 GHz radio in full performance 4×4 MIMO mode. The switch I use supports 802.3at/PoE+, which is great, but 6 GHz radio downshifts to 2×2. And that’s where an 802.3bt power injector comes to the rescue.

Zyxel 5G PoE++ Injector

Cisco’s 5 GbE 802.11bt power injector (AIR-PWRINJ7=) is now available, and that’s my go to option for production use.

Since the Cisco injector isn’t widely available yet, I decided to test this Zyxel one. It provides 802.3bt power and allows the AP to run in full power and full 4×4 6 GHz radio mode with no compromise.

Do I like power injectors in production?

Absolutely not! Ideally you should design for 802.3bt/UPOE switches to power all your new APs via PoE.

It allows you to:

easily, centrally and remotely monitor how much power the APs use
enable/disable power on a port to bounce an AP
leverage redundant Platinum-rated power supplies for the AC to DC power conversion
manage the solution with ease – just think how difficult it is to manage more than 1 power injector, the number of AC power sockets, and what happens when someone disconnects the injector?

I still use C3650 UPOE mGig switch in my lab. Catalysts 9300 and 9400 the best choice these days.

UPOE and mGig capable C3650 providing full power to the AP

Final look

Carrying a full-size switch is not really an option for me, because small form factor is my main goal. So a power injector works best for me. But if I could I would love to use a compact 802.3bt switch.

Are you wondering if the PoE splitter connected to my iperf3 server (the little black box with 3 Ethernet interfaces) actually negotiated 2.5 Gbps Full duplex with the switch? Yes, it did. But keep in mind that the PoE splitter is technically only rated for 1 GbE. So use as short patch cable as possible and ideally CAT6.

Still few things to tidy up and perhaps I could build this into a nice Pelican case

OWC Thunderbolt 3 to 10 Gbps Ethernet Adapter – The Fastest Multigigabit Adapter For Your Mac

When it comes to the fastest copper Ethernet adapter for your Mac, you have only 2 options:

If your other half approves, get yourself an M1 Mac Mini with built-in 10 GbE port. It doesn’t get much better than this.
Or you can consider an add-on 10 Gigabit Ethernet Thunderbolt 3 adapter for your current Mac.

We will focus on the latter today.

Thunderbolt 3, not USB

While the USB-C connector might temp you to connect these adapters to a standard USB port, these adapters don’t support USB protocol. They use Thunderbolt 3 and they happen to use the same USB-C connector as USB. That’s the only thing USB and Thunderbolt have in common. Before you order one of these adapters, double-check that your computer supports Thunderbolt 3. That should be most new MacBooks, Mac Minis, Intel NUCs and similar platforms.

Which 10 GbE adapter shall I buy?

I tested two of these Thunderbolt 10 GbE adapters. One made by Sabrent, and the other by OWC. They both look alike, both perform very well, both get quite warm, and both work out of the box on macOS. Yes, no driver installation required on your part on macOS! 🎉

Mainly because of the loose Sabrent cable issue explained below, I recommend the OWC adapter. It comes with great documentation, and even the Thunderbolt cable itself is thicker and feels premium.

OWC Thunderbolt 3 10G Ethernet Adapter OWCTB3ADP10GBE

From throughput perspective, I personally tested it up to 3 Gbps down and 3.3 Gbps up using iperf3 with default settings. The limitation is on my part, I just don’t have another 10 GbE computer I could test against.

I’ve seen reports of:

between 7 Gbps and 8.74 Gbps uplink speeds with default iperf3 settings
9.5 Gbps uplink iperf3 speeds with Jumbo frames enabled

When I reviewed 2.5 GbE and 5 GbE adapters, this setup has become my reference I ran all iperf3 tests against.

It supports Jumbo frames including a custom MTU setting

VLAN tagging

The OWC adapter also supports VLAN tagging. Here is my Trunk port with Native VLAN 129:

Trunk port configured on the access switch

Let’s tag all traffic with VLAN 130:

Verify that we are indeed in VLAN 130:

VLAN 130 is being used instead of the Native VLAN 129

If you only want to use VLAN 130 (without touching the Native VLAN 129), you can disable the adapter itself. VLAN 130 virtual interface will stay up and forward traffic.

Disable the Native VLAN 129 and only use VLAN 130 for all traffic

Sabrent Thunderbolt 3 to 10 Gbps Ethernet Adapter TH-S3EA

I won’t go into the detail, but my main challenge with the Sabrent adapter was its loose Thunderbolt cable. The connection between the USB-C socket on the adapter and the USB-C connector on the Thunderbolt cable is very loose and practically pulls out just by the tension of the cable itself. It might have been just my unit, but I can’t recommend it.

Sabrent Thunderbolt 3 to 10Gbps Ethernet Adapter on the left

It almost felt like it needed some hot glue to keep the Thunderbolt cable connected

What about Windows and Linux support?

I tested the Sabrent adapter on Windows 10. It required a Sabrent driver installation and then it worked just fine. I would assume the same for the OWC.

I don’t have a Linux computer with a Thunderbolt port, so I can’t share anything on that front.

How to mount WLAN Pi to a tripod

You might remember me saying something about designing a 3D printed WLAN Pi tripod mount. Yes, that was the plan… until I found a much better solution, which I had already owned.

Why tripod mounted? Well, occasionally I work on an outdoor Wi-Fi project. WLAN Pi can be a really useful for throughput testing, or it can share your phone’s cellular internet connectivity with your access point. This is really useful in cloud-managed surveys, labs, and projects.

Tern RidePocket Handlebar Bag

I present to you this small, well designed, and weatherproof Tern RidePocket bag. It is a fantastic bicycle bag, and as good bag for your WLAN Pi. You can purchase one in many countries around the globe and made by a big bike company, which is here to stay.

WLAN Pi in the Tern RidePocket bag on a tripod

WLAN Pi powered by PoE using PoE splitter

If you wanted to, you can battery power your Pi. Just add a battery pack of your choice.

Outdoor surveys involve all kinds of weather, and that’s where this rain cover becomes really useful.

What makes it work better than other or cheaper bags? It mounts securely, and does not slide down the tripod thanks to its strap coated with a layer of anti-slip rubber material.

Anti-slip material on the strap and a hook towards the top

If you prefer a Raspberry Pi 4, or WLAN Pi Community Edition based on Raspberry Pi 4, it fits in this bag too including a PoE splitter with little effort.

Lenlun Bike bag set

Do you need to interact with your WLAN Pi while it is mounted? No problem. I’ve tested a handful of other bags and Lenlun Bike bag set is the best fit. It allows you to see the display and press buttons while it protects everything stored inside.

Attachment to tripod is not as clean as Tern

Finally, after you are done working, these bags can happily carry your keys, phone, battery pack, and wallet.