Hi Jouni, On Fri, Jul 21, 2023 at 7:04 AM Jouni Malinen <j@xxxxx> wrote: > 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. Thanks for the explanation. > 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. When I reported the issue last month, I also tried running the main branch snapshot from hostap.git and it also failed. Today I tried it again against top of head: 96deacf5d71022b263a27113de52c1f13efdd6ec and Wifi is functional on QCA9377! It looks like there is a recent commit in the main branch that fixed the problem. Do you have any suggestion as to what this commit could be? I would like to get v2.10 fixed as well. Thanks a lot _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
