public inbox for linux-wireless@vger.kernel.org
 help / color / mirror / Atom feed
* Missing BEACON_LOSS event
@ 2025-07-29 13:03 Alexander Wilhelm
  2025-07-30  7:52 ` Nicolas Escande
  0 siblings, 1 reply; 3+ messages in thread
From: Alexander Wilhelm @ 2025-07-29 13:03 UTC (permalink / raw)
  To: Jeff Johnson; +Cc: ath11k, linux-wireless

Hello devs,

can someone help with the following issue?

I'm using a QCN9074-based device in STA mode, connected to an access point. When
the AP is powered off (without sending a deauthentication frame), the client
remains indefinitely associated. There is no disconnect, no beacon loss event,
and the RSSI remains stuck at the last known value.

Here is what I see in the logs:

    daemon.debug wpa_supplicant[6960]: nl80211: Drv Event 64 (NL80211_CMD_NOTIFY_CQM) received for wlan0
    daemon.debug wpa_supplicant[6960]: nl80211: Packet loss event for 04:f0:21:bd:63:1f (num_packets 10)
    daemon.debug wpa_supplicant[6960]: wlan0: Event STATION_LOW_ACK (32) received

As a comparison, with an ath10k-based device, I get the expected disconnect sequence:

    daemon.debug wpa_supplicant[5859]: nl80211: Drv Event 64 (NL80211_CMD_NOTIFY_CQM) received for wlan0
    daemon.debug wpa_supplicant[5859]: nl80211: Beacon loss event
    daemon.debug wpa_supplicant[5859]: wlan0: Event BEACON_LOSS (53) received
    daemon.notice wpa_supplicant[5859]: wlan0: CTRL-EVENT-BEACON-LOSS
    daemon.debug wpa_supplicant[5859]: RTM_NEWLINK: ifi_index=13 ifname=wlan0 operstate=33554432 linkmode=16777216 ifi_family=0 ifi_flags=0x1003 ([UP])
    daemon.notice netifd: Network device 'wlan0' link is down
    daemon.notice netifd: Interface 'wlan' has link connectivity loss
    daemon.debug wpa_supplicant[5859]: nl80211: Drv Event 20 (NL80211_CMD_DEL_STATION) received for wlan0
    daemon.debug wpa_supplicant[5859]: nl80211: Delete station 04:f0:21:bd:63:1f
    daemon.debug wpa_supplicant[5859]: nl80211: Drv Event 39 (NL80211_CMD_DEAUTHENTICATE) received for wlan0
    daemon.debug wpa_supplicant[5859]: nl80211: Deauthenticate event
    daemon.debug wpa_supplicant[5859]: wlan0: Event DEAUTH (11) received
    daemon.debug wpa_supplicant[5859]: wlan0: Deauthentication notification
    daemon.debug wpa_supplicant[5859]: wlan0:  * reason 4 (DISASSOC_DUE_TO_INACTIVITY) locally_generated=1
    daemon.debug wpa_supplicant[5859]: wlan0:  * address 04:f0:21:bd:63:1f
    daemon.debug wpa_supplicant[5859]: Deauthentication frame IE(s) - hexdump(len=0): [NULL]
    daemon.notice wpa_supplicant[5859]: wlan0: CTRL-EVENT-DISCONNECTED bssid=04:f0:21:bd:63:1f reason=4 locally_generated=1

From what I can tell, the function `ath11k_mac_handle_beacon_miss()` exists and
is wired up via `ath11k_roam_event()`, but the firmware never seems to send
`WMI_ROAM_EVENTID`, so the handler is never triggered.

Is this expected behavior? Does the firmware need to be configured differently
to enable beacon miss detection in STA mode? Or is this a known limitation? Any
help or clarification would be appreciated.


Best regards
Alexander Wilhelm

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Missing BEACON_LOSS event
  2025-07-29 13:03 Missing BEACON_LOSS event Alexander Wilhelm
@ 2025-07-30  7:52 ` Nicolas Escande
  2025-07-30  9:00   ` Alexander Wilhelm
  0 siblings, 1 reply; 3+ messages in thread
From: Nicolas Escande @ 2025-07-30  7:52 UTC (permalink / raw)
  To: Alexander Wilhelm, Jeff Johnson; +Cc: ath11k, linux-wireless

On Tue Jul 29, 2025 at 3:03 PM CEST, Alexander Wilhelm wrote:
> Hello devs,
>
> can someone help with the following issue?
>
> I'm using a QCN9074-based device in STA mode, connected to an access point. When
> the AP is powered off (without sending a deauthentication frame), the client
> remains indefinitely associated. There is no disconnect, no beacon loss event,
> and the RSSI remains stuck at the last known value.
[...]
> From what I can tell, the function `ath11k_mac_handle_beacon_miss()` exists and
> is wired up via `ath11k_roam_event()`, but the firmware never seems to send
> `WMI_ROAM_EVENTID`, so the handler is never triggered.
>
> Is this expected behavior? Does the firmware need to be configured differently
> to enable beacon miss detection in STA mode? Or is this a known limitation? Any
> help or clarification would be appreciated.

Hello,

I've brought this up already on the ath11k/ath12k list:
https://lore.kernel.org/ath12k/CZA2NS7J83D4.18SU6W9R96KPY@gmail.com/
To my knowlege, nothing upstream has been posted so far by QCA.

In non mainline sources there is a patch to support ath12k:
https://git.codelinaro.org/clo/qsdk/oss/system/feeds/wlan-open/-/blob/win.wlan_host_opensource.3.0/patches/ath12k/897-wifi-ath12k-Add-support-for-STA-mode-to-trigger.patch
My guess is that ath11k works the same way.

It would be great if QCA people could mainline this, it seems like a small
enough and isolated feature that could be pushed without side effects. 

>
>
> Best regards
> Alexander Wilhelm


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Missing BEACON_LOSS event
  2025-07-30  7:52 ` Nicolas Escande
