Received-SPF: pass (google.com: domain of linux-wireless+bounces-2783-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Message-ID: <90ac3bdc-8797-4d57-8bc9-48e0ad406674@quicinc.com>
Date: Tue, 30 Jan 2024 15:00:02 +0800
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: ath11k multicast action frame RX
Content-Language: en-US
To: James Prestwood <jprestwood@locusrobotics.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>
From: Baochen Qiang <quic_bqiang@quicinc.com>
In-Reply-To: <642b61a6-e3c0-4831-887f-f25314bf166d@locusrobotics.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit


On 1/27/2024 3:18 AM, James Prestwood wrote:
> On 1/24/24 5:06 AM, James Prestwood wrote:
> 
>> Hi,
>>
>> I recently added support to ath10k, for the QCA6174, to receive 
>> multicast action frames in order to support DPP. I'm trying to do this 
>> for the ath11k QCNFA765/WCN6855. I took the same approach as ath10k 
>> which was actually quite simple but I'm unable to see any multicast 
>> frames coming over even when I enable RX/DATA debugging.
>>
>> What I've done so far is:
>>
>>  - Add FIF_MCAST_ACTION to the supported filters list
>>
>>  - Created/started a monitor vdev from within 
>> ath11k_mac_op_configure_filter()
>>
>>     ath11k_mac_monitor_vdev_create(ar);
>>
>>     ath11k_mac_monitor_start(ar);
>>
>> - Also tried adding
>>
>>     ath11k_mac_config_mon_status_default(ar, true);
>>
>> I can successfully create/start the monitor vdev. I see now as I'm 
>> writing this email that my specific hardware does not support monitor 
>> mode outright... Is this a dead end or is there hope with purely 
>> driver changes? or is it some filtering at the firmware level 
>> preventing this?
> 
> I was able to finally see my broadcast frame after some additional 
> testing. It seems the driver/firmware/something gets a bit hung up when 
> I attempt to put it in monitor mode. It will start printing these 
> messages for about a minute:
> 
> [   51.093034] ath11k_pci 0000:00:06.0: data dest_rx: new ppdu_id a1a2 
> != status ppdu_id a1a1 dest_mon_not_reaped = 650 dest_mon_stuck = 12
> [   51.094461] ath11k_pci 0000:00:06.0: data dest_rx: new ppdu_id a1a3 
> != status ppdu_id a1a2 dest_mon_not_reaped = 651 dest_mon_stuck = 12
> [   51.096281] ath11k_pci 0000:00:06.0: data dest_rx: new ppdu_id a1a5 
> != status ppdu_id a1a3 dest_mon_not_reaped = 652 dest_mon_stuck = 12
> 
> In most cases these ppdu ID's are a one-off from the expected ID which 
> seemed weird to me. But if I let it sit long enough I all of a sudden 
> get a ton of "data rx" messages, which is what I would expect if I 
> enabled a monitor vdev. Once this flurry starts I see the action frame 
> from my other client, sometimes at least. The firmware generally crashes 
> after a while so I've still got a ways to go but it seems within the 
> realm of possibility that this device could receive broadcast action 
> frames?
> 
> Hoping for some breadcrumbs to follow here...
> 
Hi James, as you already mentioned, ath11k/WCN6855 doesn't support 
monitor mode yet. I don't know why you are testing multicast action 
frame with monitor mode. So if monitor mode is not a must, could you 
test this with STATION mode? We would look into this if any issue found.

> Thanks,
> 
> James
> 
>>
>> Thanks,
>>
>> James
>>
>>