Client-mode: CTRL-EVENT-BEACON-LOSS

Hi,
does anybody know what could be causing these CTRL-EVENT-BEACON-LOSS notices in the log?

device is a Xiaomi mini running OpenWrt 19.07.2, r10947-65030d81f3
configured as a client using the 2.4Ghz radio, the wireless link itself should be fine:

      Mode: Client  Channel: 3 (2.422 GHz)
      Tx-Power: 20 dBm  Link Quality: 57/70
      Signal: -53 dBm  Noise: unknown
      Bit Rate: 43.3 MBit/s
      Encryption: WPA2 PSK (CCMP)
      Type: nl80211  HW Mode(s): 802.11bgn
      Hardware: [MediaTek MT7620]

(logs on the access point, also running openwrt, show nothing out of the ordinary).

burst of these can last anywhere from a couple of seconds to 5 minutes.

any help would be much appreciated.

> Thu Apr  9 20:47:40 2020 daemon.notice wpa_supplicant[22034]: wlan1: CTRL-EVENT-BEACON-LOSS
> Thu Apr  9 20:47:45 2020 daemon.notice wpa_supplicant[22034]: wlan1: CTRL-EVENT-BEACON-LOSS
> Thu Apr  9 20:47:49 2020 daemon.notice wpa_supplicant[22034]: wlan1: CTRL-EVENT-BEACON-LOSS
> Thu Apr  9 20:47:53 2020 daemon.notice wpa_supplicant[22034]: wlan1: CTRL-EVENT-BEACON-LOSS
> Thu Apr  9 20:47:56 2020 daemon.notice wpa_supplicant[22034]: wlan1: CTRL-EVENT-BEACON-LOSS
> Thu Apr  9 20:47:58 2020 daemon.notice wpa_supplicant[22034]: wlan1: CTRL-EVENT-BEACON-LOSS
> Thu Apr  9 20:47:59 2020 daemon.notice wpa_supplicant[22034]: wlan1: CTRL-EVENT-BEACON-LOSS
> Thu Apr  9 20:48:01 2020 daemon.notice wpa_supplicant[22034]: wlan1: CTRL-EVENT-BEACON-LOSS
> Thu Apr  9 20:48:02 2020 daemon.notice wpa_supplicant[22034]: wlan1: CTRL-EVENT-BEACON-LOSS
> Thu Apr  9 20:48:03 2020 daemon.notice wpa_supplicant[22034]: wlan1: CTRL-EVENT-BEACON-LOSS
> Thu Apr  9 20:48:05 2020 daemon.notice wpa_supplicant[22034]: wlan1: CTRL-EVENT-BEACON-LOSS
> Thu Apr  9 20:48:08 2020 daemon.notice wpa_supplicant[22034]: wlan1: CTRL-EVENT-BEACON-LOSS
> Thu Apr  9 20:48:09 2020 daemon.notice wpa_supplicant[22034]: wlan1: CTRL-EVENT-BEACON-LOSS
> Thu Apr  9 20:48:10 2020 daemon.notice wpa_supplicant[22034]: wlan1: CTRL-EVENT-BEACON-LOSS
> Thu Apr  9 20:48:16 2020 daemon.notice wpa_supplicant[22034]: wlan1: CTRL-EVENT-BEACON-LOSS
> Thu Apr  9 20:48:18 2020 daemon.notice wpa_supplicant[22034]: wlan1: CTRL-EVENT-BEACON-LOSS

Hi, please help I got the same problem. I bridge the TD-W8970 (OpenWrt 19.07.2 r10947-65030d81f3 ) with my primary router. I don’t have any problem with my wifi , but this annoying message flooding the System Log. Anyone knows how I can disable this message? I changed the log_level to 4 but with no luck.

