9120AXI Access Point - Random 802.11 Beacon Contents

[Aaron Harrison]

I've been troubleshooting some client connectivity issues on our 9120AXI and 9800 controllers recently, and this has led me down the path of doing OTA captures on APs.

I'll preface this by saying 802.11 captures are not something I've looked into in detail previously.

But - the 9120AXI APs we have seem to behave very differently to our other APs (typically 3802/2802s that are pending replacement over the next couple of years with more 9120AXIs) when it comes to the 802.11 beacons and probe responses.

My Catalyst centre server repeatedly tells me that Intel clients are reporting 'Invalid IE (49)'  in beacons, so I started to look into the beacon contents to see what they were grumbling about. I imagined I could do a quick capture, and see what IE 49 was, and see how I might disable it, or whatever.

If I look at any other AP - Cisco 3802, my home broadband, etc, beacons seem to work like so:

- transmit every 100ms or whatever the interval is. Regular.

- each beacon, other than timestamp related content or the MAC of the sending device, is pretty much the same. It advertises the same data rates, security, unintelligible OFDM capabilities etc.

If I look at an OTA capture from a Cisco 9120:

- they seem to 'double transmit. sometimes. I understand the beacon interval is 100ms by default, but I see one beacon, then another almost immediately after. Then another 'pair' 100ms later. Odd, but probably not important.

- more strangely, every 100ms the 9120s transmit a different beacon. It's 99% similar, but at the end of the 'tagged' elements, it randomly inserts a different bit of information into every beacon:

So here's some examples. I've obfuscated the SSID but the captures are filtered for the same SSID, and come from the same AP

First beacon in this capture has a 'relay transfer parameter' tagged parameter:

Next one, 200ms later,... has a 'Supported Channels' tag:

Next one... 'page slice'

Etc. Probe responses appear the same way. Random parameters, changing continuously.

Beacon sizes are about 400 bytes so plenty of scope to put more data in, if it was needed. And surely, random changing beacons could cause inconsistent client behaviour? Not to mention make it a PITA to figure out what IE 49 is, if it might not appear in beacons when I capturing.

I see this behaviour on 5ghz in these two scenarios:

9120AXI - running on WLCX 5520 8.10.190.0 

9120AXI - running on WLC 9800 17.12.5

3800/2800 on the same two WLCs do not do this. All beacons are the same, every 100ms. As they are on every other wireless network I have easy access to today.

Has anyone seen this behaviour?

Can anyone explain it to me - maybe it's normal? 

I can't help think that's it's not, seeing parameters like 'supported channels' disappear seems silly, as those are things that will not change between beacon intervals. 

[Leo Laohoo]

The first generation of AX APs are made up of 9130 and the 9110/9120 series of APs.  9130 as Qualcomm chipset while the "lower quality" have Broadcom chips with the later being described (by a WNBU member) as "challenging" (read between the lines) to program.  

Next, daily AP reboot is going to be the norm because the codes are buggy.  There is no stable code.  Every code will keep anyone awake at night with nightmares.

[eglinsky2012]

@Leo Laohoo What chipsets do the 9105, 9124, 916x, and 917x use?

[Leo Laohoo]

910X, 911X, 912X are Broadcom. 

9130, 916X and 917X are all Qualcomm.  

[Aaron Harrison]

So I understand what you are saying, maybe one chipset is better than another. 

But that doesn't excuse Cisco from providing a product that works and behaves normally.

Few organisations are going to stomach nightly reboots of APs. Certainly, this one will not where they have 24-hour operations. 

Aaron

[Mark Elsen]

   - @Aaron Harrison   >....Few organisations are going to stomach nightly reboots of APs. Certainly, this one will not where they have 24-hour operations. 
                                 @Leo Laohoo    Fully agree , not a viable solution in many business circumstances.

  M.

[Leo Laohoo]

---

@Aaron Harrison wrote:
Few organisations are going to stomach nightly reboots of APs. Certainly, this one will not where they have 24-hour operations. 

---

Cisco's "quality control" is non-existence since 2010.  Ever since IOS-XE has been released, I initially thought the quality of the code has hit rock bottom.  Sadly, I was mistaken.  Every day, I read these bug reports and I cry myself to sleep every night.  

Initially, I first heard about these "reboot APs daily" affecting the first generation of Cheetah OS, 2800/3800/4800/1560, but the bugs do not affect the "classic IOS", 2700/3700 and older.  We were told that these bugs affecting CoS will be fixed in the new Catalyst 9k.  Over time, Catalyst 9k "reboot APs daily" started to appear and I've already seen this workaround being recommended to the new 917x APs.  

At first, the bugs affected the AP radios randomly blackholing traffic.  And these "blackholing" bugs are now affecting the wired port of the AP.  

So, yeah.  Some users may not have the stomach with "reboot APs daily" workaround but nobody really made the effort of complaining to their SE about it.  So life goes on.   

[Mark Elsen]

  - @Aaron Harrison     Make sure that the Wi-Fi drivers are up to date on the intel clients.
                                   For instance make a POC on one client and check if that makes a difference :
                                   https://www.intel.com/content/www/us/en/download/19351/intel-wireless-wi-fi-drivers-for-windows-10-and-windows-11.html

  M.

[Aaron Harrison]

Hey Mark

We do of course update the drivers as we see issues. I'd prefer the desktop folks standardise a bit more, but here we are.

However - no amount of driver updates is going to change what the AP sends out in beacons. They are just blasted out and received by the clients right? 

Aaron

[Mark Elsen]

  - @Aaron Harrison    >...We do of course update the drivers as we see issues. I'd prefer the desktop folks standardise a bit more, but here we are.
                                  As mention in your new thread ; you can pick one test device and see if a driver upgrade is related

  M.

[pieterh]

one question (I did not recognize any information in your posts) : how did you perform the capture?
on a wireless client? or did you use the controlers radioactive capture capabilities?

[pieterh]

according to Google-AI it could mean 

Wifi beacon element ID 49, often listed as a reason code for association denial, means "Destination STA is not present within this QBSS". This indicates that the client's request to join a Quality of Service Basic Service Set (QBSS) was denied because the access point could not find the device in its current service area, possibly due to location, signal strength, or an expired session. 

• .....
• Meaning: The access point is rejecting the client's connection because the client device is not within the specific service area of the Quality of Service (QoS) enabled network. 

wich suggests "49" is a valid IE ID, but caused by the client has moved to a different (service) area.

[pieterh]

using other search terms (adding site:IEEE.org) Google-AI  responds with a relation to power-save state.

WiFi beacon element ID 49 refers to the Traffic Indication Map (TIM) element in the IEEE 802.11 wireless standard. This element is a critical part of the beacon frame, used by an access point to inform client devices whether there are any buffered unicast frames waiting for them, allowing devices to save power by not constantly scanning for beacons. 

• What it is: The Traffic Indication Map (TIM) element is a component within a beacon frame, a type of wireless frame that access points (APs) periodically broadcast to announce their presence and provide information about the network.
• Element ID: In the standard, element ID 49 is specifically assigned to the TIM element.
• Function: The TIM element's primary function is to help client devices enter a power-saving state. The TIM shows which stations have buffered unicast data waiting at the AP.
• How it works:
• Client devices can go to sleep and periodically wake up to check for beacon frames.
• If a client device sees that the TIM indicates it has data waiting, it can wake up and request the data.
• If the TIM indicates no data is waiting, the device can remain asleep to conserve power.

• Context within IEEE 802.11: The IEEE 802.11 standard defines this and many other elements within the beacon frame, which are the fundamental building blocks for wireless local area networks (WLANs).