13

I have Debian 13 installed with KDE plasma desktop. I noticed that my WiFi latency regularly gets higher for a few seconds, then returns to normal. After some investigation using ping and iw event, I noticed a 100 ms latency spike for 3-5 seconds when iw reports that the scan started. I assume the scan is triggered by the network manager (right?). Can I disable scanning when connected to a WiFi network and enable it otherwise?

Edit: I think most scans are by wpa_supplicant, not Network Manager. I'm using 2.4 GHz WiFi with 20 MHz channel to make it more resistant to interference. I investigated a bit more and noticed that the scans are triggered because the signal at my desk (usually -70 to -80 dBm) is considered too weak by wpa_supplicant so it is trying hard to find a different network. The question then becomes: How to reduce the threshold a bit (to -80 dBm)?

Improve this question
5
  • how often does this happen, and in which frequency band? What kind of wifi network is this – some home router Access point, or a more corporate wifi that supports roaming? Commented Aug 19 at 10:32
  • oh and where concretely are you – this might be DFS ISM in action. Commented Aug 19 at 10:38
  • @MarcusMüller I updated the question with new information. It turns out that wpa_supplicant is triggering excessive scans in the hope to find a better network because the signal is relatively weak. When I get closer the access point no scans are triggered by wpa_supplicant at all. Commented Aug 19 at 12:59
  • "I'm using 2.4 GHz WiFi with 20 MHz channel to make it more resistant to interference", er, what? If you are in an urban setting, the 2.4 GHz band is just crowded. Commented Aug 21 at 15:00
  • @jcaron The "reduce interference" was about the narrower band. A smaller band is less likely to overlap with the bands of other people. And I need 2.4GHz for its large coverage (my internet connection is not even close to saturate the 2.4 GHz 802.11n standard so I'm fine). Commented Aug 21 at 17:21

2 Answers 2

Reset to default
10

After full investigation assisted by the people here, I found a working solution: Reduce the roaming threshold from -70 to -80 dBm using dbus. Using a script that triggers when a new wireless network is connected, we can ensure the setting persists.

Steps:

  1. Copy the following script:

    #!/bin/bash set -e # Run only when an interface is up if [[ "$2" != "up" ]]; then exit 0 fi # Check that the interface that went up is a wireless one if iw dev | grep -wq "$1"; then ALL_NETS="$(busctl tree fi.w1.wpa_supplicant1 | grep -Eo '/fi/w1/wpa_supplicant1/Interfaces/.+/Networks/[[:digit:]]+')" for DBUS_PATH_TO_NET in $ALL_NETS; do busctl call --system \ fi.w1.wpa_supplicant1 \ "$DBUS_PATH_TO_NET" \ org.freedesktop.DBus.Properties Set \ ssv \ fi.w1.wpa_supplicant1.Network Properties \ 'a{sv}' 1 \ bgscan s "simple:30:-80:86400" done fi

  2. Save it as fix_roaming.sh

  3. Make it executable: chmod +x fix_roaming.sh

  4. Copy it to the appropriate Network Manager hooks directory: sudo cp fix_roaming.sh /etc/NetworkManager/dispatcher.d

  5. Done!

You can disconnect from the WiFi and reconnect for the script to execute for the first time or do it manually. Now, your roaming threshold is set to -80 dBm, which should help people far from the access point with no replacements keep reasonable performance. Note: Make sure you have iw and busctl commands available, otherwise the script won't work.

Improve this answer
6

Ah, interesting! Good investigation! That's exactly why I asked for roaming-enabled networks:

That search happens automatically in such networks, because, well, how else would the Wi-Fi device figure out it should switch to the next AP serving the same network :) Now, first measure would usually be to check that this isn't a misconfiguration on your AP's side: if you can, make sure it's not advertising roaming that doesn't exist.

If you can't, or if you need roaming, you can adapt the bgscan parameter in wpa_supplicant's configuration. There's a somewhat-commented example config file (typically, /usr/share/doc/wpa_supplicant/wpa_supplicant.conf); look for the section starting with bgscan: Background scanning). You probably want something like simple:60:-84:600 which means every 60s, it's checked whether the signal strength is below -84 (unitless), and if so, a scan is started.

Improve this answer
8
  • 1
    It seems like the scan is occurring every 6 seconds by default, it proceeds as follows: Signal is weak -> takes 5 seconds to scan across 2.4 and 5 GHz spectrums -> Finds nothing -> waits 6 seconds and tries again... I checked the code of network manager and it is configured to scan only every 30 seconds for roaming. Who is it then the one who is triggering these scans? Commented Aug 19 at 13:30
  • 2
    I couldn't find the file you mentioned on my Debian 13, so I searched some more and found a method to set this directly using DBus, see the last post from here: forums.raspberrypi.com/viewtopic.php?t=385366 Based on this, I raised the threshold to -80 dBm and got rid of the issue. However for some reason wpa_supplicant doesn't seem to honor the timeout between scans properly. Maybe a bug. I wonder how to make that proposed solution persistent, it feels pretty manual... Commented Aug 19 at 13:57
  • @td211 well done! Do you think you could post what you did as an answer here (and accept it later?) That way, future readers will know what works. Commented Aug 19 at 14:31
  • Yes I can do that, after I figure out a way to automate the solution first, because as it stands now, it isn't persistent nor global... I may use some Network Manager hooks to execute a script that auto detects all needed dbus paths and sets the correct bgscan value for all connected networks. I will try to do it asap. @MarcusMüller Commented Aug 19 at 14:46
  • 1
    From what I remember, NetworkManager's bgscan interval depends on whether it is currently connected to a WPA-PSK network or a WPA-Enterprise one; the latter are expected to have dense coverage of APs so the interval is lower, while WPA-Personal gets the opposite default. That might be what overrides your manual bgscan setting. Commented Aug 19 at 16:08

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.