Wi-Fi Vendor – Detect vendor of a Wi-Fi access point with just your iPhone or iPad

Many of us walk into buildings and we immediately start looking for access points 🙃 Often times, the access points are not visibly installed. But how can you tell what vendor is your favourite coffee shop using, or what APs did your customer deploy?

Now, would it be cool if you could use your iPhone or iPad to find out what vendor is your customer, public venue, favourite football club, or train provider using?

Wi-Fi Vendor iOS Shortcut

I created a Shortcut for iOS, which does exactly that.

Simply connect to a Wi-Fi network and open the shortcut. We will automatically populate the input field with the BSSID of the AP you are currently connected to:

Simply connect to a Wi-Fi network and tap on the Wi-Fi Vendor icon

If you don’t want to connect to an AP, use Airport Utility to get the BSSID (aka the “wireless MAC address” of the AP) of the access points around you, and let Wi-Fi Vendor shortcut do its magic:

Scan for BSSIDs around you and detect vendor

Or you can even use the good old Copy & Paste method. Let’s say you saved the OUI to your Notes app. Copy it to clipboard and paste into Wi-Fi Vendor:

Benefits of this solution

  • iPhone or iPad is all you need. No need to open your laptop or other professional Wi-Fi tool.
  • It is free, and driven by your coffee donations 😉☕️
  • All data stays on your iPhone and iPad. No data, not even the BSSID, is sent to a cloud service.
  • Our OUI <-> Vendor database is Wi-Fi centric, open to additions of the new records by Wi-Fi professionals, it has extra entries from vendor documentation, and BSSIDs captured in the field
  • It is community-driven and customisable. Contribute new OUIs, or fork our repository and create your own tool.
  • For Cisco Meraki APs, I use an active detection method – more about this below

Cisco Meraki active vendor detection method

When there is no match based on the access point’s OUI, Wi-Fi Vendor shortcut performs an active check. Make sure you are connected to the AP, then open Wi-Fi Vendor. It will attempt to browse to the Local Status Page of the AP and if it find Cisco Meraki logo in the source code, that’s a match.

Supported iOS releases

I’ve tested Wi-Fi Vendor on these devices. Use iOS 17 or newer for the best results and all features.

  • iPad Air 2, iOS 15.7.7 – no Cisco Meraki active check, doesn’t detect BSSID you are currently connected to
  • iPhone SE 2nd gen, iOS 16.6 – no Cisco Meraki active check, doesn’t detect BSSID you are currently connected to
  • iPhone SE 2nd generation, iOS 17.0 – all features are supported
  • iPhone SE 3rd generation, iOS 17.0 – all features are supported

Download and install Wi-Fi Vendor iOS Shortcut

It takes less than a minute to install.

Follow this video guide to 🔽 download the latest version from my GitHub to your iPhone or iPad.

Install Wi-Fi Vendor shortcut

The mandatory boring bit

This tool is provided as is. If you spot anything that needs to be fixed, let us know, or even better submit a Pull Request including the fix. Blame Jiri for anything that needs to be fixed, not Cisco 😉

Cisco DART extension cable for C-ANT Wi-Fi antennas and Catalyst 9130AXE access points

Cisco’s Catalyst 9130AXE access point (the external antenna model) doesn’t have any antennas built-in by design. It uses a DART connector with 8 RF lines and 16 digital lines. They carry the RF signals and allow communication between the AP and antenna.

All new C-ANT9101, C-ANT9102 and C-ANT9103 antennas connect natively using their directly-attached DART connector to the Catalyst 9130AXE access point. It significantly simplifies the deployment process, allows the AP to automatically detect the antenna model, type and gain, and it doesn’t allow any room for installation errors like loose RP-TNC connectors or swapped antenna RF ports.

Here is an example of the new bell antenna C-ANT9102 with directly-attached DART connector.

And here is one connected to the C9130AXE-E access point.

Now, if your scenario requires the antenna to be installed further away from the access point (inside of a freezer for example) there is a 3-feet DART extension cable for that sold by Cisco.

