The DBus signatures registered (via dbus_g_proxy_add_signal) for the
fi.w1.wpa_supplicant.Interface.{BSSAdded,ScanDone} signals were
incorrect. That prevented us from receiving wifi ap scan results, at
least in the case where wpa_supplicant has DBus introspection disabled.
There's two possibilities for errors from D-Bus when trying to
activate the supplicant; either we ignore the error and wait
for the supplicant to restart or be started, or it's a hard
error and we can't continue without risking worse behavior (ie
out of memory, supplicant spawns but exits immediately, etc).
This adds a few more harmless errors to the first category
which can happen if the supplicant's .service file exists
but the supplicant does not, in which case we just wait for
it to magically show up later.
The regex was capturing integers larger than 3 digits, which aren't
valid SSID integer list items because each byte of the SSID cannot be
larger than 255. Add an explicit testcase for intlist SSIDs too.
The previous regex was causing a testcase failure with an SSID of
'1337' which it was interpreting as a single element intlist, but
should have been interpreted as a string since it's clear > 255.
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).
We need to read IPV6_FAILURE_FATAL and other values, even if IPv6 is disabled.
Else the variables would use default values, which may not be right. Then
switching between methods "Ignore" and "Automatic" in a GUI would change value of
IPV6_FAILURE_FATAL property, even if it's not touched explicitly.
The core problem was the nm_connection_need_secrets() call in
nm-agent-manager.c's get_start() function; for VPN settings this
always returns TRUE. Thus if a VPN connection had only system
secrets, when the agent manager checked if additional secrets
were required, they would be, and agents would be asked for
secrets they didn't have and couldn't provide. Thus the
connection would fail. nm_connection_need_secrets() simply
can't know if VPN secrets are really required because it
doesn't know anything about the internal VPN private data;
only the plugin itself can tell us if secrets are required.
If the system secrets are sufficient we shouldn't be asking any
agents for secrets at all. So implement a three-step secrets
path for VPN connections. First we retrieve existing system
secrets, and ask the plugin if these are sufficient. Second we
request both existing system secrets and existing agent secrets
and again ask the plugin if these are sufficient. If both those
fail, we ask agents for new secrets.
