Skip to content

[th/connection-timestamp-for-wifi]

Thomas Haller requested to merge th/connection-timestamp-for-wifi into master
Revert "wifi: don't autoconnect to networks that have never been successful"

As commit ccfe5fec8d1c ('wifi: don't autoconnect to networks that have
never been successful') explains, Wi-Fi profiles only autoconnected
if they had no or a positive timestamp.

The problem that tried to solve is when a user accidentally clicks on a
Wi-Fi network in applet. Then the created profile may not be usable
(because of wrong credentials). To avoid indefinitely to autoconnect,
uch a profile will have a timestamp of 0, which prevents further
auto activations.

However, I find that problematic.

An important use case is pre-deploying profiles. In that case, the user
cannot set the timestamp, because the timestamp cache
/var/lib/NetworkManager/timestamps is internal, undocumented API. Also,
ifcfg-rh doesn't support the timestamp and anyway, does the timestamp
of the NMConnection does not get honored (only the one from the
timestamps file).
Maybe that could be an alternative solution here, to allow the user to
mark profiles as "I really want it to autoconnect". But that seems
unnecessary and wrong to me.

The problem really is that the user cannot do anything to ensure that
autoconnect will work tomorrow (short of editing the timestamps
database). The problem is that the property of whether a profile
every connected successfully is not in direct control of the user (it
depends on external conditions).

If the user has bogus profiles configured, those profiles should be
deleted (or autoconnect disabled) and not keep autoconnect blocked.

Also note that if you are at home and accidentally click on your
neighbour's Wi-Fi network, then you presumably still also have a working
profile to your own network. That usable profile will have a more
recent timestamp and be preferred during autoconnect already.

This reverts commit ccfe5fec8d1c1038467e4a56656d8f90bc94d2ed.

https://bugzilla.redhat.com/show_bug.cgi?id=1781253

Merge request reports