Comment 5 for bug 1425172

Wireless APs are removed after a while, based on whether we receive an AP removal signal from the supplicant, or if not, after a reasonable amount of time. This time is currently defined as three times the maximum scan interval (2 min), so after 6 minutes of the AP not changing strength or other properties to cause an update of its last-seen value, and not otherwise being explicitly removed by the supplicant. This is because we can miss signals from the supplicant for a variety of reasons, and also because APs might not be updating in a noticeable way for a long period of time between explicit scans, in which case it would also be wrong to remove them from the list.

Here it's important to also report findings from 'nmcli dev wifi list' as opposed to the indicator if it's an issue for network-manager, as the indicator may have further logic that changes the behavior of the AP list.

Now, I don't recall seeing such issues on desktop in any noticeable way, so it would definitely be important to make sure whether it's also an issue there (and it should if the problem is in NM, since we use the same NM, the same supplicant, and the same code for handling APs on all systems).

One thing this could be however is a driver issue. Drivers are entitled to report access-points the way they want, and if there is an internal timeout to removing APs from scan results (or the driver not actually scanning when we ask it to), then this could appear. In this case it does remain relevant to know how desktop compares to the phone.