* 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