This is by no means an exhaustive explanation, but a quick overview that was two slides of a Wi-Fi talk I gave at the Wisconsin State Telecommunications Association’s 2024 Fall Conference.

People over a certain age (and nostalgia nerds) will appreciate this video from 1976 that aired for a decade afterwards.

The Sausage Factory

Let’s use the development of 802.11be as our example. From this page, the 802.11be committee posted their updates. Here’s the table they show:

I found this interesting, to be sure, but what are all the acronyms? I’d never learned those in my technical Wi-Fi experience. Note the use of the indefinite article (“a”) versus the definite article (“the”) below. Here are the acronyms defined:

• PAR: Project Authorization Request
  • Document that outlines the need for a new project or standard
• TG: Task Group (IEEE 802.11be)
  • A subgroup within a working group focused on a specific task or project
• WG: Working Group (IEEE 802.11)
  • A group of experts working on the development of a standard
• SA: Standards Association (IEEE 802)
  • A body within IEEE that oversees the standards development process
• EC: Executive Committee (IEEE)
  • The governing body that manages the activities of the Standards Association
• RevCom: Review Committee
  • The committee that evaluates readiness for final approval
• SASB: Standards Activities Support Branch
  • The division that provides support for standardization activities; acts like the “quality control board” and final authority that ensures an IEEE standard is legitimately developed, consensus-based, and ready to be officially published.

Now that we have an example and a basis for understanding, take a look at 802.11bn (which will likely be called Wi-Fi 8). From this page:

As I write this (April 21, 2025), it looks like they may be running a bit behind. Releasing 802.11bn only 4 years after 802.11be was a pretty aggressive timeline, so it will probably take a bit longer for the final standard. The Wi-Fi Alliance will probably run ahead a little bit anyway, as they did with certifying Wi-Fi 7 in January of 2024 when it was September before the final 802.11be was through all the committees.

I hope you enjoyed this small peek behind the curtain. Note that I am not involved in any of this, besides being a watchful eye (and having an IEEE login).

Seamless roaming. The dream. Many articles and presentations have been given on this topic.

