The Interface held a reference to the manager to listen for the 'available'
signal. Instead of that, let's make the child unaware of the master to
keep the inheritance cleaner.
config.h should be included from every .c file, and it should be
included before any other include. Fix that.
(As a side effect of how I did this, this also changes us to
consistently use "config.h" rather than <config.h>. To the extent that
it matters [which is not much], quotes are more correct anyway, since
we're talking about a file in our own build tree, not a system
include.)
Commit fb6cde50 changed from setBlobs in the old wpa_supplicant D-Bus
interface, which returned an integer status code, to AddBlob in the new
one, which doesn't, but didn't account for that change. That caused
error messages of the form "Couldn't set network certificates: Too few
arguments in reply." on valid connection requests.
Signed-off-by: Geoffrey Thomas <gthomas@mokafive.com>
Types passed to dbus-glib need to be GTypes, not D-Bus type. While the
DBUS_TYPE_G_* macros are GTypes from libdbus-glib, the other DBUS_ types
aren't.
Signed-off-by: Geoffrey Thomas <gthomas@mokafive.com>
Signed-off-by: Thomas Haller <thaller@redhat.com>
Remove all remaining GParamSpec name and blurb strings (and fix
indentation while we're there), and add G_PARAM_STATIC_STRINGS to all
paramspecs that were lacking it.
These are expected errors if the supplicant can't be launched
for some reason. We should only log entirely unexpected errors
like wrong method arguments or types, really odd failures, etc.
NetworkManager[1312]: <error> [1379601146.148818] [supplicant-manager/nm-supplicant-interface.c:853] interface_add_cb(): (wlan0): error adding interface: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
NetworkManager[1312]: <error> [1379601171.160742] [supplicant-manager/nm-supplicant-interface.c:853] interface_add_cb(): (wlan0): error adding interface: Activation of fi.w1.wpa_supplicant1 timed out
The sole purpose of this structure was to track in-progress D-Bus
pending calls, so that they could be selectively canceled if the
supplicant got disconnected during assocation (canceling only
assocation-related calls) or if the supplicant went away (canceling
both assocation-related and general calls). But its only benefit
over NMCallStore alone was knowing which list of pending calls to
remove the current pending call from, and we can just explicitly
do that in the code instead.
Thus, the SupplicantInfo structure is removed and replaced with
explicitly adding and removing the pending calls from the call
store.
(The DBusGProxy is not referenced by dbus_g_proxy_begin_call(),
the caller is expected to hold a reference to the proxy for as long
as necessary, and when the proxy is destroyed, all its pending calls
will be canceled. Since the supplicant interface owns the proxies,
there's no possibility that the proxy will outlive the supplicant
interface and thus call back into it when its dead. The old code
referenced the supplicant interface over the life of the pending
call, but that's not necessary.)
Its only purpose is to track a number of DBusGProxyCalls to let
us cancel them all at the same time, without having to track each
call individually in the supplicant code. Instead of abstracting
it to the level of GObject and gpointer, just use the types it's
meant for.
This reverts commit 7902787263.
We'll be requiring wpa_supplicant 1.0+ from now on. wpa_supplicant
1.0 is over a year old a this point, so it's not unrealistic to
bump the requirement.
NOTE: you really do want 1.1 or later anyway if you want to
successfully use WPA-EAP networks, since that version has fixes
to correctly handle PMKSA preauthentication, otherwise you'll
get periodic disconnections on enterprise networks.
GObject creation cannot normally fail, except for types that implement
GInitable and take a GError in their _new() method. Some NM types
override constructor() and return NULL in some cases, but these
generally only happen in the case of programmer error (eg, failing to
set a mandatory property), and so crashing is reasonable (and most
likely inevitable anyway).
So, remove all NULL checks after calls to g_object_new() and its
myriad wrappers.
https://bugzilla.gnome.org/show_bug.cgi?id=693678
And return an error when trying to activate an AP mode connection
if the supplicant does not support it.
With wpa_supplicant 1.0 and earlier there is no way to positively detect
whether AP mode is supported, so we simply try to start AP mode
and then fail if it doesn't work.
With more recent versions we can check the Introspection data
(if the supplicant has been built with introspection enabled) or
check the global Capabilities (if the supplicant is recent enough)
for positive indication of AP mode support.
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.
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.
NMDeviceWifi and a few other things expect the interface will
move from STARTING to READY and then on to other states. But the
state was getting set to the actual supplicant interface state
immediately when the first properties were read (which include
the State property) and thus the READY state got bypassed. But
we also want to read stuff like the capabilities before letting
the interface be used.
So first, ensure the supplicant interface object actually uses the
READY state like its callers expect, and second, don't set the
READY state until we actually know what we need to know about it.
Because the supplicant doesn't have a BSS property for "last seen"
we have to fake that by listening to PropertiesChanged events for
stuff like signal strength, which usually changes a bit from scan
to scan. But in case it doesn't change, we'll never get that PC
signal, and thus we'll never update our internal 'last seen'
timestamp, and thus the AP will get removed from the NM scan list
even if it was in the supplicant's last scan results.
So, if the AP if we haven't receieved a BssRemoved signal for the
AP yet don't remove it from the NM scan list. One caveat is that
if the supplicant's DEFAULT_BSS_EXPIRATION_AGE value is greater
than NM's AP expiration age, NM will by consequence use the
supplicant's value instead. At the moment the supplicant sets
DEFAULT_BSS_EXPIRATION_AGE to 180 seconds while NM's is 360.
This message was printed:
GLib-GObject-CRITICAL **: g_value_get_string: assertion `G_VALUE_HOLDS_STRING (value)' failed
It showed out it came from g_cclosure_marshal_VOID__STRING() in BSSRemoved signal.
The signal parameter is object path, so use g_cclosure_marshal_VOID__BOXED instead.
The standard D-Bus PropertiesChanged signals are only in 1.0 and
later, so we also have to listen to the deprecated signals for
older supplicant versions. We can revert this commit when we
drop support for wpa_supplicant 0.7.x.
The port to the new supplicant D-Bus API for NM 0.9 had one unfinished
piece, which was to remove old APs from the scan list when the
supplicant returned no scan results or there was a scan error. In
this case, the removal code would not be called. This wasn't much
of a problem until 836f7d177e which
began removing APs from the scan list correctly in this case.
This uncovered a bug in NM's wpa_supplicant management code, which
was that NM only updates its internal AP object 'last seen' timestamp
when the AP is reported by the supplicant as a completely new BSS
(in merge_scanned_ap()). But the new supplicant D-Bus interface
only reports the BSS as "new" when the supplicant doesn't know about
the BSS, either because it is a new BSS or because it's been removed
from the supplicant's scan list at some point in the past.
Thus for BSSes that are consistently kept in the supplicant's scan
list, because the wifi driver is actually doing its job and reporting
them consistently in scan results, NM would not be updating the
'last seen' value for the corresponding NM AP objects. Due to
836f7d177e this would cause APs that
should be kept to be removed from the NM scan list.
To fix this, have the NMAccessPoint object track which supplicant
dbus object it came from, and have NMSupplicantInterface listen for
PropertyChanged signals for those APs the supplicant knows about.
When something changes (like signal strength as the result of updated
scan results) update the AP's 'last seen' timestamp since it clearly
still exists in the scan list. This way we update the timestamp both
when the supplicant finds a new AP and when it updates the properties
of existing APs.
EAP-FAST used to require some patches to OpenSSL which aren't always
applied. We can't depend on the supplicant supporting EAP-FAST like
we can for EAP methods that don't require any special support from
external libraries. To ensure the error gets reported correctly and
early, fail the configuration step if EAP-FAST isn't supported by
the supplicant but the connection requests it.
We'll use this to request identity and passwords in-band during
the connection attempt instead of sending them all at the
beginning. This should allow better handling of wrong
passwords (since we'll know we need to request them from the
user interactively) and better error codes when things fail.
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.
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.
We only want to prevent regression to > READY after READY has
been reached, since the interface state will track the supplicant
connection state which legitimately jumps around.
If the supplicant cannot be service activated, wait until it shows up
on the bus instead of sitting around doing nothing. This fixes a small
regression introduced when the _READY state was added to the supplicant
interface object.
