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.
