These are distinct from old-school LEAP (ie, Network EAP) in that
they are standard Dynamic WEP with LEAP as an EAP method and use
open-system authentication. Old LEAP uses the non-standard LEAP
authentication algorithm. The config for each is different and thus
we need to make sure we handle both cases.
The new wpa_supplicant D-Bus interface only passes back the 'level'
of the scanned BSS, which with nl80211 drivers is almost always dBm,
which NM handled fine. But WEXT-based drivers (ipw2x00, other older
ones, and some vendor drivers) use a mix of values for the 'level'
parameter, including the old WEXT 8-bit signed-value-in-unsigned-int
scheme. Handle that.
Alternatively, we could have the supplicant expose the 'flags' value
from its internal BSS list over the bus.
Ran into a case right underneath a tower where the Intel WiMAX SDK
reported signal strength as 32767 which is pretty clearly an overflow
of a 16-bit int somewhere in the WiMAX stack. Since our internal
NMWimaxNsp GObject property for signal-quality has a max value of
100, dbus-glib got pretty angry when GObject failed to return
something because the property value was out of range, leading
to malformed message and the bus daemon kicking us off, and finally
an assertion somewhere. Fun.
Timestamps are no longer written to the connection file itself, but
are kept in a lookaside file in /var to allow for read-only or
stateless /etc and to ease system administration and deployment.
NM updates timestamp for active connections every 5 min. We don't
want to touch files in /etc due to this. This commit solves that
by not updating timestamp in the connection's property. Rather it
updates the timestamp internally. All timestamps are also kept track
of in /var/lib/NetworkManager/timestamps file.
When settings are requested via D-Bus GetSettings(), the proper
timestamp is put in the connection setting before returning.
Some adjustments need to be made to read and write secret flags, and
to ensure that connections that don't have system-owned secrets are
still parsed as expected. testcases for 802.1x connections to come
shortly.
Like if the IP interface doesn't have an ifindex yet. Previously
the connection would just go merrily along and wait for IPv6 to
complete even though it had already failed. Happens if you try
to do IPv6 on mobile broadband connections, which we'll add support
for later.
These days more and more devices are showing up that support a
number of different access technology families in the same hardware,
like Qualcomm Gobi (CDMA and GSM), Pantech UM190 (CDMA and GSM),
Pantech UML290 (CDMA and LTE), LG VL600 (CDMA and LTE), Sierra
320U (GSM and LTE), etc. The previous scheme of having device
classes based on access technology family simply cannot handle
this hardware and attempting to add LTE to both the CDMA and GSM
device classes would result in a bunch of code duplication that
we don't want. There's a better way...
Instead, combine both CDMA and GSM device classes into a generic
"Modem" device class that provides capabilities indicating what
access technology families a modem supports, and what families
it supports immediately without a firmware reload. (Gobi devices
for example require a firmware reload before they can switch
between GSM and CDMA). This provides the necessary flexibility
to the client and allows us to keep the API stable when the
same consolidation change is made in ModemManager.
The current code doesn't yet allow multi-mode operation internally,
but the API is now what we want it to be and won't need to be
changed.
deactivate_quickly is misnamed these days; it was originally used
for quickly tearing down a device for sleep and such. But these
days it's used for the bulk of device deactivation. Only the wifi
class used the actual deactivate method. So combine the two and
make device implementations less complicated.
If configuration fails, there won't be an IPv6 config for the device,
thus the route flush when deactivating the device if it fails would
only flush IPv4 routes. We don't know how far through IPv6 setup
we got, so we do want to flush IPv6 routes on deactivate if we
started IPv6 config at any point.
Clients need to do their own logging using glib or whatever; these
macros while somewhat helpful were not flexible and are not a
substitute for actual logging in the client. g_warning, g_message,
and g_error are more suitable anyway.
It's always used with a GByteArray anyway, as are most
functions in nm-utils.h. Even better, we can skip the
memcpy since it turns out to be pointless.
Will be used for things like activating a VPN connection before
signaling that the device is activated, or maybe for bridges and
bonds, to ensure that applications don't think the system has
connectivity before everything is set up.
It's really dbus-glib's fault, but the problem seems to be that when
short-lived D-Bus calls are made (with dbus_g_proxy_call_no_reply)
and the service is activated, then quits immediately like the
dispatcher does, there's not enough time for internal dbus-glib
housekeeping. The GetNameOwner call that's kicked off when the
DBusGProxy is created hasn't returned by the time the proxy is
being unrefed, so the proxy doesn't end up on the
unassociated_proxies list. But when the proxy is destroyed, and
it destroys it's DBusGProxyManager, the manager expects that
the proxy is on unassociated_proxies. Thus the crash.
I'm not entirely sure why we hit this only at shutdown with
systemd; it could be that systemd is killing the bus daemon at
the same time as we're running the dispatcher and that's why the
GetNameOwner call doesn't complete.
Work around all this by expecting a message return, which works fine
during normal operation, but on shutdown allows us to avoid urefing
the proxy until everything in dbus-glib has been handled, which at
shutdown time really just means leaking it. But then we exit, so
it's cleaned up anyway.
