Hi Sathishkumar,
> In the multi-client (64 or higher clients on single radio) test scenario
> of AP mode using hostapd, we are facing EAPOL key timeout for random
> clients.
>
> wlan1: STA 00:41:c0:a8:03:10 WPA: received EAPOL-Key msg 4/4 in invalid
> state (7) – dropped
I think you'll probably have to share a more complete hostapd log, and
likely also send to Jouni/hostap list.
> This is happening due to delay in transmission of association response
> frames for retried association request frames from the client and one of
> the association requests is received when EAPOL key exchange is in
> process.
>
You're talking about the AP, which is transmitting the association
response. How could the AP possibly have sent an EAPOL msg 1/4 before
getting an ACK on the association response? Why are there retries for
this anyway?
> NL80211_CMD_NEW_STATION is received on hostapd when already
> EAPOL M3 is transmitted and waiting for EAPOL M4.
Are you sure this is with an in-kernel driver?
Hostapd should be creating the stations?
> But since hostapd
> received NL80211_CMD_NEW_STATION, it resets the handshake process from
> M1 again by the time client sends M4 to see the above error.
Yeah, but ... why isn't hostapd doing that?
> This delay is seen only after the commit, a05829a7222e ("cfg80211: avoid
> holding the RTNL when calling the driver") and not seen before/without
> this commit. We could see delay in processing of nl80211_get_key,
> nl80211_set_key, nl80211_new_key, nl80211_del_key and nl80211_tx_mgmt
> commands.
>
> The delay and EAPOL key timeout is not seen when NL80211_FLAG_NEED_RTNL
> is set back to internal_flags of nl80211_get_key, nl80211_set_key,
> nl80211_new_key, nl80211_del_key and nl80211_tx_mgmt messages alone.
>
> Please share your comments on this issue requiring RTNL lock for key and
> mgmt nl80211 commands.
Not going to happen, you need to find the real cause of this.
johannes