@ 2025-07-30  9:00   ` Alexander Wilhelm
  0 siblings, 0 replies; 3+ messages in thread
From: Alexander Wilhelm @ 2025-07-30  9:00 UTC (permalink / raw)
  To: Nicolas Escande; +Cc: Jeff Johnson, ath11k, linux-wireless

Am Wed, Jul 30, 2025 at 09:52:16AM +0200 schrieb Nicolas Escande:
> On Tue Jul 29, 2025 at 3:03 PM CEST, Alexander Wilhelm wrote:
> > Hello devs,
> >
> > can someone help with the following issue?
> >
> > I'm using a QCN9074-based device in STA mode, connected to an access point. When
> > the AP is powered off (without sending a deauthentication frame), the client
> > remains indefinitely associated. There is no disconnect, no beacon loss event,
> > and the RSSI remains stuck at the last known value.
> [...]
> > From what I can tell, the function `ath11k_mac_handle_beacon_miss()` exists and
> > is wired up via `ath11k_roam_event()`, but the firmware never seems to send
> > `WMI_ROAM_EVENTID`, so the handler is never triggered.
> >
> > Is this expected behavior? Does the firmware need to be configured differently
> > to enable beacon miss detection in STA mode? Or is this a known limitation? Any
> > help or clarification would be appreciated.
> 
> Hello,
> 
> I've brought this up already on the ath11k/ath12k list:
> https://urldefense.com/v3/__https://lore.kernel.org/ath12k/CZA2NS7J83D4.18SU6W9R96KPY@gmail.com/__;!!I9LPvj3b!A_l1xrZCr5Oo1_ZCUkIiXoWPpFN0WLWL0jzZvD_tjkUbOJTC-SHA0CC0HrtcXfPeOOb3729mKsEecEcXslQ0X9e4o9WHOw$ 
> To my knowlege, nothing upstream has been posted so far by QCA.
> 
> In non mainline sources there is a patch to support ath12k:
> https://urldefense.com/v3/__https://git.codelinaro.org/clo/qsdk/oss/system/feeds/wlan-open/-/blob/win.wlan_host_opensource.3.0/patches/ath12k/897-wifi-ath12k-Add-support-for-STA-mode-to-trigger.patch__;!!I9LPvj3b!A_l1xrZCr5Oo1_ZCUkIiXoWPpFN0WLWL0jzZvD_tjkUbOJTC-SHA0CC0HrtcXfPeOOb3729mKsEecEcXslQ0X9dH40t43A$ 
> My guess is that ath11k works the same way.

Thank you for your response, Nicolas. It helps me a lot. Most of the patch code
is already part of `ath11k` driver. I will port the remaining part that
implements the `ath11k_peer_sta_kickout_event` for STA for me until another
firmware/driver solution is proposed.


Best regards
Alexander Wilhelm

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2025-07-30  9:01 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-07-29 13:03 Missing BEACON_LOSS event Alexander Wilhelm
2025-07-30  7:52 ` Nicolas Escande
2025-07-30  9:00   ` Alexander Wilhelm

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox