[PATCH] Revert "wpa_supplicant: Send EAPOL frames over nl80211 where available"

[Fabio Estevam]

Hi Jouni,

On Fri, Jul 21, 2023 at 7:04 AM Jouni Malinen <j at w1.fi> 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