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.
If the supplicant dies a number of times within a short period of
time, make it go sit in the corner for a bit instead of continuously
trying to start it and have it die again.
Instead of just exposing a "running" value, instead make a meta
"available" value that's a combination of whether the supplicant
is actually running plus whether we want to talk to it right now
or not.
interface_add() could get called from two places: by the wifi/eth
device class when activating (which if the supplicant isn't yet
running will D-Bus activate it) and from the NameOwnerChanged
handler for the wpa_supplicant dbus service smgr_running_cb().
So if the supplicant wasn't running, nm_supplicant_interface_new()
would call interface_add() to bring the supplicant to life via
activation, then go on and create priv->iface_proxy. When the
supplicant appeared and D-Bus sent the NameOwnerChanged,
smgr_running_cb() would also call interface_add(), creating a
second priv->iface_proxy. The first one got lost and lived after
its parent NMSupplicantInterface was killed, and could still
respond to signals over the bus.
Prevent that by adding another state, STARTING, that indicates
that we've already started talking to the supplicant. Also be
extra paranoid about disconnecting signal handlers on the proxy.
We only really need one state for the supplicant interface which
simplifies handling in the Wifi and Wired device classes quite a
bit. It also simplifies the supplicant interface class too.
One behavioral change in the device classes is not running the
supplicant interface state changes from an idle; we'll have to
see if that causes problems. ISTR long ago that processing the
state change signals directly caused some issues, but we've
significantly reworked somethings since then so we may be able
to get away with this now.
Move GObject stuff to the bottom to reduce prototype abuse and
remove unneeded prefixes from stuff that's private to the class
itself. We also don't need the 'supplicant-manager' or 'device'
properties since they weren't used anywhere.
Move GObject stuff to the bottom to reduce prototype abuse and
remove unneeded prefixes from stuff that's private to the class
itself. We also don't need the 'supplicant-manager' or 'device'
properties since they weren't used anywhere.
This has been around a long time, but is very hard to trigger. It appears
to happen mostly if the supplicant segfaults on resume but has been seen
in other cases as well.
For whatever reason, the DBusGProxy's refcount reaches 0 and the proxy gets
disposed of. That in turn disposes of all the pending calls that are
in-progress on the proxy. Since we give the pending calls a closure, that
closure (nm_supplicant_info_destroy) gets called when the pending calls
are destroyed. That closure unrefs the proxy again.
Since DBusGProxy doesn't have any protection in its dispose() handler
against re-entrant disposes (which is arguably a bug of the client)
we end up infinite looping in nm_supplicant_info_destroy().
Fix that by ensuring we return early if we detect that we are already
freeing the NMSupplicantInfo object, and thus don't try to dispose
of the proxy yet again.
With supplicant patches, this allows NM to figure out when the supplicant
is performing an unsolicited scan, and thus to not run periodic_update()
when the supplicant is scanning.
This fixes some of the causes of "roaming to none", especially in hidden
SSID networks. In those cases, after NM had requested a broadcast scan,
the hidden SSID AP would likely not show up in the scan results, leading
to the supplicant performing a specific SSID scan that NetworkManager
was unaware of. While that specific SSID scan was going on, NM could
run periodic_update() and pull the wrong frequency off the card,
leading to the "roaming to none" message when the associated AP with
the wrong frequency could not be found in the scan list.
* src/supplicant-manager/nm-supplicant-interface.c
(nm_supplicant_interface_disconnect): Don't increment the reference
count when disconnecting. The problem is on shutdown, when the replies
to these commands do not arrive before NM exits, resulting on never
calling supplicant interface's dispose(), which removes the interface
from supplicant.
git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@4093 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