root@TP-LINK:~# iw dev wlan0 station dump
Station ec:f0:fe:a4:06:a0 (on wlan0)
        inactive time:  4 ms
        rx bytes:       19474500474
        rx packets:     26673482
        tx bytes:       26463045857
        tx packets:     23389683
        tx retries:     5161763
        tx failed:      2886
        beacon loss:    661
        beacon rx:      1523424
        rx drop misc:   240733
        signal:         -48 [-58, -55, -52] dBm
        signal avg:     -48 [-60, -54, -52] dBm
        beacon signal avg:      -49 dBm
        tx bitrate:     240.0 MBit/s MCS 13 40MHz short GI
        rx bitrate:     300.0 MBit/s MCS 15 40MHz short GI
        rx duration:    0 us
        last ack signal:43 dBm
        expected throughput:    44.677Mbps
        authorized:     yes
        authenticated:  yes
        associated:     yes
        preamble:       long
        WMM/WME:        yes
        MFP:            no
        TDLS peer:      no
        DTIM period:    1
        beacon interval:100
        short preamble: yes
        short slot time:yes
        connected time: 176581 seconds

Please also post together the logs that come immediately before CTRL-EVENT-BEACON-LOSS

Hello guys,

I also am experiencing this with my Xiaomi 4A 100M when I made it as a WDS Bridged Repeater. On related logs on my main router which is also using OpenWRT.

It seems that this happens if there are no activity on it after an hour or so, some kind of power saving/sleep mode on the wifi. So right now, i'm testing if having a sudo keepalive using PING will keep this from happening. I'll probably know in few days if the message still appears.

I've added the following in the scheduled task:

0 */1 * * * ping -c 1 dns.google

Let us know if someone find the reason. I've upgraded two WDS connections (4 routers total - 740N, 841N) to 19.07.5 and now I see the message in the log of the client (WDS) router. Previous version 18.06.8 and lower were free of this message.

I'm seeing the same thing on a TP-Link TL-WR1043ND v1 WDS client connecting to a TP-Link Archer C7 v2 AP. They're both on OpenWrt 19.07.3. I use this for the TV box and there are short video pauses caused by this until the connection reestablishes, so it's not just from idle connections.

Found this bug which seems related:

It may be a powersaving issue that causes missed beacons.

Also seeing this in my logs as well.

Wed May 18 13:05:44 2022 daemon.notice wpa_supplicant[1397]: wlan1: CTRL-EVENT-BEACON-LOSS
Wed May 18 13:05:50 2022 daemon.notice wpa_supplicant[1397]: wlan1: CTRL-EVENT-BEACON-LOSS
Wed May 18 13:05:52 2022 daemon.notice wpa_supplicant[1397]: wlan1: CTRL-EVENT-BEACON-LOSS
Wed May 18 13:05:59 2022 daemon.notice wpa_supplicant[1397]: wlan1: CTRL-EVENT-BEACON-LOSS
Wed May 18 13:06:00 2022 daemon.notice wpa_supplicant[1397]: wlan1: CTRL-EVENT-BEACON-LOSS
Wed May 18 13:06:01 2022 daemon.notice wpa_supplicant[1397]: wlan1: CTRL-EVENT-BEACON-LOSS
Wed May 18 13:06:03 2022 daemon.notice wpa_supplicant[1397]: wlan1: CTRL-EVENT-BEACON-LOSS
Wed May 18 13:06:05 2022 daemon.notice wpa_supplicant[1397]: wlan1: CTRL-EVENT-BEACON-LOSS
Wed May 18 13:06:07 2022 daemon.notice wpa_supplicant[1397]: wlan1: CTRL-EVENT-BEACON-LOSS
Wed May 18 13:06:09 2022 daemon.notice wpa_supplicant[1397]: wlan1: CTRL-EVENT-BEACON-LOSS
Wed May 18 13:06:10 2022 daemon.notice wpa_supplicant[1397]: wlan1: CTRL-EVENT-BEACON-LOSS
Wed May 18 13:06:11 2022 daemon.notice wpa_supplicant[1397]: wlan1: CTRL-EVENT-BEACON-LOSS
Wed May 18 13:07:11 2022 daemon.warn wpa_supplicant[1397]: wlan1: Undefined secondary channel: drop OBSS scan results
Wed May 18 13:12:11 2022 daemon.warn wpa_supplicant[1397]: wlan1: Undefined secondary channel: drop OBSS scan results
Wed May 18 13:17:11 2022 daemon.warn wpa_supplicant[1397]: wlan1: Undefined secondary channel: drop OBSS scan results

