Hello, I wanted to provide some closure on these issues I wrote about in June, in case anybody else notices something similar in the future: On 6/9/2022 3:26 PM, Doug Brown wrote:
1) In 2.7, commit 065c029a55955feac56d6537778233da0074d27b "Remove MBO dependency from Supported Operating Classes element" causes me to get rejected by my APs (both an Asus router and iPhone hotspot) wlan0: Event ASSOC_REJECT (12) received wlan0: CTRL-EVENT-ASSOC-REJECT bssid=xx:xx:xx:xx:xx:xx status_code=1 I worked around this one temporarily by commenting out the call to wpas_supp_op_class_ie() in wpas_populate_assoc_ies(). I am not experienced enough to understand if this is a driver issue or something deeper, but ensuring the op class IEs don't get added fixes it.
I did some packet sniffing and determined that this is actually a bug in the libertas driver, caused by multiple IEs being added to the association request. The libertas driver gets confused if there is more than one. I'll be submitting a Linux kernel patch to fix this. So not wpa_supplicant's fault at all.
This fixes it up until version 2.10, which adds more problems: 2) In 2.10, two commits adding SCS and MSCS support cause the exact same issue (rejected by both of my APs with the same error as above): a118047245b0861acdf6a9f8410237705f12d995: "MSCS: Add support to send MSCS Request frames" c005283c48c189752c18d68d6cebaaa02e64c155 "SCS: Sending of SCS Request frames" I worked around these temporarily by commenting out the new bits being set in wpas_ext_capab_byte from these two new commits.
This was caused by the same bug -- again, a libertas driver problem.
3) This still doesn't fix 2.10 with libertas, because libertas is also affected by the same issue in 2.10 that others have already fixed for the broadcom-wl adapters, where wpa_supplicant is trying to install more scan IEs than are supported, and just prints this repeatedly as soon as it opens up: wlan0: CTRL-EVENT-SCAN-FAILED ret=-22 retry=1 wlan0: CTRL-EVENT-SCAN-FAILED ret=-22 retry=1 ... This patch already posted earlier this year by David Bauer fixes this final issue: http://lists.infradead.org/pipermail/hostap/2022-January/040185.html
This patch is still necessary. Doug _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap