Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Message-ID: <e8638002e21df72ccd697b6701a5f10079de4db3.camel@sipsolutions.net>
Subject: Re: Multi-client EAPOL key timeout when not having RTNL lock
 protection
From:   Johannes Berg <johannes@sipsolutions.net>
To:     Sathishkumar Muruganandam <murugana@codeaurora.org>,
        linux-wireless@vger.kernel.org
Date:   Thu, 02 Sep 2021 16:15:30 +0200
In-Reply-To: <6cae54aee83a19dc13e458e4d20e4f28@codeaurora.org>
References: <6cae54aee83a19dc13e458e4d20e4f28@codeaurora.org>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.38.4 (3.38.4-1.fc33) 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: bulk

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