ath12k & ath11k beacon miss detection

ath12k & ath11k beacon miss detection

[Nicolas Escande]

Hi there,

I found that when using QCN9274 iun station mode, we never get disconnected from
the AP even if it stops beaconning. Using iw I can see the "inactive time"
increasing without supplicant ever getting a beacon miss event.

From what I gathered, given we set the flag CONNECTION_MONITOR using
ieee80211_hw_set in __ath12k_mac_register (mac.c) we should detect the
connection loss and call ieee80211_connection_loss() at some point. Right now,
there is no such mecanism in ath12k.

So looking at ath11k code I found out that in that driver we have a specific
WMI event "WMI_ROAM_EVENTID" that can report a WMI_ROAM_REASON_BEACON_MISS that
in turn ends up calling ieee80211_beacon_loss after some time.

But trying ath11k & qcn9074 in station mode yielded the same result, we never
get the roam event and never get disconnected either.

So going back to ath10k this time, the code isn't exactly the same but even then
we had the same wmi event, with the same WMI_ROAM_REASON_BEACON_MISS and we'd
call ath10k_mac_handle_beacon_miss which in turn ends up calling
ieee80211_beacon_loss via a work item.

And using ath10k on qca9888 works well for me.

So I have a few questions:
  - is this supposed to work on ath11k ? Does it not work for me specifically
    because of my chipset ? Or are we missing some wmi config ?
  - as the code to handle the roam event is missing/commented out in ath12k will
    it be a different mecanism to detect connection loss ? Or it'll be the same
    and you guys just did not have time yet to tackle this ?

I'm happy to add the missing code to fix that use case in both drivers but I'll
need some insight from you ath folks on this.

Thanks  

Re: ath12k & ath11k beacon miss detection

[Jeff Johnson]

On 2/20/2024 9:11 AM, Nicolas Escande wrote:
> Hi there,
> 
> I found that when using QCN9274 iun station mode, we never get disconnected from
> the AP even if it stops beaconning. Using iw I can see the "inactive time"
> increasing without supplicant ever getting a beacon miss event.
> 
> From what I gathered, given we set the flag CONNECTION_MONITOR using
> ieee80211_hw_set in __ath12k_mac_register (mac.c) we should detect the
> connection loss and call ieee80211_connection_loss() at some point. Right now,
> there is no such mecanism in ath12k.
> 
> So looking at ath11k code I found out that in that driver we have a specific
> WMI event "WMI_ROAM_EVENTID" that can report a WMI_ROAM_REASON_BEACON_MISS that
> in turn ends up calling ieee80211_beacon_loss after some time.
> 
> But trying ath11k & qcn9074 in station mode yielded the same result, we never
> get the roam event and never get disconnected either.
> 
> So going back to ath10k this time, the code isn't exactly the same but even then
> we had the same wmi event, with the same WMI_ROAM_REASON_BEACON_MISS and we'd
> call ath10k_mac_handle_beacon_miss which in turn ends up calling
> ieee80211_beacon_loss via a work item.
> 
> And using ath10k on qca9888 works well for me.
> 
> So I have a few questions:
>   - is this supposed to work on ath11k ? Does it not work for me specifically
>     because of my chipset ? Or are we missing some wmi config ?
>   - as the code to handle the roam event is missing/commented out in ath12k will
>     it be a different mecanism to detect connection loss ? Or it'll be the same
>     and you guys just did not have time yet to tackle this ?
> 
> I'm happy to add the missing code to fix that use case in both drivers but I'll
> need some insight from you ath folks on this.

The ath12k driver is still work-in-progress and there is quite a bit of
functionality missing there due to the refactoring to handle 802.11be
Multi-Link Operation. However I'm surprised that ath11k has this issue.
I've asked the development team to look at this. It would be helpful for
you to open a bug to track the issue. Please see
<https://wireless.wiki.kernel.org/en/users/drivers/ath11k/bugreport>.

Thanks!
/jeff

Re: ath12k & ath11k beacon miss detection

[Kalle Valo]

"Nicolas Escande" <nico.escande@gmail.com> writes:

> Hi there,
>
> I found that when using QCN9274 iun station mode, we never get disconnected from
> the AP even if it stops beaconning. Using iw I can see the "inactive time"
> increasing without supplicant ever getting a beacon miss event.
>
>>From what I gathered, given we set the flag CONNECTION_MONITOR using
> ieee80211_hw_set in __ath12k_mac_register (mac.c) we should detect the
> connection loss and call ieee80211_connection_loss() at some point. Right now,
> there is no such mecanism in ath12k.
>
> So looking at ath11k code I found out that in that driver we have a specific
> WMI event "WMI_ROAM_EVENTID" that can report a WMI_ROAM_REASON_BEACON_MISS that
> in turn ends up calling ieee80211_beacon_loss after some time.
>
> But trying ath11k & qcn9074 in station mode yielded the same result, we never
> get the roam event and never get disconnected either.
>
> So going back to ath10k this time, the code isn't exactly the same but even then
> we had the same wmi event, with the same WMI_ROAM_REASON_BEACON_MISS and we'd
> call ath10k_mac_handle_beacon_miss which in turn ends up calling
> ieee80211_beacon_loss via a work item.
>
> And using ath10k on qca9888 works well for me.
>
> So I have a few questions:
>   - is this supposed to work on ath11k ? Does it not work for me specifically
>     because of my chipset ?