Brief aside: The three main roaming-related IEEE 802.11 task groups are: k, r, and v (my pneumatic device was “I krave seamless roaming” (forgive the spelling of “crave”). Officially once the 4-year rollup* is done, these task group’s letters are no longer relevant, except in the hearts and minds of nerds and writers of data sheets. If we’re talking about what was produced by the 802.11ac task group, for example, the standard is now officially called “VHT” (Very High Throughput). If we’re talking Wi-Fi Alliance certifications (aka, the branded route), we could say Wi-Fi 5^†. As of this writing (mid-April, 2025), 802.11-2024 still isn’t out, which is why I picked 802.11ac instead of ax, which is not in 802.11-2020.

* Every four(ish) years, the IEEE 802.11 committee puts all completed task groups into a document with the title in the format 802.11-YYYY
† Technically its proper name is “Wi-Fi CERTIFIED ac” but “Wi-Fi 5” is acceptable

That was a major digression, but I’m famous for that in person, so I bring my conversational style into my posts.

Layer 1 and 2 Roaming

Rather than k/r/v, these standards are officially referred to as:

• k ➔ RRM (Radio Resource Management)
• r ➔ FT (Fast BSS Transition)
• v ➔ WNM (Wireless Network Management)

802.11-2020 is nice enough to tell us on page 10 that that’s what these task groups became:

Let’s assume that all APs and STAs in our ESS support these well, and we can roam between APs all with sub-50ms, our FaceTime calls with grandma are blip-free as we wander throughout the house that has 3 access points.

In a home environment, typically the “router” or “RG” (see my post on those) acts as the Wi-Fi controller that the mesh satellites talk to. When the user walks between APs, the new AP the user is connecting to starts outputting Ethernet frames from the STA’s MAC address onto the wired distribution network. Then all the relevant switches in the path (which may be many, just one, or be the switch built into the router’s LAN) now know the MAC address is on a new port/switch.

Layer 3 Roaming

But let’s picture an enterprise environment with 2,500 (two thousand five hundred) APs spread across the campus. We’ll have two controllers in two on-campus data centers: West and East. Let’s assume that they are using CAPWAP with tunneling of data traffic back to the controllers.

The 1,400 APs on the wlan-west controller drop users onto:

• VLAN 180 – 198.18.0.0/21
• VLAN 181 – 198.18.8.0/21
• VLAN 182 – 198.18.16.0/21

The 1,00 APs on the wlan-east controller drop users onto:

• VLAN 190 – 198.19.0.0/21
• VLAN 191 – 198.19.8/21
• VLAN 192 – 198.19.16.0/21

How can we have seamless roaming if the STA walks from an AP controlled by wlan-west to an AP controlled by wlan-east? Let’s say the user had IP address 198.18.4.5, which is associated with VLAN 180. Now his traffic is being CAPWAP tunneled from the new AP back to wlan-east, where VLAN 180 doesn’t exist and 198.18.4.5 is not a local subnet.

Does the new AP/controller give up and hope the user re-requests a DHCP address, then assigns it something in, say, the 198.19.16.0/21 range? Well, that’s certainly one way to go, but it will be extremely disruptive (on the order of seconds), as all sessions would have to drop and be re-established, etc.

Instead, intelligent controllers will solve this issue with more tunneling. The user’s original controller becomes the anchor (though different terminology may be used by different vendors), then the foreign (new) controller literally sends every Ethernet frame back to the original controller, which continues to drop the user’s traffic off on VLAN 180. The details of how this is done (i.e., which protocol(s) are used) varies between vendors. Even Cisco AireOS differs from IOS on its 9800 controllers. But the method is generally the same between vendors, and it’s table stakes for any large deployment.

If you’ve noticed from my posts, I’m most familiar with AireOS. I do realize that it’s long in the tooth, but from a conceptual level, it still preaches from the grave.

I happen to work for a company that makes Wi-Fi RGs. “What’s an RG?” you might ask. The short answer is that it’s similar to a consumer Wi-Fi router, plus extra “carrier grade” capabilities (and a carrier grade certification*). For the longer answer, refer to my post entitled APs, Routers, and RGs.

* BBF hasn’t released their 802.11be certification as of this writing

“Who is Calix?” you might ask (you have a lot of questions!). It’s one of those billion dollar companies that serve a particular industry, and if you’re not part of that industry, you may have never heard of it. In Calix’s case, our customers are exclusively ISPs (aka “carriers,” hence the “carrier grade” thing above). We make hardware and software that goes into central offices, telecommunications cabinets, and subscriber homes and businesses. We also have our Calix Cloud platform to manage all of that. Our Wi-Fi RGs have three “GigaFamily” brands: GigaSpire, GigaPro, and GigaMesh. Besides that background, this post isn’t intended to be about the company, so we’ll move on.

Something that all Calix GigaFamily wireless systems have is the ability to act as an over-the-air wireless sniffer.

First, you have to log into the device with the support user that gives access to all areas of the web interface (the “admin” user doesn’t have access to the OTA sniffer). The username and password for the support user are outside the scope of this post. If you happen to be a Calix customer, you can find the info in the Calix Documentation Library ➔ Systems Products ➔ Premises ➔ Operation ➔ GigaFamily Operation ➔ EXOS Systems: Service Provider’s Guide, then on the first page of Chapter 4: EXOS Embedded Web Interface (EWI).

Since a picture is worth 1,000 words, perhaps a 2:27 video is worth 8.8 million (feel free to do the math).

Note that the GigaSpire only has the nose on it when it’s in sniffer mode (at which point a tongue in a cheek also comes out)…

In my previous article on MCS and Windows, I laid some groundwork on what MCS is and why it’s useful. Check out the first few paragraphs for that background info.

This time, let’s turn our attention toward macOS. The best way to dump the Wi-Fi settings in a human-readable format, would be:

sudo /System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport -I

which yields something like:

     agrCtlRSSI: -45
     agrExtRSSI: 0
    agrCtlNoise: -92
    agrExtNoise: 0
          state: running
        op mode: station
     lastTxRate: 1300
        maxRate: 217
lastAssocStatus: 0
    802.11 auth: open
      link auth: wpa3-sae
          BSSID: 4c:43:41:4:1c:bc
           SSID: Flowers By Irene
            MCS: 9
  guardInterval: 800
            NSS: 3
        channel: 149,80

If you run that command without “sudo”, it doesn’t list the BSSID.

You can also run the above program with the -x flag, which will dump it in XML format, if you prefer that. Honestly, I feel like even though the output above is human-readable, it’s also easier to “machine read” than the XML.

While this gives me more information than Windows does, it doesn’t have a separate uplink vs. downlink indicator. The “maxRate” is also confusing. Before digging in too much, let’s look at another example:

     agrCtlRSSI: -33
     agrExtRSSI: 0
    agrCtlNoise: -88
    agrExtNoise: 0
          state: running
        op mode: station
     lastTxRate: 1200
        maxRate: 867
lastAssocStatus: 0
    802.11 auth: open
      link auth: wpa2-psk
          BSSID:
           SSID: Anudder
            MCS: 11
  guardInterval: 800
            NSS: 2
        channel: 52,80

This helps us understand that macOS likes round numbers. Technically, MCS 11 with two spatial streams on 80 MHz OFDMA with a 0.8μs GI is 1201 Mbps.

But we have that mysterious “maxRate” again. Before rounding to a whole number, 867 is actually 866.7, which is MCS 9 on 2 spatial streams on an 80 MHz channel with a 4μs GI. Perhaps that means it is the uplink rate… that seems conceivable.

From the first example, we have a maxRate of 217, which, before whole-number rounding, is likely 216.7, which is MCS 7 on 3 spatial streams, but on a 20 MHz channel, but we know we’re operating on an 80 MHz channel here.

Python Fun

At any rate (pun intended), parsing the output is pretty easy. Here’s a quick program I wrote to convert macOS’s output to a JSON file.

# /System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport -I

import json

macOS_wifi_dump = """
    agrCtlRSSI: -33
     agrExtRSSI: 0
    agrCtlNoise: -88
    agrExtNoise: 0
          state: running
        op mode: station
     lastTxRate: 1200
        maxRate: 867
lastAssocStatus: 0
    802.11 auth: open
      link auth: wpa2-psk
          BSSID:
           SSID: Anudder
            MCS: 11
  guardInterval: 800
            NSS: 2
        channel: 52,80
"""

int_fields = [
    'agrCtlRSSI', 'agrExtRSSI', 'agrCtlNoise', 'agrExtNoise',
    'lastTxRate', 'maxRate', 'lastAssocStatus', 'MCS',
    'guardInterval', 'NSS'
]

airport = {}
for line in macOS_wifi_dump.strip().splitlines():
    if ":" in line:
        left, right = line.split(":", 1)
        key = left.strip()
        value = right.strip()
        airport[key] = int(value) if key in int_fields else value

airport['channel'], airport['width'] = [int(x) for x in airport['channel'].split(',')]

my_json = json.dumps(airport, indent=4)
print(my_json)

The output would look like this:

{
    "agrCtlRSSI": -33,
    "agrExtRSSI": 0,
    "agrCtlNoise": -88,
    "agrExtNoise": 0,
    "state": "running",
    "op mode": "station",
    "lastTxRate": 1200,
    "maxRate": 867,
    "lastAssocStatus": 0,
    "802.11 auth": "open",
    "link auth": "wpa2-psk",
    "BSSID": "",
    "SSID": "Anudder",
    "MCS": 11,
    "guardInterval": 800,
    "NSS": 2,
    "channel": 52,
    "width": 80
}

My original idea behind MCS fiddling was in order to write a parser that would calculate all the MCS values in order to:

• Output a matrix like the one found on mcsindex.com
• Output a JSON file with the data rate being the key and an array of objects containing each of the possibilities

I may do that at some point in the future. I may also do some Linux “iw” MCS observations. For now, at least, it’s good to know what some of the capabilities and restrictions are for reading from macOS.

MCS, or Modulation and Coding Scheme, is a way to “… [evaluate] the quality of the RF environment – the RF media that devices are working in, which is reflected in every single transmission” (from MCS Table and How To Use it).

The matrix of those various measurements is called an MCS table. From that matrix, you can derive the MCS index of a given radio network configuration. An excellent table can be found at mcsindex.com. Whenever I refer to “looking at the table” in this post, that’s what I’m referring to, so if you haven’t clicked to open that link, do so now!

Windows doesn’t show you your MCS index. The quickest text-based format to show Wi-Fi data in Windows comes courtesy of the “netsh” command:

> netsh wlan show interface

The problem is that Windows will show you your raw data rate, but it’s missing certain information. Here’s some Windows output:

Name                   : Wi-Fi
Description            : Intel(R) Wi-Fi 6 AX201 160MHz
GUID                   : f6cbd34e-3469-46c4-b6f8-47c02af70e48
Physical address       : 94:e2:3c:83:c8:27
Interface type         : Primary
State                  : connected
SSID                   : Starbucks WiFi
AP BSSID               : e2:cb:ac:92:24:ff
Band                   : 5 GHz
Channel                : 149
Network type           : Infrastructure
Radio type             : 802.11ac
Authentication         : Open
Cipher                 : None
Connection mode        : Auto Connect
Receive rate (Mbps)    : 400
Transmit rate (Mbps)   : 400
Signal                 : 96% 
Profile                : Starbucks WiFi
QoS MSCS Configured         : 0
QoS Map Configured          : 0
QoS Map Allowed by Policy   : 0

I see that my Receive rate (aka Rx, aka DL/downlink) and Transmit rate (aka Tx, aka UL/uplink) are both 400 Mbps. But what does that mean? Looking at the MCS table, it indicates that a rate of 400 can mean only one thing… I’m using:

• 2 spatial streams (NSS, or “Number of Spatial Streams”)
• 256-QAM
• 5/6 coding
• 40 MHz channel
• 400μs guard interval (GI)

… therefore my MCS index is 9… easy! The only information I need from Windows here is the fact that my “Radio type” is 802.11ac, which means I’m using VHT (Wi-Fi 5), not HE (802.11ax/Wi-Fi 6) or EHT (802.11be/Wi-Fi 7).

Here’s another example:

Name                   : Wi-Fi
Description            : Intel(R) Wi-Fi 6 AX201 160MHz
GUID                   : f6cbd34e-3469-46c4-b6f8-47c02af70e48
Physical address       : 94:e2:3c:83:c8:27
Interface type         : Primary
State                  : connected
SSID                   : Flowers By Irene
AP BSSID               : 4c:43:41:04:1c:bc
Band                   : 5 GHz
Channel                : 149
Network type           : Infrastructure
Radio type             : 802.11ax
Authentication         : WPA3-Personal  (H2E)
Cipher                 : CCMP
Connection mode        : Auto Connect
Receive rate (Mbps)    : 864.7
Transmit rate (Mbps)   : 1201
Signal                 : 95%
Profile                : Flowers By Irene
QoS MSCS Configured         : 0
QoS Map Configured          : 0
QoS Map Allowed by Policy   : 0
Hosted network status  : Not available

In this case, my downlink data rate is 864.7 and my uplink rate is 1201. Unfortunately my DL is pretty ambiguous. Looking at the MCS table…

• 864.7 Mbps could mean:
  • MCS 4 on EHT at 1 SS / 16-QAM / ¾ coding / 320 MHz / 0.8μs GI
  • MCS 8 on HE/EHT at 1 SS / 256-QAM / ¾ coding / 160 MHz / 0.8μs GI
  • MCS 2 on EHT at 2 SS / QPSK / ¾ coding / 320 MHz / 0.8μs GI
  • MCS 4 on HE/EHT at 2 SS / 16-QAM / ¾ coding / 160 MHz / 0.8μs GI
  • MCS 8 on HE/EHT at 2 SS / 256-QAM / ¾ coding / 80 MHz / 0.8μs GI
  • … etc
• 1201 Mbps could mean:
  • MCS 11 on HE/EHT at 1 SS / 1024-QAM / ⅚ coding / 160 MHz / 0.8μs GI
  • MCS 11 on HE/EHT at 2 SS / 1024-QAM / ⅚ coding / 80 MHz / 0.8μs GI

In the scenarios above, what are the most logical conclusions? First, most modern mobile client stations have 2 radio chains and therefore likely 2 spatial streams (aka 2×2:2, meaning 2 Tx radio chains × 2 Rx radio chains : 2 spatial streams). In the 864.7 Mbps scenario, we can probably disregard the first two that have only 1 spatial stream. We can also disregard option 3, because we can see from the Windows output that it’s 802.11ax, aka HE, so it’s clearly not EHT. Unfortunately, there is no way to tell which MCS value we truly have, without querying the driver or doing a packet capture. With a data rate of 1201 Mbps, on the other hand, it’s obviously MCS 11, though Windows doesn’t tell us if it’s an 80 or a 160 MHz channel width. But if we assume it is also 2 spatial streams, we determine the channel width is then 80 MHz. If we “back apply” that logic to the downlink, we can reasonably guess the downlink is MCS index 8, because the DL and UL bandwidth would be the same. Therefore:

• UL is MCS 11
• DL is MCS 8

I just had to show one more thing. I work for Calix, so I am privy to the some wiz-bang Wi-Fi systems (in this case, the GigaSpire 7u10t). I also have a Minisforum MS-01 Workstation Core i9-13900H with a Wi-Fi 7 PCIe card with 6 GHz, 320 MHz bandwidth, which shows as:

>netsh wlan show interface

There is 1 interface on the system:

Name                   : Wi-Fi
Description            : TP-Link Wi-Fi 7 PCIe Adapter
GUID                   : 7467bdb0-9d6f-4ee7-aa37-59285d91e6f7
Physical address       : fc:b0:de:cd:7e:0b
Interface type         : Primary
State                  : connected
SSID                   : Flowers By Irene
AP BSSID               : c2:43:41:04:1c:bd
Band                   : 6 GHz
Channel                : 37
Network type           : Infrastructure
Radio type             : 802.11be
Authentication         : WPA3-Personal  (H2E)
Cipher                 : CCMP
Connection mode        : Profile
Receive rate (Mbps)    : 5764.8
Transmit rate (Mbps)   : 5764.8
Signal                 : 88%
Profile                : Flowers By Irene
QoS MSCS Configured         : 0
QoS Map Configured          : 0
QoS Map Allowed by Policy   : 0

and my Calix Speed & Performance Insights server yield 3.4×2.6 Gbps over Wi-Fi… 🔥

As for the DL/UL rate? It’s the highest possible score for 2 spatial streams at:

MCS 13 on EHT at 2 SS / 4096-QAM / ⅚ coding / 320 MHz / 0.8μs GI

In the near future, I will do the same MCS fiddling on macOS. Hint: macOS gives you the MCS index, but withholds certain other information, so we will still have some (different) detective work to do!

Most of my Wi-Fi career was thinking about the enterprise. No doubt that the enterprise is where you really have to put on your “Wi-Fi hat,” because you’re typically dealing with many (many!) access points. The smallest design and installation I ever did was 4 access points, and the largest was several thousand.

WPA-Personal

This is the basic “password-based” authentication mechanism that is used in most residential scenarios, and by various SSIDs in the enterprise as well. It’s usually designated for:

• the administrator or home user doesn’t want to or doesn’t have the knowledge to set up a proper infrastructure
• an access point or station that can’t support “proper” 802.1X (either on the client side or the infrastructure side)

When WEP was determined to have a hole large enough to drive a truck through, some very smart folks at the Wi-Fi Alliance came up with the notion of using the encryption method built into any device that supported WEP (RC4) and wrapping it into a temporal key format. The result was WPA-Personal. It uses the passphrase, SSID, and a few other parameters run through the PBKDF2 algorithm, to derive a pre-shared key. When the IEEE created 802.11i, AES replaced RC4, and WPA2-Personal was born. WPA3-Personal uses a different, more-secure technique, called SAE (Simultaneous Authentication of Equals).

Sometimes people interchangeably use “password,” “passphrase,” and “pre-shared key.” I’m personally fine with that… the context tells you what they’re talking about. Some examples:

• Alice asks Bob: “Hey, what’s the password for your Wi-Fi?”
• GUI tooltip: “Click the eyeball to reveal the pre-shared key.”

In both of these cases they are talking about the passphrase, but it’s not worth losing friends over!

WPA-Enterprise

When you do enterprise configuration, you need to be familiar with 802.1X and EAP. I remember it felt like voodoo, because I wasn’t particularly familiar with RADIUS at the time (circa 2004). That meant I had to come up to speed on both RADIUS and EAP at the same time.

I had used RADIUS in a basic sense with Windows 2000/2003’s IAS (Internet Authentication Service). I used it because I was setting up Cisco IOS to use AAA, and we had to use RADIUS because we didn’t have Cisco ACS, which would have provided TACACS+. As a reminder, RADIUS (or any AAA) provides these checks:

• Authentication: Am I who I say I am?
• Authorization: What do I get to do?
• Accounting: What am I doing and how much of it?

The three roles within a RADIUS communication are:

• Supplicant – the device wanting access to a resource
• Client – the device the supplicant needs access to or through
• Authentication server – the device that allows or prevents access (provides an authentication and authorization response)

Once you authenticate, the RADIUS server sends a list of attribute-value pairs (AVPs) to the client indicating what kind of access the user/device should get.

Logging into Cisco IOS expected the RADIUS server to respond with:

• Authentication – this is easy; does my username match my password
• Authorization – this where the RADIUS server passes the attribute-value pairs (AVP) back to the RADIUS authenticator

When I got into 802.1X, the thing that blew my mind was that I could pass a VLAN back to the RADIUS client, and it would apply that VLAN tag to every Ethernet frame that was dropped onto the wired network. For a university, based on a Windows group (though it could have been any criteria), students go on the “student VLAN” and staff goes on a “staff VLAN,” which probably have different firewall rules and content controls, all while using the same SSID.

Hybrid Approach

What do we do if the station only supports WPA-Personal and not WPA-Enterprise? or if it’s determined that WPA-Enterprise is too hard? Some IoT devices do not even support WPA-Enterprise. So we use one WPA-Personal SSID, but we want each device to have a unique passphrase. Some vendor terms for this are custom approach are:

• iPSK (Identity Pre-Shared Key) – Cisco
• PPSK (Private [or Per-user] PSK) – Juniper, Extreme, Fortinet
• MPSK (Multi PSK) – Aruba
• DPSK (Dynamic PSK) – Ruckus

These are all similar riffs on the same concept. The reason I say this is hybrid is because some of these will actually pass the query along to a RADIUS server or proprietary cloud, then read the AVP authorization response to make decisions, just as WPA-Enterprise would do.

Because of the way that WPA3-Personal works (SAE), this approach isn’t reasonable for that. Since 6 GHz doesn’t allow WPA or WPA2, some of these approaches are limited to 2.4 or 5 GHz bands.

When I did enterprise Wi-Fi on a daily basis, my mindset was that enterprise wireless was the only “real” Wi-Fi. Home routers were cheap toys, and only wimps used a router supplied by their ISP. As I’ve aged (and gone to work for a “residential Wi-Fi” company), I have become less judgmental.

In this article, I break down three types of devices that broadcast 802.11 wireless.

Access Points (APs)

In the enterprise world, we talk about access points (APs). Access points are typically layer-2 devices that convert between an 802.11 wireless connection and a wired connection (typically Ethernet). Some of the players that pop into my head in this arena are: Cisco/Meraki, Juniper, Extreme, Aruba, Ruckus, and Ubiquiti. There has been a lot of consolidation over the years (the one that affected me the most was Cisco buying Airespace back in 2005). The M&A efforts continue, as HPE/Aruba has been trying to buy Juniper for over a year as I write this.

More often than not, APs are controlled centrally by a non-cleverly (but appropriately named) device: the Controller, sometimes called a WLAN or Wi-Fi Controller. Many pages could be written about what controllers do, but they aren’t in the title of this post, so that’ll have to wait for another post.

Routers

In the residential world, it’s unusual to have a device that is simply an AP, as defined above. Instead, we have “Wi-Fi Routers,” which typically provide:

• Wi-Fi access point functionality
• Layer-2 switching capabilities via one or more LAN interfaces
• Layer-3 routing capabilities via WAN interface
• DNS and DHCP server services
• NAT and firewall services
• etc.

Some players off the top of my head in that space are: Netgear, Linksys, and D-Link. Sometimes you can also get “mesh units” (aka, satellites—not to be confused with the ones that orbit the earth) that have either a Wi-Fi or an Ethernet connection back to the main router that extends connectivity to an area larger than can be handled by a single device. These devices don’t typically have a lot of intelligence of their own (or their intelligence is disabled), but they are smarter than the dumb “Wi-Fi repeaters” that you can sometimes find.

Residential Gateways

A third category that most Wi-Fi professionals don’t really think about is the Residential Gateway (RG). These are similar to “Routers” above, but are usually owned by the Internet Service Provider, and “call home” via:

• Centralized ACS (Auto Configuration Server) using:
  • TR-069, aka CWMP (CPE* WAN Management Protocol)
  • TR-369, aka USP (User Services Platform)—the successor to TR-069
• Proprietary management platform, typically using https for transport
• Hybrid approach where as much as possible is done via TR-x69, but certain shortcomings necessitate a secondary connection for the necessary flexibility

* CPE: Customer Premises Equipment

In addition, because they are supplied by service providers, they may have POTS ports (for landline phones) and sometimes even an F-type coax connector to support “triple play” internet/phone/cable TV service. Some vendors that come to the top of my mind for this are: Calix, Plume, Nokia, and Adtran.

There are some vendors who play in both the “router” and “RG” world, for example, Plume and Eero (owned by Amazon).

Thoughts on Nomenclature

Based on the things written above:

• An RG is always a router *
• A router is always an AP ^†
• By implication, an RG is always an AP ^†

* assuming it isn’t just acting as a layer-2 passthrough
^† assuming Wi-Fi isn’t disabled

So, what do you call a router (which I will call a system here) if it’s doing “non-residential” things? For example, what if a system has three SSIDs:

• SSID-1 is configured to pass transparently through the device at layer-2 like a traditional AP
• SSID-2 is tied to the system’s internal DHCP server, and traffic gets NAT’ed as it passes through
• SSID-3 routes but does not NAT, and acts as a DHCP relay rather than a DHCP server

When it’s advertising SSID-1, should we call it an AP, when we’re referring to SSID-2, is it an RG, and when it’s doing SSID-3, is it a router?

My thought is that we should refer to it based on the context of what we’re describing. If we’re talking about Wi-Fi connectivity, we refer to it as an AP. If we’re talking about its router or NAT functions, we call it either a router or an RG–depending on if it’s primary configuration responsibility is that of the ISP or the person who owns or leases the device.

Some examples might be:

• Access Point
  • “The AP is set to channel 36 with an 80 MHz width”
  • “We can roam seamlessly between those APs”
• Router
  • “What IP does that router NAT outbound connections behind?”
  • “Does that router have OSPF enabled?”
• Residential Gateway
  • “What phone number is tied to the SIP configuration on that RG?
  • “Can you check the parental control settings using the iOS app for your RG?”

March 1, 2025

Cisco bought Airespace back in 2005. Airespace had this great operating system called AireOS that Cisco continued to use as its primary WLAN controller OS until they released the 9800 series in 2018. That means Cisco used AireOS for 13 years before moving the Wi-Fi controller functionality to IOS. That says a lot for the staying power and quality of AireOS.

The last time I touched a production Cisco wireless network (not counting my house) was in March of 2020. At that time, I still preferred AireOS, as it was time-tested and battle-hardened.

Today I’m writing about what happens when you change different settings in AireOS–what does it do to your beacons and your probe responses.

I created a network called “defaults”, though I quickly realized that as I made small changes, that name would no longer be meaningful. Oh well! 🙂

I left everything configured as defaults in order to obtain a baseline. Regarding roaming-related activities, we have:

• Security tab: 802.11r, aka Fast Transition, set to the default of “Adaptive.”
• Advanced tab: 802.11k:
  ☑ Neighbor List
  ☐ Neighbor List Dual Band
• Advanced tab: 802.11v BSS Transition Support
  ☑ BSS Transition
  40 Optimized Roaming Disassociation Timer (0 to 40 TBTT)
  ☑ BSS Max Idle Service
  ☑ Directed Multicast Service

Here are some of the results.

Enable WPA with TKIP

The default is WPA2 with AES.

I enabled WPA with AES:

This was the new information element that showed up in my beacon frames.

Next, I added TKIP in:

That gave me this. Not surprising that there is an additional data point.

This is probably the most common WPA-WPA2 transition mode configuration, though:

Roaming Settings

FT / 802.11r

Fast Transition, also referred to as 802.11r, is enabled as “Adaptive” by default. This is what a default information element looks like:

When I disabled FT, it was simply removed.

A few things happen when converting from “Adaptive” to “Enable”. First, you have to be sure to check the AKM corresponding to the WPA type you use (Personal vs. Enterprise).

The second is that Cisco will try to keep you from shooting yourself in the foot with this message:

Warning!! Non-802.11r Clients will not be able to connect on this WLAN. Press OK to Continue.

Radio Management / 802.11k

Disabling 802.11k will yield this difference in your information elements:

Wireless Network Management / 802.11v

Maybe I have more work to do here, but when I disabled 802.11v settings, the IE (at least in the beacon probes) weren’t different at all.

I decided not to go through every possible iteration, as that would take forever. I suppose some nice automation could do the trick, but I’ll save that for another day!