Incompatible power injector with Cisco Catalyst Wireless CW9166 Wi-Fi access point

Just a very quick reminder that if you power your CW AP using an incompatible 802.3at power injector, you will likely see the AP successfully boot up, but it disables its radios few seconds later. The result is no SSID put on the air.

What to look for in the logs?

If you console or SSH into the AP, you will see this error message. Followed by radio interfaces going down.

set_sys_cond_state: condition critical state 4
condition critical state 4 error message

That’s it. Use officially supported injectors, and save yourself from the trouble I ran into 😊

Convert Cisco Catalyst Wireless access point to Meraki cloud-managed mode

We have already converted a Cisco Meraki access point to Catalyst/DNA mode the other week.

Access point conversion from Catalyst/DNA mode (managed by Catalyst 9800 controller) to Meraki mode allows you to add a Catalyst Wireless AP to Cisco Meraki Dashboard, and fully monitor, and fully manage it from there.

Convert Catalyst/DNA AP to Meraki mode

Order the AP in the right mode

Order your access points in the right mode out of the box, and don’t worry about conversion. That’s the “-MR” SKU for cloud-management/SaaS model. If you wish to manage the APs by a Catalyst 9800 controller, simply find the right access point SKU and regulatory domain based on your coutry using this tool and reach out to your favourite Cisco Partner or distributor for a quote.

What do we need?

  • Catalyst Wireless CW9162I, CW9164I, CW9166I, CW9166D1, or CW9163E access point joined to a Catalyst 9800 series controller (hardware appliance, cloud instance, or virtual machine)
  • Cisco Meraki MR access point license

Let’s start the conversion

1. Make sure the access points you want to convert have successfully joined the Catalyst 9800 controller. Head over to Configuration > Wireless > Migrate to Meraki Management Mode.

Migrate to Meraki Management Mode

2. Select one or more APs you wish to convert and click the Migrate to Meraki Management Mode button.

Select APs

3. Wait for validation to complete. Click Next.

Validate that the AP can be converted

4. Tick Agree and continue and click Yes.

Take a deep breath and kick-start the process

5. Conversion has now finished. Note that each AP has a Cisco Serial Number and Meraki Serial Number. Copy the Meraki Serial Number.

Conversion has finished

6. While you are doing that, the AP rebooted and started the Meraki image.

AP has left the controller and is about to establish connectivity to Dashboard after reboot

During the boot process, the AP logs a message about the mode change.

Reset reason – AP converted to Meraki mode

And you will no longer have access to its Console port. If you connect a console cable, <Meraki> output will appear with no option to type any commands.

Console port output after conversion

7. Copy the Meraki Serial Number and log in to Cisco Meraki Dashboard. Open Organization > Configure > Inventory. Click Add devices, and paste the Meraki Serial Number of the AP.

Inventory
Add the AP by entering its Meraki Serial Number

8. From now on, the AP now behaves like any other Meraki cloud-managed access point. All monitoring and management features of the Dashboards are available. If you ever change your mind, and wish to convert it back to Catalyst/DNA mode, here is my step-by-step guide.

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.

6 GHz only SSID is the only one enabled
Channel Number allows us to configure the Primary channel

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

No signs of 6 GHz

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.

6 GHz SSID discovered

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.

5 GHz only and 6 GHz only SSIDs enabled

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.

iPad Pro with Wi-Fi 6E

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.

3 APs in lower 6 GHz in the UK

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.

FILS frames are 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.

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

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.

iPad sees both the 5 GHz “Cisco 5” and 6 GHz “Cisco 6” 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.

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.

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.

6 GHz 2×2 MIMO setup powered by PoE+

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