Device: TP-LINK EAP225 Outdoor v1
Firmware: OpenWrt 21.02.0 r16279-5cc0535800 / LuCI openwrt-21.02 branch git-21.231.26241-422c175

1 Like

I see rashes of these. They have been there for a long time, can't remember what version they started with been there since router was installed... with probably Barrier Breaker. I've tried to make them go away with wifi tweaks but if anything I've made it worse. Just reflashed to 21.02.3 and issue is still there.

Router is in a tough spot so reception is not great:

wlan1     ESSID: 
          Access Point: 
          Mode: Client  Channel: 149 (5.745 GHz)
          Center Channel 1: 151 2: unknown
          Tx-Power: 17 dBm  Link Quality: 45/70
          Signal: -65 dBm  Noise: -95 dBm
          Bit Rate: 240.0 MBit/s
          Encryption: WPA2 PSK (CCMP)
          Type: nl80211  HW Mode(s): 802.11an
          Hardware: XXXX:XXXX XXXX:XXXX [Atheros AR9220]
          TX power offset: none
          Frequency offset: none
          Supports VAPs: yes  PHY name: phy1

2.4GHz is crowded in the area so we use 5GHz.

I can see... maybe 200+ of these a day? They happen in clusters:

Wed May 18 00:45:19 2022 daemon.notice wpa_supplicant[1699]: wlan1: CTRL-EVENT-BEACON-LOSS
--18 more of them--
Wed May 18 00:46:37 2022 daemon.notice wpa_supplicant[1699]: wlan1: CTRL-EVENT-BEACON-LOSS
Wed May 18 02:27:24 2022 daemon.notice wpa_supplicant[1699]: wlan1: CTRL-EVENT-BEACON-LOSS
--10 more of them--
Wed May 18 02:28:25 2022 daemon.notice wpa_supplicant[1699]: wlan1: CTRL-EVENT-BEACON-LOSS
Wed May 18 08:00:46 2022 daemon.notice wpa_supplicant[1699]: wlan1: CTRL-EVENT-BEACON-LOSS
--9 more---
Wed May 18 08:01:51 2022 daemon.notice wpa_supplicant[1699]: wlan1: CTRL-EVENT-BEACON-LOSS
Wed May 18 10:33:53 2022 daemon.notice wpa_supplicant[1699]: wlan1: CTRL-EVENT-BEACON-LOSS

They cause traffic to queue up until router reconnects. Very annoying.

Never thought it could be a "sleep" issue... I'll try the ping trick.

1 Like

Ping doesn't help. Or doesn't help much.

It's a kernel problem. Seems on track to be cleaned up on kernel 5.15+.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bddac7c1e02ba47f0570e494c9289acea3062cc1
Anybody know if OpenWRT would include that as a patch for v22? Probably too late. If I figure out how to open an issue I'll put it there.

1 Like

Seems issue can be fixed at kernel level (which would help many drivers beyond ath9k) or on the ath9k driver. I'll try test that, as it is less intrusive:
https://lore.kernel.org/stable/8043549.T7Z3S40VBb@natalenko.name/
Funny bunch the kernel maintainers (including Linus Torvalds himself in thread above!).

1 Like

Have an ASUS RT-AC58U as the AP and a TP-Link Archer C7 v5 as the client - following this guide.

CTRL-EVENT-BEACON-LOSS is flooding the Archer C7 v5, ending up loss of connection with the RT-AC58U and needing a reboot at least once a day. Both are on OpenWrt 22.03.0 r19685, and I have tried reversing their roles too - the client invariably loses connectivity with a deluge of this in the log.

Considering these builds are still on 5.10.138, is there any workaround (like disabling powersave) - or can the relevant patches be cherry-picked from 5.15.x?

Update after a little experimenting - turning off 802.11r and KRACK, and setting beacon interval to 2999 in the AP seems to have gotten rid of this.

But the connection between the AP and Client getting dropped once a day - that still occurs, assuming that is not related to the BEACON_LOSS messages in the log...