The part number is AIR-CAB003-D8-D8=.

It has 90-degree 8-port plug on one side and straight 8-port jack on the other.

Azimuth and Elevation angles of external Wi-Fi antennas on Cisco DNA Center maps

Orientation of Wi-Fi access point with external antenna(s) on Cisco DNA Center maps is represented by 2 key attributes.

Azimuth tells us how many degrees we rotated the antenna around its vertical axis. It ranges from 0 to 360.

Elevation represents downtilt of the main lobe relative to horizon. It ranges from -90 to 90. Horizon equals to Elevation 0. If the antenna’s downtilt is 30° down, Elevation is -30. The minus sign tells us that the antenna is pointed downwards.

Downtilt of 30° equals to Elevation -30

Antenna shooting above the horizon, which is not very common, would have positive (larger than 0) Elevation value.

We are going to focus exclusively on access points with external antennas in this post. If you are deploying internal antenna AP or AP with dipole antennas, here are the correct settings for you.

Everything in this post applies to all Cisco’s directional antennas. To name a few, C-ANT9103, C-ANT9104, AIR-ANT2566D4M-R, AIR-ANT2566P4W-R, AIR-ANT2513P4M-N.

Enough theory. Pictures are worth a thousand of words.

We are going to use use Cisco’s AIR-ANT2566P4W-R, which has a nicely squished pattern and changes to its orientation are very visual.

Wall-mounted external antenna

By default DNA Center sets APs with external antennas to Azimuth 0 and Elevation 0. Elevation 0 means that the antenna is wall-mounted (downtilt 0°) and its main lobe shoots parallel to horizon.

Let’s assume perfectly wall-mounted antennas with no downtilt at all in the examples below. That way we don’t need to touch the Elevation setting at all. All we need to do is to adjust the Azimuth angle depending on which wall the antenna is mounted on.

Wall-mounted antenna shooting towards the right

Azimuth 0 and Elevation 0 is the default setting for external antennas. It represents a perfectly wall-mounted antenna (that’s what Elevation 0 means) shooting in the right hand direction (that’s what Azimuth 0 does). The main lobe travels parallel to the floor.

Azimuth 0, Elevation 0
Azimuth 0 and Elevation 0

On the floor plan, it is mounted on the ‘left wall’ of the room, shooting towards the right.

Wall-mounted antenna shooting towards the bottom of the map

Now, what if you installed the antenna on a wall, but it points towards the bottom of the map (I avoid the south as it is not true south) this time?

Azimuth 90 and Elevation 0

We rotated the antenna clockwise around it vertical axis by 90 degrees. There is Azimuth for that, so we will increase Azimuth by 90. The final setting is Azimuth 90 and Elevation 0.

The antenna appears as mounted on the ‘top wall’ of the room shooting towards the bottom of our floor plan.

Wall-mounted antenna shooting towards the left

We have now rotated the antenna by another 90 degrees clockwise. That results in Azimuth 180 and Elevation 0.

Azimuth 180 and Elevation 0

It is installed on the right wall pointed towards the left of our floor plan.

Wall-mounted antenna shooting towards the top of the map

Finally, if the antenna is mounted on the ‘bottom wall’ and it points towards the top of our floor plan, that is another 90-degree increment, and results in Azimuth 270 and Elevation 0.

Azimuth 270, Elevation 0

Hopefully, there are no surprises there?

If your antenna uses a different orientation, simply drag the blue Azimuth arrow and point it wherever the antenna’s main lobe is shooting towards.

Ceiling-mounted antenna

Ceiling-mounted antenna shooting towards the floor

Antenna mounted to the ceiling shooting towards the floor has downtilt of 90°. We simply set Elevation to -90. Don’t miss the minus sign.

This is how Azimuth 0 (antenna cables on the left, top side of the antenna on the right) and Elevation -90 looks like.

Azimuth 0, Elevation -90

The irregular ‘oval-ish’ pattern of this patch antenna is very obvious on the map. It kisses the top and the bottom of the floor plan.

My antenna is ceiling-mounted but it is rotated?!

