Bug 1781253

Summary:	[RFE] improve handling of connection.timestamp
Product:	Red Hat Enterprise Linux 8	Reporter:	Thomas Haller <thaller>
Component:	NetworkManager	Assignee:	Thomas Haller <thaller>
Status:	CLOSED ERRATA	QA Contact:	Desktop QE <desktop-qa-list>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	8.2	CC:	atragler, bgalvani, jmaxwell, lrintel, rkhan, sukulkar, thaller, till, vbenes
Target Milestone:	rc	Keywords:	FutureFeature
Target Release:	8.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	NetworkManager-1.26.0-0.1.el8	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-11-04 01:49:00 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1807630

Description Thomas Haller 2019-12-09 16:06:45 UTC

The connection.timestamp indicates when the profile as successfully activate the last time.

This is relatively important for Wi-Fi profiles, because they won't autoconnect unless they were activated previously.

That means, when you want to pre-deploy a Wi-Fi profile, you would also need to set the timestamp, otherwise the profile cannot autoconnect.

There are multiple issues:

- ifcfg-rh plugin does not persist/read the timestamp

- keyfile reads it, but it gets ignored in favor of /var/lib/NetworkManager/timestamps, see https://gitlab.freedesktop.org/NetworkManager/NetworkManager/blob/e0569ee575a40f401b2cca1acbd9cddd5fa567cd/src/settings/nm-settings-connection.c#L2186

- when setting the timestamp via D-Bus, we actually write it to keyfile. However, it's still ignored and not properly set in NMSettingsConnection. We either should ignore the timestamp from D-Bus entirely, or properly handling setting.

- as it is, the timestamp cannot be actually set, neither via D-Bus nor via file based API. That means, you cannot create a profile that can autoconnect right away.

Comment 3 Thomas Haller 2020-05-27 15:35:20 UTC

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/524

Comment 4 Thomas Haller 2020-06-03 16:27:59 UTC

fixed upstream as https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/6022af99635fa1c0f89426ab13821d47a82db189

Comment 8 Thomas Haller 2020-07-02 10:40:18 UTC

for testing:


- there are 3 cases for a profile:

  a) when a profile never was attempted to autoconnect, it has no timestamp (at all), and is not mentioned in `/var/lib/NetworkManager/timestamps`.
  b) if a profile successfully activates, the positive timestamp gets written to /var/lib/NetworkManager/timestamps.
  c) if a profile tries to activate but fails, *and* if it had no timestamp previously (case a)), then NetworkManager would write timestamp 0 to /var/lib/NetworkManager/timestamps


What now happened before:

 - for (only!) Wi-Fi profiles, autoconnect was blocked if the profile has an explicit timestamp set to zero (case c)).


the effect is, that when you add a new profile (either intentionally or by accident when clicking in nm-applet on the wrong network), then initially it would autoconnect (case a). If that fails, autoconnect was blocked (case c), until a manual activate succeeded.


The change here is that autoconnect is now no longer blocked, regardless of whether it succeeded in the past.

Comment 9 Vladimir Benes 2020-07-02 12:11:08 UTC

test case added:
https://gitlab.freedesktop.org/NetworkManager/NetworkManager-ci/-/merge_requests/593

Comment 12 errata-xmlrpc 2020-11-04 01:49:00 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (NetworkManager bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:4499