Don't trust Airmatch or reported values. Validate with other tools like Ekahau or Aruba UXI sensors!!
First posted mid January 2025
We have two clusters, each cluster has two 7240XM controllers. Cluster is L2 connected. Environment is managed by an active Mobility Conductor. We have a standby MC.Everything is running 8.10.0.14. TAC Case open for issue noted below. We are advised by Aruba ERT engineer that they are escalating issue to a higher level engineering team. TAC has confirmed our findings during multiple remote session. HPE/Aruba has not sent anyone onsite.
The issue:
Airmatch is not honoring 5GHz channel assignment as defined in AP groups. In addition, and most worrisome, the channels reported by the MD, MC and Airwave may be incorrect. This is not restricted to any one specific AP group, cluster or location. We have multiple AP groups configured across out hospitals. Standard AP group settings allow all 5 GHz channels except channels 36,144,165. We only use 20 MHz channel width.
We discovered Airmatch (or maybe some other protocol) is assigning channels 36 and 165. We suspect channel 144 is also being assigned but have not confirmed that with Ekahau or the Aruba UXI sensors. TAC has confirmed our findings. We can prove 100 % that an AP is using channel 36 (match BSSID) per UXI and Ekahau whereas the Aruba infrastructure, MDs, MC and Airwave all report the AP is using another channel. Example, Aruba infrastructure may show the AP on channel 64.
When we associate a Win11 device or a Vocera badge, we see channel 36 displayed on GUI of each yet the Aruba infrastructure shows the client is connected to the channel the Aruba infrastructure is reporting the AP is using, say channel 64 to use the example above.
1/31/25 - After three weeks of troubleshooting and multiple remote sessions with multiple TAC Engineers, this issue is being tracked via internal ticket# AOS-262499.
2/6/25 - Request by TAC. Uploaded ap tech support files from 3 additional access points that are reporting incorrectly.
2/113/2025- How to confirm actual channel in use:
Run below to find the channel reported to be in use. Note radio is reporting it is using channel 140
show ap active ap-name <valid ap name> -
Active AP Table
---------------
Radio 0 Band Ch/EIRP/MaxEIRP/Clients
AP:5GHz-VHT:140/18.0/25.2/2
Run below command to find the channel the radio is actually using. In this case, radio 0 of the access point is actually using channel 36 while the channel reported by the mobility conductor and MDs report the radio is on channel 140.
show ap debug radio-info ap-name <valid ap name>
Radio Info Script
------------------
aruba_dbg_radio_info_0 Start time: Wed Jan 29 11:58:41 EST 2025
---------------------------------------------------------------
====== wl-commands ======
wl -i wifi0 cca_get_stats -i
Using channel 36
chan dur ibss obss interf time
36 1002 85 8% Low 0 0% Low 0 0% Low 3521950
36 1002 100 9% Low 1 0% Low 0 0% Low 3521949
36 1002 197 19% Medium 2 0% Low 0 0% Low 3521948
36 1002 97 9% Low 1 0% Low 0 0% Low 3521947
36 1001 91 9% Low 1 0% Low 0 0% Low 3521946
36 1003 100 9% Low 5 0% Low 0 0% Low 3521945
36 1002 111 11% Low 2 0% Low 0 0% Low 3521944
36 1002 70 6% Low 1 0% Low 0 0% Low 3521943
36 1002 77 7% Low 1 0% Low 0 0% Low 3521942
36 1002 75 7% Low 1 0% Low 0 0% Low 3521941
Summaries:
chan dur ibss obss interf num seconds
36 1002 10% Low 0% Low 0% Low 10
Recommended channel: 36