wpa_supplicant broken with libertas driver since 2.7 (hacky fixes included)

Doug Brown doug at schmorgal.com
Mon Jan 2 15:04:15 PST 2023


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.


More information about the Hostap mailing list