To rotate the antenna on the ceiling by 90° clockwise, we just need to increment Azimuth.

Azimuth 90, Elevation -90

Azimuth 90, Elevation -90

This time the coverage area stretches from left to right, because we rotated the antenna by 90 degrees.

Azimuth 180, Elevation -90

Azimuth 180, Elevation -90

Azimuth 270, Elevation -90

Antenna cables point towards the bottom of the map, which is yet another 90-degree increment. It is still perfectly ceiling-mounted (that’s Elevation -90).

Azimuth 270, Elevation -90

Let’s practise

Now, let’s apply the theory.

What Azimuth and Elevation would you configure on C-ANT9103 antenna connected to Catalyst 9130 AP mounted using AP-BRACKET-9 bracket on the ‘top wall’ (don’t let the perspective of the photo confuse you) of the floor plan with 30-degree downtilt?

Azimuth 90, Elevation -30

The antenna is mounted on the top wall shooting to the bottom of the map. That translates to Azimuth 90. It is wall-mounted, which normally means Elevation 0, but it is tilted 30° down. So, we subtract 30 from Elevation. And here we go, that’s Elevation -30.

Generate a Wi-Fi QR code offline without relying on random web services

There are many online services that allow you to create a Wi-Fi QR code for free. The problem is that you are giving your SSID and your password (passphrase) in plain text to a random company on the internet. What happens if they sell or leak these?

There is a better way

You can easily create a QR code from your Terminal. The tool will guide you through the process.

wifi_qrcode_generator in action

What do we need?

I am using a Mac (it should work the same way on Windows) and we will install wifi_qrcode_generator, which is a Python package. No Python skills needed.

Install the tool

Open macOS Terminal and execute:

pip install wifi-qrcode-generator

Add Python to your PATH variable

You now might be able to start the tool by typing wifi-qrcode-generator in Terminal. If it fails, you might need to add Python to your PATH variable.

  1. Edit this zsh file: nano ~/.zshrc
  2. Add a new line and modify the Python version part if needed: export PATH="$HOME/Library/Python/3.9/bin:$PATH"
  3. Save the file using Control+o and exit using Control+x.

Generate a Wi-Fi QR code the easy way

Execute wifi-qrcode-generator in Terminal and follow the instructions.

wifi_qrcode_generator tool in action

If you decide to save it as PNG, the file will save to your home folder.

Generated QR code sample

Scan the QR code with the Camera app on your phone and it will save this new Wi-fi profile and it will attempt to join.

Or use 4 lines of Python to generate the QR code

Alternatively, you can use few lines of Python to generate the code.

import wifi_qrcode_generator.generator
qr_code = wifi_qrcode_generator.generator.wifi_qrcode(ssid='Jiri', hidden=False, authentication_type='WPA', password='SuperSecretP@$$w0rd')

The outcome is the exact same.

New Site Survey mode on Cisco Catalyst Wi-Fi 6E access points

Cisco Catalyst Wi-Fi 6E access points in DNA persona support a new Site Survey mode. It allows you to perform AP-on-a-stick survey, it comes with a fresh web interface, and it supports 6 GHz. This new mode is included in the Lightweight access point software image.

Unlike the Embedded Wireless Controller (EWC) mode, which was available on previous generation of APs, this new Site Survey mode doesn’t require any extra software image download or reflash of the AP.

CW9162 access point in Site Survey mode

What do we need

  • Either of C9136I, CW9166I, CW9164I and CW9162I APs in DNA persona (controller-managed AP running Lightweight software image) works. We are going to use CW9162I-ROW DNA persona AP running 17.9.3 or newer release.
  • Console cable connected to the USB port of your laptop and the RJ45 Console port of the AP
  • PoE injector, PoE-capable battery pack, or switch with PoE support. To power CW916x APs, PoE+ (802.3af) is sufficient. You will need UPOE (802.3bt) to leverage full radio capability of C9136I.

Why the 17.9.3 or newer release

