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.
If we mask signals before daemonizing, the daemon process will not be
able to handle them, and thus would be unkillable with anything other
than SIGKILL.
Helps when you need to grep the code to change a signal's signature.
Otherwise you're stuck grepping for "state" which a lot of objects
have as a signal name.
Remove unused args for the non-VPN cases to cut down on the NULL NULL NULL
stuff since we're also adding two more arguments. Add the ability for
callers to give a callback that should be called when the dispatcher is
done.
Buggy kernel drivers sometimes default the carrier to ON when they
are capable of link-detection but the carrier is actually off, and
they quickly switch the carrier OFF when they determine actual
carrier state (cdc-ether, for example).
The initial carrier ON event would trigger a queued state change
from UNAVAILABLE to DISCONNECTED, which may auto-activate the
device. But before that state change happens, if a carrier OFF
event comes in, that queued state was not getting cleared and
the device would transition to DISCONNECTED even though the
carrier was off.
To ensure that never happens, and that we don't enter states that
aren't valid when the carrier is off, we need to clear any queued
state changes that wouldn't be valid in the new carrier state.
The kernel periodically adds routes for specific operations, including
when pinging any host. These are temporary routes and aren't part of
the interface's permanent routing configuration, so we should ignore
them.
If ModemManager isn't running, don't put DUN connections into
AvailableConnections, and don't allow DUN connections to be started
either automatically or manually.
Because object-valued properties (like ip4-config) get reloaded
asynchronously when they change, we will still have out-of-date values
for them cached at the point when we get the StateChanged signal from
the daemon. Work around this by manually reloading all properties
before emitting the client-side signal.
Also, fix a dumb bug in NMObject...
The MM API defines the GetIP4Config method return as (uuuu) which
is [ IP, DNS1, DNS2, DNS3 ]. Unfortunately the for() loop in the
static_stage3_done() function started at index 0, which is the IP
address. This caused the IP address to be added to the DNS list.
It should start at index 1 instead.
This worked fine with PPP because PPP terminates, and NM watches
for that and handles it fine. But modems with pseudo-ethernet ports
don't have anything like that, so we have to watch the modem's state
property instead. This works only with MM 0.5.4 and later (including
0.6).
