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.
When a DBus error is received, the values of the other parameters
may be undefined, but bindings will assume they're valid and fail.
Capture this case and pass NULL to the callbacks.
Also, allow passing NULL instead of a callback, for bindings that
don't support the argument types.
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.