When secrets are flagged as agent-owned in a connection configuration file, but
actually not available, we have to return an empty hash (nm_connection_to_hash()
returns NULL).
It's not a valid prefix since NM determines the default routes
automatically, and thus routes and addresses with a prefix of
zero should not be used in config files.
If a shared wifi connection is restricted to a certain set of users
and none of those users have authorization to start shared wifi
connections, don't auto-start the connection.
If an error occurred, or PolicyKit is disabled, we don't want to
schedule two idle handlers to return the result of an authentication
request. We'll soon be queuing up multiple requests at the same
time so we don't want this to happen.
Use case:
A user has an auto-activatable connection with secrets in a keyring. While
booting NM starts and tries to activate the connection, but it fails because of
missing secrets. Then the user logs in, but the connection is marked as invalid
and is not tried again.
This commit solves the issue by removing invalid flag and activating the
connection when a secret agent registers.
Signed-off-by: Jiří Klimeš <jklimes@redhat.com>
ifcfg-rh plugin now reads/writes the property as MACADDR_BLACKLIST variable.
The variable is space-separated list of MAC addresses in the standard
hex-digits-and-colons notation.
E.g. MACADDR_BLACKLIST="7e:d8:c0:85:58:7f 00:1e:65:30:d5:c7"
"mac-address-blacklist" property is added to the ethernet and WiFi connections.
It is the MAC addresses list of devices on which the connection won't be
activated.
Original patch (NM_0_8 branch) from Thomas Bechtold <thomasbechtold@jpberlin.de>
Instead of retrying the password a number of times, immediately fail the
connection and ask for a new pasword if (1) the request fails during the
802.1x authentication and (2) the password is an 'always-ask' 802.1x
password. The password is bad anyway, and in the case of RSA/OTP tokens
the code may have already changed, so it's pointless to keep retrying
the same password when it's already stale.
Use a broader range of supplicant interface states to determine
when to tell the supplicant to idle; we want to allow the
disconnect in all of these states, not just some of them.
Second, allow the active network to be removed from the supplicant's
list in most of these states, even when the supplicant interface is
inactive or disconnected.
If there is a temporary connection failure (e.g. due to unavailable DHCP), the
connection is marked as invalid after several retries. Reset the flag after
5 mins to allow next auto-reconnection.
IPV6_FAILURE_FATAL is now read and defaults to TRUE for ifcfg files
even if IPv6 is turned off. That means that if we write a connection
for which NM_SETTING_IP6_CONFIG_MAY_FAIL is FALSE but IPv6 is disabled,
ifcfg-rh won't write out IPV6_FAILURE_FATAL (because IPv6 is disabled
so why bother writing out IPv6-related settings) but on re-read it will
treat the absence of IPV6_FAILURE_FATAL as TRUE/yes. This leads to
a mismatch between the connection that was written out (which will
have NM_SETTING_IP6_CONFIG_MAY_FAIL=FALSE and no IPV6_FAILURE_FATAL)
and the re-read connection (which will have
NM_SETTING_IP6_CONFIG_MAY_FAIL=TRUE since a missing IPV6_FAILURE_FATAL
is treated as NM_SETTING_IP6_CONFIG_MAY_FAIL=TRUE).
Since commit 0ce4b6b412
NetworkManager-wait-online.service quits immediately if there is no link yet.
Fix it by removing the '-x' option.
But if we do just that, NM-w-o would add a useless 30 seconds delay in the
case when NM is not running at all.
Solve this by adding a Requisite= dependency on NM.
https://bugzilla.redhat.com/show_bug.cgi?id=710502
