geoclue polls wpasupplicant SSID list too often, resulting in lag and packet loss

[Kevin Keijzer]

Steps to reproduce:

1. Install GNOME Weather, or GNOME Clocks, or basically anything that determines your location
2. In GNOME Control Center > Privacy, enable Location Services (note that I am unsure about this part; it may not even be necessary)
3. Open the application requesting your location
4. Do something latency-sensitive on WiFi, like SSH or ping

Hypothesis:

When an application requesting your location is running in the background and location services are enabled, it seems to tell geoclue to use NetworkManager's D-Bus API for letting wpasupplicant scan for surrounding networks very often. This causes lots of latency spikes and visible lag.

Typing characters in an SSH session is rather laggy, and running something as simple as mtr 192.168.1.1 will show that every ~20 seconds the latency is over 100ms and packet loss occurs, while it's normally around 1.5ms with no packet loss. There are probably lots of other issues caused by this as well.

When a WiFi adapter scans for SSID's, it has to switch channels, delaying or dropping traffic in the meanwhile. This is what causes the lag and packet loss.

On phones connected to LTE this may make sense, but on a laptop which uses WiFi as its active network, this is detrimental to the connection.

Changing /etc/geoclue/geoclue.conf to disable WiFi scanning, solves this problem:

[wifi]
enable=false

On Ubuntu 18.04, this setting was the default. On Ubuntu 20.04, it has changed to 'true'.

Expected behaviour:

Don't break WiFi for a location scan.

$ lsb_release -rd
Description: Ubuntu 20.04 LTS
Release: 20.04

$ apt-cache policy geoclue-2.0
geoclue-2.0:
  Installed: 2.5.6-0ubuntu1
  Candidate: 2.5.6-0ubuntu1
  Version table:
 *** 2.5.6-0ubuntu1 500
        500 http://nl.archive.ubuntu.com/ubuntu focal/main amd64 Packages
        100 /var/lib/dpkg/status

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Sebastien Bacher (seb128)]

Thank you for your bug report, that's an interesting finding but it sounds like it would have more chance to be addressed upstream since Ubuntu doesn't have anywork actively working on geoclue at the moment, could you also report it to the code writers on

https://gitlab.freedesktop.org/geoclue/geoclue/-/issues ?

[Kevin Keijzer (kkeijzer)]

I will. But for the time being, perhaps it should be tested with more WiFi adapters? (I only have AR9380's, so I can only test ath9k.)

If this is a problem for many chipsets, the default should probably be changed back to 'false'.

[Kevin Keijzer (kkeijzer)]

https://gitlab.freedesktop.org/geoclue/geoclue/-/issues/129

[Kevin Keijzer (kkeijzer)]

It sounds like geoclue is hardly maintained upstream. And I really don't think it's a driver issue. It's common physics that tuning a radio to different channels all the time will break the transmission to and from the channel you want to tune to.

In Ubuntu 18.04, this was disabled by default. Was that an upstream decision, or an Ubuntu patch?

[Guy Person (itisme1997)]

This was a problem for me as well with a RTL8821CE card on my laptop.

[tomdryer (tomdryer-com)]

I was getting poor latency on my system with an "Intel Corporation Wireless 8265 / 8275" adapter because Geoclue was initiating scans nearly continuously. This is caused by a bug which was fixed in a Geoclue 2.5.7:

https://gitlab.freedesktop.org/geoclue/geoclue/-/commit/7b52291b6e45fbb93604b838a0ba02fbbde7cd39

Ubuntu 20.04 is still affected because the latest available version is 2.5.6.