Why am I insisting on 17.9.3 or newer release? There was an issue, which prevented Site Survey mode from working on ROW regulatory domain APs used in the UK. The AP simply won’t accept the GB country code, and it won’t enable 5 GHz and 6 GHz radios. This is fixed in 17.9.3.

How to upgrade the AP to 17.9.3

Simply join the AP to an existing Catalyst 9800 controller running 17.9.3 release. During the join process, the AP will automatically upgrade its software to 17.9.3 to match your controller’s release.

If you don’t have a controller by hand, download and spin up C9800-CL 17.9.3 virtual machine controller on your favourite hypervisor or cloud service and join the AP to it.

How to activate and use the Site Survey mode

  1. Console into the Lightweight AP. Switch the AP to Site Survey mode and wait for it to reload:

    ap-type site-survey

    Note: Mode change to Site Survey mode erases the AP settings and resets Console port credentials to cisco/Cisco.

  2. After it reloads, ROW domain AP will only broadcast 2.4 GHz survey SSID. No 5 GHz. No 6 GHz. That’s because we haven’t configured any country code yet and it doesn’t know what regulatory to follow. Note the Country NONE value.

  3. If you are using ROW domain AP, configure country code using this command using Console connection and reload:

    configure ap country-code GB

  4. The AP will boot up and broadcast the survey SSID on all 3 bands.

  5. Connect to the survey SSID wirelessly. It is an open SSID, no passphrase needed.

  6. Access the access point’s web interface on Default credentials are admin/admin. Click OK, and change default credentials.

  7. Using the web UI, customise the RF settings to fit your survey needs. Default 6 GHz channel setting is set to Auto, which results in channel 1, which is not a Preferred Scanning Channel (PSC).

    Let’s change it to channel 5 or other PSC channel.

  8. That’s it. Take the AP with you to site and enjoy the survey. When you PoE power it, it will automatically start in the Site Survey mode with your customised settings.

    To scan 6 GHz spectrum, I use WiFi Explorer Pro with WLAN Pi M4 as a remote sensor. It has a built-in tri-band Wi-Fi adapter.
Custom 6 GHz channel and Tx power
Site survey SSID enabled on all 3 bands

New LED pattern in Site Survey mode

During boot, the LED flashes blue.

After the AP successfully starts Site Survey mode, the LED flashes red and green. This is a normal Site Survey mode pattern, and absolutely nothing to worry about.

LED flashes red and green in Site Survey mode

How long does a Site Survey AP take to boot?

From plugging the Ethernet cable in to seeing the SSIDs on the air, it takes about 3-4 minutes. DFS channels take 4 minutes or so, other bands come up faster.

Does internet connectivity work?

Yes, it does. If you connect AP’s Ethernet port to infrastructure that provides internet, wireless clients connected to the AP in Site Survey mode get internet access too.

The Ethernet interface of the AP gets an IP address via DHCP from the existing infrastructure. The AP has its own DHCP scope enabled on its survey SSID. It then NATs traffic coming from wireless clients to the wired network.

Lanyard accessory for WLAN Pi R4

Some of you have asked about the lanyard I use with my WLAN Pi R4. So here is how to make yours.

What does it do?

It allows you to ‘wear’ the R4 while keeping your hands free. You can perform 2.4 GHz, 5 GHz or 6 GHz scanning, spectrum analysis, or packet capture from your Mac.

WLAN Pi R4 with 6 GHz Wi-Fi adapter and 6 GHz spectrum analyser as a remote sensor to WiFi Explorer Pro
Wearable WLAN Pi R4

What parts do I need?

My goal is to use a standard conference lanyard. Use your favourite one or order a custom one with your name or company name. In the UK, I use greencotton on eBay and they have been great.

WLAN Pi R4 lanyard, D rings and bolts

After many iterations, I discovered that these D ring picture holders work best. They are made of metal, of perfect size and readily available. So there is no reason to overengineer this or reinvent the wheel.

Finally, we need two M2.5 x 5 mm bolts to attach the D rings to the bottom of the Waveshare heatsink.

D rings attached to WLAN Pi R4
Lanyard attached to WLAN Pi R4

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?


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


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.

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.


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