From the table, I would remove 124E and 128E from your channel selection as those have the 'R' (Radar) flag. 112 has the C flag and is abandoned to go back to 124/128.
What probably happens is that the AP sees a radar on 124, then moves to 112 which is more busy and over time finds that 124 is nice and clean and returns there because it has a lot of capacity. AirMatch (MCR and Central) should handle this situation better than standalone controllers.
Also it looks that you are using 80MHz channels on 5GHz. Going down to 20/40MHz may improve things as well, but if you see regular radar events, it's common practice to remove those from the available channels.
------------------------------
Herman Robers
------------------------
If you have urgent issues, always contact your Aruba partner, distributor, or Aruba TAC Support. Check
https://www.arubanetworks.com/support-services/contact-support/ for how to contact Aruba TAC. Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba Networks.
In case your problem is solved, please invest the time to post a follow-up with the information on how you solved it. Others can benefit from that.
------------------------------
Original Message:
Sent: Nov 25, 2022 02:04 AM
From: Andriy -
Subject: Radar detected on interface wifi0, channel .... , typeid 3
1) I have reported wifi disconnections per radar events
I am going to exclude UNII2 frequencies as a workaround solution.
Any better solution can be used in such case ?!
ap regulatory-domain-profile "exclude_UNII2-extended"
no valid-11a-channel 112
no valid-11a-channel 124
...
ap-group <.....>
....
regulatory-domain exclude_UNII2-extended
----------------------
2) I thought IEEE 802.11h ("Dynamic frequency selection" part) is not so disruptive,
is it really per standard design it leads to wifi disconnections in the case of radar or some configuration adjustments can overcome this?!