Re: wifi: ath12k: do not drop data frames from unassociated stations

From: Kalle Valo <kvalo@kernel.org>
To: Hari Chandrakanthan <quic_haric@quicinc.com>
Cc: <quic_kvalo@quicinc.com>,  <ath12k@lists.infradead.org>,
	<linux-wireless@vger.kernel.org>
Subject: Re: wifi: ath12k: do not drop data frames from unassociated stations
Date: Fri, 29 Sep 2023 11:58:45 +0300	[thread overview]
Message-ID: <87y1gp73ui.fsf@kernel.org> (raw)
In-Reply-To: <1689749074-14676-1-git-send-email-quic_haric@quicinc.com> (Hari Chandrakanthan's message of "Wed, 19 Jul 2023 12:14:34 +0530")

(moving from ath11k to ath12k list)

Hari Chandrakanthan <quic_haric@quicinc.com> writes:

>>From 'IEEE Std 802.11-2020 section 11.3.4.1':
> If STA A in an infrastructure BSS receives a Class 2 or Class 3 frame
> from STA B that is not authenticated with STA A
> (i.e., the state for STA B is State 1), STA A shall discard the frame.
> If the frame has an individual address in the Address 1 field,
> the MLME of STA A shall send a Deauthentication frame to STA B.
>
> When data frames from unassociated stations are received by an AP,
> the AP is supposed to send a deauthentication/disassociation frame with
> reason code "Class 2 frame received from nonauthenticated STA" or
> "Class 3 frame received from nonassociated STA".
>
> But ath12k AP doesn't send deauthentication/disassociation frames,
> when it receives data frames from unassociated stations.
>
> The ath12k driver drops the data frames from unassociated
> station and the upper layer(mac80211/hostapd) is not aware of such event.
> Hence deauthentication/disassociation frame is not sent to that
> particular station by the AP.
>
> To address this issue, allow the data frames from the
> unassociated stations to reach mac80211 so that mac80211 can send
> NL80211_CMD_UNEXPECTED_FRAME event to userspace(hostapd) and hostapd
> upon receiving the event will send the deauthentication/disassociation
> frame with proper reason code.
>
> The data frame from unassociated stations gets dropped in mac80211.
>
> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0-02903-QCAHKSWPL_SILICONZ-1
>
> Signed-off-by: Hari Chandrakanthan <quic_haric@quicinc.com>

Heh, I think I found a bug in patchwork. I had a weird problem that
whenever I took this patch from patchwork and applied it using git-am
the commit was empty. The issue seems to be that in mbox format
patchwork doesn't replace "\nFrom " with "\n>From " like all other
software do.

When downloading from patchwork[1]:

[...]
X-Mailing-List: linux-wireless@vger.kernel.org

From 'IEEE Std 802.11-2020 section 11.3.4.1':
If STA A in an infrastructure BSS receives a Class 2 or Class 3 frame
[...]

But from lore[2] it's correct:

[...]
X-Mailing-List: linux-wireless@vger.kernel.org

>From 'IEEE Std 802.11-2020 section 11.3.4.1':
If STA A in an infrastructure BSS receives a Class 2 or Class 3 frame
[...]

No need to resend because of this, the patch will be soon in the pending
branch.

[1] https://patchwork.kernel.org/project/linux-wireless/patch/1689749074-14676-1-git-send-email-quic_haric@quicinc.com/mbox/

[2] https://lore.kernel.org/linux-wireless/1689749074-14676-1-git-send-email-quic_haric@quicinc.com/raw

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

-- 
ath12k mailing list
ath12k@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/ath12k