Good news/bad news: good news is that my hAPax2 is failing to connect in station mode to a Cisco 11ax AP (9117) so it seems somewhat repeatable. Bad news is that my failure mode is slightly different: it gets through association but the AP immediately sends a deauth with Reason Code 0x002e.
I have access to the Cisco infrastructure here and it has some relatively advanced troubleshooting tools, so I put this MAC address of the tik through it during a failure (they call it Radioactive Trace) and it gives this output:
The reason code listed by Cisco 0x002e is 46d but that might be the Status Code per 802.11-2020 table 9-50. Seems that number got used as the reason code in the deauth frame per table 9-49. Anyway, the Cisco debug is quite helpful here; I made sure my tik config matched yours and matched the Cisco config from the beacons you provided. So we have the same scenario already mentioned: the tik advertised for PMF but the AP does not and that matches with the Cisco error code. So for me, there are two solutions: either disable PMF in the tik, or enable as optional on the CIsco side. I confirm that both worked for me and the tik was then able to complete the association and communicate.
So why is my symptom the same but the exact failure mode appears different? A couple of possibilities:
I have access to the Cisco infrastructure here and it has some relatively advanced troubleshooting tools, so I put this MAC address of the tik through it during a failure (they call it Radioactive Trace) and it gives this output:
Code:
Connection attempt #22024/03/24 16:01:09.124client-orch-smClient made a new Association to an AP/BSSID: BSSID 0cd0.f8xx.xxxx, WLAN WIFI-PUB, Slot 1 AP 0cd0.f8xx.xxxx, APabc123, Site tag west, Policy tag west-policy, Policy profile west_vlan90, Switching Local, Socket delay 0ms2024/03/24 16:01:09.125dot11Association failure, reason code sent: 46, interpretation: WLAN security policy doesn't support the requested cipher suite2024/03/24 16:01:09.127client-orch-smController initiated client deletion with code: CO_CLIENT_DELETE_REASON_DOT11_CIPHER_SUITE_REJECTED. Explanation: During RSN Information element processing, the group key provided by client is invalid. Actions: This is probable client side issue. Check RA traces, and contact client manufacturerSo why is my symptom the same but the exact failure mode appears different? A couple of possibilities:
- we have different problems and they are not really related
- I have a different AP/different AP software than you do
- I did notice that the tik will probe often but not actually try to connect so perhaps the short capture you show is not representative of what is happening
- maybe other reasons too
Statistics: Posted by robertkjonesjr — Sun Mar 24, 2024 6:30 pm