Just a generic comment: QCN9074 and QCN9274 chipsets are designed for AP
use cases and their firmware tends to be lacking on station mode
features.

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

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

Re: ath12k & ath11k beacon miss detection

[Nicolas Escande]

On Wed Feb 21, 2024 at 1:46 AM CET, Jeff Johnson wrote:
[...]
>
> The ath12k driver is still work-in-progress and there is quite a bit of
> functionality missing there due to the refactoring to handle 802.11be
> Multi-Link Operation. However I'm surprised that ath11k has this issue.
> I've asked the development team to look at this. It would be helpful for
> you to open a bug to track the issue. Please see
> <https://wireless.wiki.kernel.org/en/users/drivers/ath11k/bugreport>.

Yeah I fugured as much for ath12k so I thought I try to do as it was done in
ath11k and that's how I found out it wasn't working either there.

Thanks for having your guys looking into it, in the mean time here is a link to
the bug report on buzilla https://bugzilla.kernel.org/show_bug.cgi?id=218522

I'll be happy to test anything you can throw at me on this

> Thanks!
> /jeff

Re: ath12k & ath11k beacon miss detection

[Nicolas Escande]

On Wed Feb 21, 2024 at 8:02 AM CET, Kalle Valo wrote:
[...]
>
> Just a generic comment: QCN9074 and QCN9274 chipsets are designed for AP
> use cases and their firmware tends to be lacking on station mode
> features.

Yeah I know full station mode is not to be expected on thoses chipsets but we
do use them as such for a short period of time on our product...
We just need basic connectivity for a few seconds.

Re: ath12k & ath11k beacon miss detection

[Kalle Valo]

"Nicolas Escande" <nico.escande@gmail.com> writes:

> On Wed Feb 21, 2024 at 8:02 AM CET, Kalle Valo wrote:
> [...]
>>
>> Just a generic comment: QCN9074 and QCN9274 chipsets are designed for AP
>> use cases and their firmware tends to be lacking on station mode
>> features.
>
> Yeah I know full station mode is not to be expected on thoses chipsets but we
> do use them as such for a short period of time on our product...
> We just need basic connectivity for a few seconds.

Yeah, I understand that. I was just trying to warn you. In my opinion
the station modes should be properly implemented and tested as well.

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

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

Re: ath12k & ath11k beacon miss detection

[Nicolas Escande]

On Wed Feb 21, 2024 at 1:46 AM CET, Jeff Johnson wrote:
[...]
> The ath12k driver is still work-in-progress and there is quite a bit of
> functionality missing there due to the refactoring to handle 802.11be
> Multi-Link Operation. However I'm surprised that ath11k has this issue.
> I've asked the development team to look at this. It would be helpful for
> you to open a bug to track the issue. Please see
> <https://wireless.wiki.kernel.org/en/users/drivers/ath11k/bugreport>.
>
> Thanks!
> /jeff

Hi Jeff,

Any news from the developement team ? Is this something that got into their
backlog, or even better, got a chance to be looked into ? I'm sure if we tackle
it on either ath 11k or 12k the other one will be trivial to fix.

Thanks anyway !

Re: ath12k & ath11k beacon miss detection

[Jeff Johnson]

On 3/15/2024 3:06 AM, Nicolas Escande wrote:
> On Wed Feb 21, 2024 at 1:46 AM CET, Jeff Johnson wrote:
> [...]
>> The ath12k driver is still work-in-progress and there is quite a bit of
>> functionality missing there due to the refactoring to handle 802.11be
>> Multi-Link Operation. However I'm surprised that ath11k has this issue.
>> I've asked the development team to look at this. It would be helpful for
>> you to open a bug to track the issue. Please see
>> <https://wireless.wiki.kernel.org/en/users/drivers/ath11k/bugreport>.
>>
>> Thanks!
>> /jeff
> 
> Hi Jeff,
> 
> Any news from the developement team ? Is this something that got into their
> backlog, or even better, got a chance to be looked into ? I'm sure if we tackle
> it on either ath 11k or 12k the other one will be trivial to fix.

Yes, there is an ath12k patch under internal review and test. Hope it will
reach the list soon.

/jeff

Re: ath12k & ath11k beacon miss detection

[Nicolas Escande]

On Fri Mar 15, 2024 at 8:55 PM CET, Jeff Johnson wrote:
[...]
> > Hi Jeff,
> > 
> > Any news from the developement team ? Is this something that got into their
> > backlog, or even better, got a chance to be looked into ? I'm sure if we tackle
> > it on either ath 11k or 12k the other one will be trivial to fix.
>
> Yes, there is an ath12k patch under internal review and test. Hope it will
> reach the list soon.
>
> /jeff

Great news. Thanks !