Received-SPF: pass (google.com: domain of linux-wireless+bounces-3966-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Message-ID: <3cd77b50-f681-4b74-bdaa-6e2bd73ad744@gmail.com>
Date: Fri, 23 Feb 2024 08:13:27 -0800
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: ath11k multicast action frame RX
Content-Language: en-US
To: Baochen Qiang <quic_bqiang@quicinc.com>,
 "open list:MEDIATEK MT76 WIRELESS LAN DRIVER"
 <linux-wireless@vger.kernel.org>, ath11k@lists.infradead.org
References: <dcdbd757-ad6e-4fe0-a0c1-fe328431b73b@locusrobotics.com>
 <642b61a6-e3c0-4831-887f-f25314bf166d@locusrobotics.com>
 <90ac3bdc-8797-4d57-8bc9-48e0ad406674@quicinc.com>
 <1dafe0e5-292b-4764-86c7-cc1757aeb3b6@gmail.com>
 <ed8eeb92-e1eb-445e-989d-2340c26faf44@quicinc.com>
 <7a62031b-ad1f-4da2-8217-19a5d7fdc0f4@gmail.com>
 <f363f179-b41f-4bea-882f-e4aacb8ad519@quicinc.com>
 <eaeb8e9b-3809-4f89-a5b2-7949aa01fbde@gmail.com>
 <026d9ba3-525d-4a12-8d03-5fece818330c@quicinc.com>
 <0e8ad2c2-cc39-4903-97f7-c3ffb525e61a@gmail.com>
 <df35ce71-84dd-4c2c-af9a-820cb9a71291@quicinc.com>
From: James Prestwood <prestwoj@gmail.com>
In-Reply-To: <df35ce71-84dd-4c2c-af9a-820cb9a71291@quicinc.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Baochen

On 2/22/24 5:56 PM, Baochen Qiang wrote:
>
>
> On 2/22/2024 11:38 PM, James Prestwood wrote:
>> Hi Baochen,
>>
>> On 2/21/24 6:26 PM, Baochen Qiang wrote:
>>> But you are using monitor mode, not station mode, on ath10k, right? 
>>
>> No I'm using station mode. It looks like ath10k creates a monitor 
>> device to receive these frames (that was already done before my 
>> patch), but the interface I'm using from userspace is a regular 
>> station interface
>>
> OK let's forget what ath10k does to receiver those frames for now and 
> focus on ath11k. From what I got from firmware team, it's expected 
> that ath11k station interface can't get those frame without a scan 
> because device A is connected to an AP already and is supposed to get 
> frames only from within the BSS, apparently device B here is not 
> within that BSS.
>
I still don't know why a scan would change anything. Maybe the act of 
scanning triggers something in the firmware to allow the RX of multicast 
frames (like to receive probe responses)? If so that's not really a 
mechanism to enable multicast RX, its just a side effect of scanning.

But yes currently when an ath11k device is connected to a BSS it will 
only receive frames from within that BSS. This is what I was attempting 
to change, allow it to receive multicast action frames while connected 
(or disconnected for that matter).

The whole point of DPP is to provision a new device. So one device is 
offline and asking the connected device for credentials. This is done 
via multicast action frames.

Thanks,

James

>> Thanks,
>>
>> James
>>