If D-Bus fails to spawn the supplicant it sometimes returns a method
timeout error instead of a spawn error. We've seen that happen on
F18 when systemd is used to autolaunch the supplicant. That causes
NM to assume that the supplicant crashed and thus never try to talk
to it again, on the assumption that (a) it crashed and (b) it will
crash again if we try to use it, and thus we'll be in a spawn loop.
First, (a) is not necessarily the case, and second, the supplicant
doesn't crash like that anymore. So we're pretty safe to just talk
to the supplicant if it starts later instead of ignoring it if
we detect the timeout error.
NMPolicy was calling nm_device_state_changed() from inside its
NMDevice::state-changed handler, which caused the D-Bus signal to get
lost. Use nm_device_queue_state() instead.
If /etc/NetworkManager/dispatcher.d didn't exist or was
empty, we'd try to pull the first element of a 0-sized array.
To fix this cleanly, we need to explicitly separate discovery
of binaries to execute from setting up the callback data.
Rather than having NMDevice subclasses connect to their own
::state-changed signal, fix up the signal definition so they can just
override the class handler.
The idea was copied from gtk, but it's only used there in cases where
the method's wrapper function and default implementation would
otherwise have the same name, which never happens in NM because our
method implementations aren't prefixed with the type name, so it's
just noise here.
Add --enable-modify-system, to change the default for
org.freedesktop.NetworkManager.settings.modify.system to allow users
to edit system connections without needing to authenticate.
VLAN connections can have "hardware" settings in addition to the
VLAN-specific ones. ifcfg-rh was reading in wired settings for VLANs,
but was not writing them back out.
VLANs are only supported on certain kinds of devices, so don't try to
create them on other devices. (In fact, NM currently assumes that
VLANs are only created on Ethernet devices, so we need to be even more
picky than that.)
Do slightly more validation if NMSettingVlan properties, and make sure
that at least one method of specifying a parent is used.
Remove the check that id is in range, since gobject will not allow you
to set the property to a value outside its declared range anyway.
The ctype macros (eg, isalnum(), tolower()) are locale-dependent. Use
glib's ASCII-only versions instead.
Also, replace isascii() with g_ascii_isprint(), since isascii()
accepts control characters, which isn't what the code wanted in any of
the places where it was using it.
replace_default_ip6_route() was mistakenly requiring gw to be
non-NULL, which meant it could only set the route via a gateway, not
via a device (thus breaking IPv6-over-openconnect)
We don't need to use distribution-specific network scripts to just bring
up the loopback interface.
I'm not aware of any init dependency problems but even if there are some,
it is more practical to solve them in the respective configuration files.
This function also tried to add 127.0.0.1 to the list of addresses but
not ::1. We don't need to set the interfaces up as this is done by the
kernel.
This function was basically the same for all distributions and
was used only in one place. It tried to restart nscd or ask it
to reload configuration. This is not necessary as nscd uses
inotify to watch /etc/resolv.conf.
We go through the SECONDARIES state where we check if there are some secondary
(VPN or other) UUIDs that are to be activated before progressing to ACTIVATED.
In case of an error with a secondary UUID or its activation, the base connection
can't activate successfully.
Recent versions of wpa_supplicant have a "DisconnectReason" property
that, upon a deauthentication event, contains an IEEE 802.11
"Reason Code" for why the disconnect may have occurred. We may
want to use this in the future, so add the infrastructure to pass it
around to supplicant listeners.
Most often, a disconnect during the 4-way handshake means that the
WPA PSK is wrong (though not always). In that case, ask the user
for a new password.
When the supplicant starts connecting, or gets disconnected, track
whether it ever starts talking to an AP. Then if the connection fails
as a result of an initial connection timeout or a link timeout, we
can use SSID_NOT_FOUND when we're reasonably sure the AP doesn't
exist. Clients can use this to show better error messages.
Note that SSID_NOT_FOUND may only be reported when using nl80211
drivers, as WEXT drivers don't provide the status necessary to
determine whether the network exists or not.
Don't automatically request new secrets just because previous
attempts to connect failed, since this could be due to many
other things than bad secrets. Only request new secrets if
the caller of handle_auth_or_fail() specifically wants them.
Next, if the supplicant fails the initial association attempt
with an encrypted AP, only ask for new secrets if this is the
first time we're trying to connect to this network. Otherwise
we assume the secrets good; if they aren't, the user should
change them through a configuration editor.
These changes should dramatically cut down the number of
unwanted secrets requests due to random driver failures, weak
AP signal strength, or out-of-range APs.
If the link to the current AP fails, that's either because it is out of range
or somebody turned it off, or the driver is being dumb. Instead of leaving
the failed AP in the scan list, whereupon we'll just try reconnecting to it
again (even though it might not be visible), remove it from the list and
only try reconnecting if a new scan finds it. To ensure that happens, start
a scan when entering the DISCONNECTED state, which the device enters
right after FAILED.
Now there's a race between the periodic update and the link timeout
handler, as the periodic update could have run right before the link
timeout, and if the card was momentarily unassociated when the periodic
update fired, priv->current_ap will be cleared, and thus we can't remove
it from the internal scan list.
To fix that, only run the periodic update when we know the supplicant is
talking to an AP. When it's not talking to an AP the information that
the perioidic update gathers is meaningless anyway. Plus, it's not very
helpful to clear the current AP just because the driver/supplicant are
in a transient state; if they recover the connection we've bounced
stuff unecessarily, and if they don't recover we'll be tearing the
connection down anyway.
If you accidentally click on an wifi network in the menu, and you
don't know the password, and cancel, the connection always stuck
around and was available for autoconnection. That's annoying, and
it's a few clicks to go delete them. But better yet, we can
slightly repurpose the 'timestamp' property of connections to
determine whether or not they've been successfully connected in the
past; NM stores timestamps for all connections as of version 0.9.
So if a wifi connection hasn't ever been successful (which means it
has a timestamp in the timestamp cache, but that timestamp is zero),
don't try to autoconnect it.
Preloaded connections without a timestamp will still be autoconnected
at least once (as they always have) because they won't yet have a
timestamp in the timestamp cache.
Currently there's no way to differentiate between a connection that has
never been activated, and a connection that has never been *successfully*
activated. In both cases nm_settings_connection_get_timestamp() returns
zero. But it's useful to know whether a connection hasn't even been
tried yet, so enhance the timestamp code to return whether or not the
timestamp has been found in the timestamp cache or not, and make the
NMDevice core set an explict timestamp of 0 if the connection failed
on the first attempt.
We'll use this later to conditionally autoconnect WiFi connections
depending on whether they've ever successfully connected or not, but
still allow preloaded connections without a timestamp to autoconnect
as they always have.
