Journal logs spammed with CTRL-EVENT-SCAN-FAILED

I’m not sure when it started, but I’m being constantly bombarded with

wpa_supplicant[1917]: wlp4s0: CTRL-EVENT-SCAN-FAILED ret=-22

In my journal logs. Which is accumulating really fast:

» journalctl | grep "CTRL-EVENT-SCAN-FAILED" | wc -l

40375


I currently use an AX200 :

04:00.0 Network controller: Intel Corporation Wi-Fi 6 AX200 (rev 1a)
Subsystem: Intel Corporation Wi-Fi 6 AX200NGW
Kernel driver in use: iwlwifi
Kernel modules: iwlwifi

And I haven’t touched my network config from the NixOS (unstable variant) defaults beyond manually enabling networkmanager (though the GNOME config already sets that, wpa_supplicant is used as the backend) and using dnscrypt with the wiki recommended setup (disabling it makes no difference).

The error “seems” harmless, because I can still view, connect and interact with networks just fine from the GNOME settings panel, so my guess its that it is related to active scanning, like the one mentioned in:

NetworkManager[151159]: <warn> [1732054149.8691] device (wlp4s0): wifi-scan: active scanning for networks due to profiles with wifi.hidden=yes. This makes you trackable

Though I’ve never enabled that explicitly.

I haven’t been able to find this exact issue while searching for the error it prints out. Does anyone have pointers that might help in diagnosing this?

I am also having similar (CTRL-EVENT-SIGNAL-CHANGE instead) spamming now happening on my machines.

the journal/log is being spammed with these messages.

Dec 19 09:56:49 myPC wpa_supplicant[4090]: wlp2s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-53 noise=9999 txrate=1080600
Dec 19 09:56:52 myPC wpa_supplicant[4090]: wlp2s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-53 noise=9999 txrate=1080600
Dec 19 09:56:55 myPC wpa_supplicant[4090]: wlp2s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-48 noise=9999 txrate=1080600
Dec 19 09:56:59 myPC wpa_supplicant[4090]: wlp2s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-54 noise=9999 txrate=1080600
Dec 19 09:57:02 myPC wpa_supplicant[4090]: wlp2s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-48 noise=9999 txrate=1080600
Dec 19 09:57:05 myPC wpa_supplicant[4090]: wlp2s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-54 noise=9999 txrate=960700
Dec 19 09:57:08 myPC wpa_supplicant[4090]: wlp2s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-53 noise=9999 txrate=1200900
Dec 19 09:57:11 myPC wpa_supplicant[4090]: wlp2s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-48 noise=9999 txrate=1080600
Dec 19 09:57:14 myPC wpa_supplicant[4090]: wlp2s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-53 noise=9999 txrate=1080600
Dec 19 09:57:17 myPC wpa_supplicant[4090]: wlp2s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-53 noise=9999 txrate=1080600
Dec 19 09:57:20 myPC wpa_supplicant[4090]: wlp2s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-54 noise=9999 txrate=1080600
Dec 19 09:57:23 myPC wpa_supplicant[4090]: wlp2s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-54 noise=9999 txrate=1080600
Dec 19 09:57:26 myPC wpa_supplicant[4090]: wlp2s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-53 noise=9999 txrate=1080600
Dec 19 09:57:29 myPC wpa_supplicant[4090]: wlp2s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-53 noise=9999 txrate=1080600
Dec 19 09:57:32 myPC wpa_supplicant[4090]: wlp2s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-53 noise=9999 txrate=1080600
D

I am unsure how to edit /etc/systemd/system/wpa_supplicant.service with an override to adjust the noise level for it ie. adding LogLevelMax=4 (warning) or maybe 3 (error)

EDIT: This started after upgrading to the latest linux 6.12 (was on 6.6.66 before) if that’s any help. currently I’m on Linux myPC 6.12.2-zen1 #1-NixOS ZEN SMP PREEMPT_DYNAMIC

Same here. Was on default kernel version 24.11 switched to latest.

This is a kernel thing. I just switched to default kernel. Nothing happen.

Log level >= info would be a workaround.

Was a long way to find out what can I do. Now I patch wpa_supplicant to be quiet.

diff --git a/wpa_supplicant/systemd/wpa_supplicant.service.in b/wpa_supplicant/systemd/wpa_supplicant.service.in
index 58a6228..fbe7de3 100644
--- a/wpa_supplicant/systemd/wpa_supplicant.service.in
+++ b/wpa_supplicant/systemd/wpa_supplicant.service.in
@@ -7,7 +7,7 @@ Wants=network.target
 [Service]
 Type=dbus
 BusName=fi.w1.wpa_supplicant1
-ExecStart=@BINDIR@/wpa_supplicant -u
+ExecStart=@BINDIR@/wpa_supplicant -u -q
 
 [Install]
 WantedBy=multi-user.target

1 Like

I’ve been staring at this on how to override this nixpkgs/nixos/modules/services/networking/wpa_supplicant.nix at 371e69dcca43f7a1d79b069da19568107165099e · NixOS/nixpkgs · GitHub

I can’t think of any clean way. @benitosmash what were you thinking of doing?

This is used, when you do not use gnome as a DE and configures the package by yourself.

This would than be used nixpkgs/pkgs/os-specific/linux/wpa_supplicant/default.nix at 371e69dcca43f7a1d79b069da19568107165099e · NixOS/nixpkgs · GitHub

I add the patch in my flake.nix.

       pkgs = import nixpkgs {
        system = "${systemSettings.system}";
        overlays = [
          (finalAttrs: previousAttrs: {
            wpa_supplicant = previousAttrs.wpa_supplicant.overrideAttrs (old: {
              patches = old.patches ++ [
                  ./patches/wpa_supplicant-quiet.patch
              ];
            });
          })
        ];
      };
1 Like

@benitosmash yes, this is a good solution, but I feel there has to be a better way.

I’m meh about keeping patches like this as it litters my configs.

This is what I use:

{ lib, config, ... }: let
  cfg = config.networking.wireless;
  override.serviceConfig.LogLevelMax = "warning";
in lib.mkIf cfg.enable {
  systemd.services =
    if cfg.interfaces == [ ]
    then { wpa_supplicant = override; }
    else lib.listToAttrs (map (i: lib.nameValuePair "wpa_supplicant-${i}" override) cfg.interfaces);
}
1 Like

@rvl very nice! This is clean. Thanks.

This log message is fixed upstream. Send CTRL-EVENT-SIGNAL-CHANGE message to control interfaces only - hostap - hostapd/wpa_supplicant

1 Like

You wouldnt know how to apply this patch perhaps? 2.11 is the latest in both 24.11 and unstable unfortunately.