On Thu, Jul 20, 2023 at 04:21:45PM -0300, Fabio Estevam wrote:
> Let me ask you: what is the impact of reverting 144314eaa7e0
> ("wpa_supplicant: Send EAPOL frames over nl80211
> where available")? What exactly will stop working (what is the
> usecase, system, kernel version)?
The nl80211 control port mechanism is a more convenient approach for
sending and receiving EAPOL frames. It gives more control over the
transmission options and is a better fit for the special frames that are
used for key management and that have rules that do not apply to all
other Data frames. As such, there is significant desire to be able to
use the nl80211 path for EAPOL frames for all cases in the future and
the strongly preferred option here would be to fix the issue that seems
to prevent the TX path through the nl80211 control port in the setup
where you are seeing the issue.
I tried to reproduce this issue with ath10k without much success, i.e.,
the nl80211 control port TX works fine in all my tests. I'm using the
current hostap.git snapshot of wpa_supplicant, though, so it would be
helpful if you could check whether you can reproduce the problem with
the main branch snapshot from hostap.git instead of the v2.10 release.
I do not have an easily available ath10k test setup with an SDIO card,
so that part is different to your environment as well. I would have
hoped this type of a difference to not depend on the PCI vs. SDIO part,
though, but I guess it is possible there could be some other reasons for
seeing different behavior. In any case, I would have expected quite a
bit larger number of reports in this area if this actually were
generically affecting all ath10k-based devices.
--
Jouni Malinen PGP id EFC895FA
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
