The symbol is part of the public API (included in the GIR file),
and gjs complains loudly if a defined symbol is not found.
https://bugzilla.gnome.org/show_bug.cgi?id=706259
Acked-by: Pavel Šimerda <psimerda@redhat.com>
There are three additions to the D-Bus interface for VPN plugins as
part of this patch:
1) ConnectInteractive(): called by NM instead of Connect() to let
the plugin know that it can request additional secrets during the
connection process using SecretsRequired
2) SecretsRequired: a new signal emitted by the plugin to indicate
to NetworkManager that additional secrets are required to connect;
can only be called if NetworkManager initiated the connection by
calling the ConnectInteractive() method
3) NewSecrets(): a new method of the plugin that NetworkManager calls
when new secrets requested by the SecretsRequired signal have been
retrieved from secret agents
We need new methods because agents need to be aware of the hints that
the VPN plugins may send with the SecretsRequired signal (detailing
the specific secrets that are required) and at this time, not all
agents support passing those hints to the VPN plugin authentication
dialogs.
Add a "monitor-connection-files" config option, which can be set to
"false" to disable automatic reloading of connections on file change.
To go with this, add a new ReloadConnections method on
o.fd.NM.Settings that can be used to manually reload connections, and
add an nm-cli command to call it.
Add a new libnm-glib method to get the type description for a device,
and use it in nmcli. For most types, the type description is based on
the class name, but for NMDeviceGeneric, it comes from the
:type-description property.
Add NMDeviceGeneric, to provide generic support for unknown device
types, and create NMDeviceGenerics for those devices that NM
previously was ignoring. Allow NMSettingGeneric connections to be
activated on (managed) NMDeviceGenerics.
Use the correct annotation for vfuncs, so that NMClient.SecretAgent becomes
introspectable.
Use "self" as the first argument of the vfuncs in their declarations, to match
the actual name in nm-secret-agent.c. This avoids warnings from g-ir-scanner.
https://bugzilla.gnome.org/show_bug.cgi?id=698184
Both the VpnState property and the VpnStateChanged dbus signals update the
NMVPNConnection's 'vpn-state' GObject property, so we should ensure that
when either updates it due to a D-Bus event, GObject signals are sent
out for both too.
Though the client shouldn't be calling anything when NM isn't running
(because clients have nm_client_get_manager_running()), make sure
that NMClient never calls a NetworkManager method when NM isn't
on the bus.
Next, ensure NMObject doesn't try to refresh properties when NM isn't
running. Creating an NMClient may trigger a property refresh request,
but if NM isn't running, defer that until NM starts, to ensure that
we don't D-Bus autostart NM.
Third, ensure NMRemoteSettings doesn't attempt to list connections
unless NM is running.
This prevents service activation of NetworkManager in lieu of dbus-glib
learning about DBUS_HEADER_FLAG_NO_AUTO_START.
Use the D-Bus connection helper whenever we need a connection to
NM, which by default tries to use a private connection instead of
the shared bus connection whenever the user is root. Doing this
by default will not change the behavior of libnm-glib, and allows
tools like nmcli and libnm-glib-using clients to work in minimal
environments (those without a bus daemon) by default.
When using a private connection, we need to use dbus_g_proxy_new_for_peer()
because the bus isn't involved. Since many parts of libnm-glib create a
proxy for their corresponding remote object, consolidate the proxy creation
logic.
A later patch will add logic to use a private connection versus a bus-based
one.
A number of places in the code need to get a connection to NM through
D-Bus, and that connection could be either a shared bus connection or
a private connection. Consolidate that logic.
Unfortunately only dbus-glib >= 0.100 correctly supports private
connections (commit 8b7e4a1c4ae055864e26db4addbcc2dc38ee6963 fixes
this problem) so the private connection functionality is not enabled
for older dbus-glib versions.
It now works with sufficiently recent python 2.x or python 3.x, whatever
is the distribution default. This patch fixes 'make check' for
distributions where 'python' means python 3.x, like Gentoo.
Because _device_update_description() freed and update *both* the
vendor and product description, if the function was not able to
read one of them the first time, it would throw both away the second
time and try re-read them. That caused code like this:
vendor = nm_device_get_vendor (device);
product = nm_device_get_product (device);
to be left with a freed 'vendor' value if _device_update_description()
could not read the product when first called from nm_device_get_vendor(),
because it would be called a second time from nm_device_get_product()
and free priv->vendor and priv->product and then attempt to re-read them.
Fix this by making the function return only one value so that the
callers can control the liftime of the property they are trying to set.
==29355== Invalid read of size 8
==29355== at 0x38F7289840: __GI_mempcpy (memcpy.S:122)
==29355== by 0x38F7276F21: _IO_file_xsputn@@GLIBC_2.2.5 (fileops.c:1353)
==29355== by 0x38F7247DA6: vfprintf (vfprintf.c:1615)
==29355== by 0x38F7250E28: printf (printf.c:34)
==29355== by 0x41E79F: print_fields (utils.c:351)
==29355== by 0x414CAB: show_device_info (devices.c:636)
==29355== by 0x415CE8: do_devices (devices.c:1094)
==29355== by 0x41D9A9: start (nmcli.c:121)
==29355== by 0x38F6E47A54: g_main_context_dispatch (gmain.c:2715)
==29355== by 0x38F6E47D87: g_main_context_iterate.isra.24 (gmain.c:3290)
==29355== by 0x38F6E48181: g_main_loop_run (gmain.c:3484)
==29355== by 0x40CB89: main (nmcli.c:359)
==29355== Address 0x50a0401 is 1 bytes inside a block of size 18 free'd
==29355== at 0x4A077E6: free (vg_replace_malloc.c:446)
==29355== by 0x38F6E4D79E: g_free (gmem.c:252)
==29355== by 0x4C55F53: _device_update_description (nm-device.c:1417)
==29355== by 0x4C56D26: nm_device_get_product (nm-device.c:1502)
==29355== by 0x414B16: show_device_info (devices.c:620)
==29355== by 0x415CE8: do_devices (devices.c:1094)
==29355== by 0x41D9A9: start (nmcli.c:121)
==29355== by 0x38F6E47A54: g_main_context_dispatch (gmain.c:2715)
==29355== by 0x38F6E47D87: g_main_context_iterate.isra.24 (gmain.c:3290)
==29355== by 0x38F6E48181: g_main_loop_run (gmain.c:3484)
==29355== by 0x40CB89: main (nmcli.c:359)
libnm-glib's public headers include headers from libnm-util. While it
does work to just $(pkg-config --cflags --libs libnm-glib), this is
only because libnm-glib has a requires on NetworkManager which happens
to use the same include directory as libnm-util.
The correct dependency chain is thus:
libnm-glib -> libnm-util -> NetworkManager
Signed-off-by: Colin Walters <walters@verbum.org>
Do NMSettingConnection:interface-name matching on the client side as
well, so that, eg, nm-applet does not list connections under the wrong
device.
(Also, move some return-if-fail checks from the subclass method
implementations into the wrapper function.)
https://bugzilla.gnome.org/show_bug.cgi?id=693684
24cda2bc broke the ability to set NMConnection:path back to NULL after
it had been set, as part of a hack to try to make
NMRemoteConnection:dbus-path work. Fix that by moving the hack
entirely into NMRemoteConnection.
https://bugzilla.gnome.org/show_bug.cgi?id=693829
In order to resolve NMRemoteConnection-valued properties, NMObject
needs to be able to create NMRemoteConnections. But NMObject assumes
that all the objects it will be creating have "dbus-connection" and
"dbus-path" properties. So add those properties to NMRemoteConnection,
aliasing the existing "bus" and "path" properties (and ensure that
whichever version gets set, we keep that value, rather than letting it
get overwritten by the NULL default value of the other one).
https://bugzilla.gnome.org/show_bug.cgi?id=693669
Two issues here: first, the daemon code was using the wrong D-Bus type
(strings instead of object-path) to send the connection path to the
secret agent, which resulted in a method-not-found error and nothing
happening in the agent.
Second, the agent-side method call verification code would fail the
request anyway, becuase verify_request() determined success based
on the reconstructed connection, which isn't given when canceling
secrets requests.
Ensure that NMDevice::state-changed signals don't get emitted out of
order, and ensure that nm_device_get_state() from a ::state-changed
handler always returns new_state.
Use --enable-doc and --enable-tests instead of --with-docs and
--with-tests. This is consistent with other features and with
--enable-gtk-doc option. Support current variants as fallback.
Don't build tests unless --enable-tests is specified.
We had separate checks for glib-2.0, gobject-2.0, gmodule-2.0, and
gio-unix-2.0. It doesn't make sense to link a binary against all 4
because gio-unix-2.0 depends on glib-2.0 and gobject-2.0. Doing this
actually breaks things in unusual circumstances.
Generally, few bits of NM actually just use glib, and not gio. We
might as well coalesce those requirements together, even if it means
in some cases we "overlink". Additionally, I chose for now to fold
gmodule-2.0 in as well, even though many fewer programs need it. The
cost of overlinking is quite small.
The benefit of this is less repeated junk in Makefile.am, as well as
more centralized control over GLib. A followup patch will allow us to
set -DGLIB_VERSION_MIN_REQUIRED in just one place, rather than having
to replicate it 4 times.
The NM configure is still suboptimal - for example, libpolkit-1
depends on gio-2.0, so really we should determine the compiler flags
all in one pass. But it doesn't matter too much for now.
A new value for NM80211Mode is introduced (NM_802_11_MODE_AP) and the
new mode is passed to wpa_supplicant analogous to adhoc-mode.
The places which need to know the interface mode have been extended to
handle the new mode.
If the configuration does not contain a fixed frequency, a channel is
selected the same way as with adhoc-mode before.
If async GetProperties completed before the GetConnections, init_left would
be 0 and thus we never connected to connections-read, causing us to terminate
initialization before connections were actually read.
https://bugzilla.gnome.org/show_bug.cgi?id=686226
The nm_connection_to_hash() call in the NMSecretAgentGetSecretsFunc
documentation missed the last argument. This patch adds
NM_SETTING_HASH_FLAG_ALL as the last argument in the example.
The ctype macros (eg, isalnum(), tolower()) are locale-dependent. Use
glib's ASCII-only versions instead.
Also, replace isascii() with g_ascii_isprint(), since isascii()
accepts control characters, which isn't what the code wanted in any of
the places where it was using it.
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...
If a class implements init_async, it should implement init_finish too,
rather than assuming the default implementation will do the right
thing (which it briefly didn't in glib 2.33).
Core D-Bus VpnStateChanged signal changed. In order to receive the signal,
the parameters was fixed. This commit also adjusts libnm-glib's vpn-state-changed
signal to match the D-Bus one.
Allows agents to provide different behavior depending on whether the
secrets request was initiated by a user (eg by picking a connection
from a UI menu or by 'nmcli con up') or was automatically started by
NetworkManager.
See https://bugzilla.gnome.org/show_bug.cgi?id=660293
Old plugins (ie, that aren't IPv6 capable) don't send the 'config'
signal, and thus have no way of signalling which IP methods they
have support for. Which means they won't set priv->has_ip4 and
thus the connect timer will kill the connection after a minute.
So track whether we got a 'config' signal, and if we didn't, but
we did get an 'ip4-config' signal (which means this is an old
plugin) then we just assume that the plugin supports IPv4. This
allows the connect timer to be canceled and the plugin to advance
to the STARTED state.
Currently the .gir files for NetworkManager-1.0 and NMClient-1.0 declare
their dependencies twice, once with the GIR name and another one with
the pkg-config name. This causes problems with Vala bindings generation.
Add new API to allow passing both IPv4 and IPv6 configuration
information from VPN plugins to the backend.
Now instead of a single Ip4Config, a plugin has Config, Ip4Config, and
Ip6Config. "Config" contains information which is neither IPv4 nor
IPv6 specific, and also indicates which of Ip4Config and Ip6Config are
present. Ip4Config now only contains the IPv4-specific bits of
configuration.
There is backward compatibility in both directions: if the daemon is
new and the VPN plugin is old, then NM will notice that the plugin
emitted the Ip4Config signal without having emitted the Config signal
first, and so will assume that it is IPv4-only, and that the generic
bits of configuration have been included with the Ip4Config. If the
daemon is old and the plugin is new, then NMVPNPlugin will copy the
values from the generic config into the IPv4 config as well. (In fact,
NMVPNPlugin *always* does this, because it's harmless, and it's easier
than actually checking the daemon version.)
Currently the VPN is still configured all-at-once, after both IPv4 and
IPv6 information has been received, but the APIs allow for the
possibility of configuring them one at a time in the future.
The signal is private for libnm-glib and should not be used externally.
It is emitted when there's an error while creating an object.
In addition, this commit makes use of the signal in NMClient to ensure
that the callbacks are always called for nm_client_activate_connection()
and nm_client_add_and_activate_connection().
Otherwise if a client holds references to the objects (or in the
JavaScript case, uses deferred garbage collection) they'll still
be in the cache when NM restarts, and the old object may have the
same path as some new object, which isn't good.
When NMClient changes state to "not running", don't just unref all the
devices and connections: emit notify::active-connections and
device-removed signals too, so the app will drop its copies of them.
https://bugzilla.gnome.org/show_bug.cgi?id=674473
In some situations, objects might get used after being disposed, so
clear out their various priv fields so we don't try to access unreffed
objects, freed strings, etc.
https://bugzilla.gnome.org/show_bug.cgi?id=674473
No idea *why* they're NULL, unless perhaps that dbus-glib can't demarshal
the variants for some reason, but until we know why at least log the
problem so we know what properties the issue might affect.
If a client keeps the connection around after NMRemoteSettings is done
with it (and has emitted 'removed' for that connection) then the
RemoteSettings object was still registered to receive signals for
that connection. To prevent clients from being able to screw up
the RemoteSettings, disconnect any signals it may be listening for
when the connection is removed. (it should be doing that anyway)
This reverts commit dd0460697c.
The commit dd0460697c make nm_remote_settings_new()
create the NMRemoteSettings object synchronously. It fixed getting properties,
but undid the previous ability to initialize the object asynchronously.
It can be reverted now, because a4f450aa0b commit
ensure initialization in get_property() calls.
We need to do _nm_object_ensure_inited() /
_nm_remote_settings_ensure_inited() from the get_property()
implementations; in most cases, get_property() just calls another
accessor method (which will call _nm_object_ensure_inited()), but in a
few places, it reads priv->whatever directly, so we need to make sure
that it's valid.
Most of the stuff was done by 762df85234.
But to allow this piece of code:
from gi.repository import NMClient
nmclient = NMClient.Client()
print nmclient.get_active_connections()
we also need to set "dbus-path" property in NMClient constuctor(),
else parent NMObject is not properly constructed.
Bindings (like GObject Introspection) almost always create objects
using g_object_new() by default and don't use our helper functions
like nm_client_new(). Thus we need to make sure that if the
object is created in that way, any property accesses or functions
that return properties ensure that the object is fully initialized,
which is what the _new() functions were supposed to do. In one
case in NMClient that was missing (getting active connections)
and wasn't happening at all in NMRemoteSettings, which are our two
entry points into libnm-glib.
This allows this python+GI sequence to return the expected active
connection list:
from gi.repository import NMClient
nmclient = NMClient.Client(dbus_path='/org/freedesktop/NetworkManager')
active = nmclient.get_active_connections()
print(active)
where previously it returned an empty list because the NMClient
wasn't fully initialized by the time nm_client_get_active_connections()
was called.
Add nm_device_connection_compatible() that returns an error when it fails.
nm_device_connection_valid() does the same work except it doesn't set GError.
First: object creation requests get triggered each time a property
that refers to the object is read. That can happen from a couple
of places around the same time (like initialization) and to be
expected. But when those requests are processed (after we've
determined the type of object to create) a previous request may
have already created the object. If that's the case don't create
a duplicate.
Second: properties can also be updated from a few places which
don't know about each other (from both regular code and the
"pseudo property" signal handlers) so when adding objects to
array properties, make sure the object hasn't already been
added to that array.
Active Device objects held a reference to their ActiveConnection
which also held a reference back to the Device. Ensure that's
broken so everyone can get disposed correctly.
When NM was registering all of its enum types by hand, it was using
NamesLikeThis rather than the default names-like-this for the "nick"
values. When we switched to using glib-mkenums, this resulted in
dbus-glib using different strings for the D-Bus error names, causing
compatibility problems.
Fix this by using glib-mkenums annotations to manually fix all the
enum values back to what they were before. (This can't be done in a
more automated way, because the old names aren't 100% consistent. Eg,
"UNKNOWN" frequently becomes "UnknownError" rather than just
"Unknown".)
NM emits coalesced PropertiesChanged signals, which might be
delayed slightly and thus sent after the StateChanged signal
for devices. Clients of libnm-glib listening for the
'state-changed' signal and then querying the state manually
using nm_device_get_state() would still see the old state until
it was updated via the delayed PropertiesChanged signal
processing. Since when the StateChanged signal comes in the
device is already in the new state, just update the state and
leave the GObject property notify signal to the
PropertiesChanged signal handling code so that clients have
an accurate device state.
Fix handle_object_array_property() to deal with receiving an empty
list correctly (rather than warning and leaving the property with its
previous value still set).
Also, add two more untracked properties that shouldn't be warned about
(NMDevice:device-type and NMActiveConnection:vpn, both of which are
only used at construct time).
Rather than generating enum classes by hand (and complaining in each
file that "this should really be standard"), use glib-mkenums.
Unfortunately, we need a very new version of glib-mkenums in order to
deal with NM's naming conventions and to fix a few other bugs, so just
import that into the source tree temporarily.
Also, to simplify the use of glib-mkenums, import Makefile.glib from
https://bugzilla.gnome.org/654395.
To avoid having to run glib-mkenums for every subdirectory of src/,
add a new "generated" directory, and put the generated enums files
there.
Finally, use Makefile.glib for marshallers too, and generate separate
ones for libnm-glib and NetworkManager.
The notifications for child objects (like NMClient's device-added
signal or NMDeviceWifi's access-point-added signal) could get emitted
before the child objects were actually constructed, because
object_created() decrements the properties-retrieved tracking
variable, which wasn't always incremented before calling that
function.
Need to initialize libnm-util to get GValue transforms registered
so the property values print out as strings. Then actually print
some debugging information about properties.
Some property updates (mainly those dealing with properties that
hold objects themsevles) weren't being done in a synchronous manner
when synchronicity was requested. Make sure that happens.
Implement GInitable and GAsyncInitable in NMObject, with
implementations that synchronously or asynchonously load all
properties, and change _nm_object_ensure_inited() to run
g_initable_init().
Update the object/object-array property handling to initialize the
objects after creating them (synchronously or asynchronously,
according to the situation), so that they will have all of their
properties preloaded before they are ever visible to the caller.
Move the non-blocking/non-failable parts of various objects'
constructor() methods to constructed(), and move the blocking/failable
parts to init(), and implement init_async() methods with non-blocking
versions of the blocking methods.
Make nm_device_new() and nm_client_new() call
_nm_object_ensure_inited(), to preserve the behaviour formerly
enforced by their construct() methods, that properties are guaranteed
to be initialized before any signals involving them are emitted.
Add generic handling for "properties" that consist of a "Get" method,
an "Added" signal, and a "Removed" signal, reusing some of the code
for handling object-array-valued properties. And load the values of
pseudo properties from _nm_object_reload/ensure_properties as well.
Add an "object_type" field to NMPropertiesInfo, and use that with
DBUS_TYPE_G_OBJECT_PATH and DBUS_TYPE_G_ARRAY_OF_OBJECT_PATH
properties so that we don't need custom marshallers for each one.
When creating an NMDevice or NMActiveConnection, we need to fetch an
extra property first to figure out the exact subclass to use, so add a
bit of infrastructure for that as well. Also, do that preprocessing
asynchronously when processing a property change notification, so that
it doesn't block the main loop.
Rather than having every property getter method have code to fetch
that specific property's value, just call the new
_nm_object_ensure_inited() (which makes sure that we've read all the
property values on the object at least once), and then return the
cached value. (After we've read the initial property values, the
PropertiesChanged signal handler will ensure that the values are kept
up to date, so we can always just return cached property values after
that point.)
This then lets us get rid of _nm_object_get_property() and its
wrappers.
Rename _nm_object_handle_properties_changed(), etc, to be about
properties in general, rather than just property changes.
Interpret func==NULL in NMPropertiesInfo as meaning "use
_nm_object_demarshal_generic", and then reorder the fields so that you
can just leave that field out in the declarations when it's NULL.
Add a way to register properties that exist in D-Bus but aren't
tracked by the NMObjects, and use that for NMDevice's D-Bus Ip4Address
property, replacing the existing hack.
Also add a few other missing properties noticed along the way.
Most of the code was using dbus_g_proxy_call() directly, but there
were some leftover uses of the generated bindings. Make things more
consistent by using dbus_g_proxy_call() everywhere, and stop building
the -bindings.h files.
Adds a new "master" property to NMActiveConnection containing the path
of the master NMDevice if the connection has a master.
Signed-off-by: Thomas Graf <tgraf@redhat.com>
The errors appeared due to calling GetAccessPoints() on removed devices:
nm_device_wifi_get_access_points: error getting access points: Method "GetAccessPoints" with signature "" on interface "org.freedesktop.NetworkManager.Device.Wireless" doesn't exist
NMClient and NMDevice used a 'lazy' approach for getting stuff from D-Bus, i.e.
requesting data from NM when they are asked for. However, for some cases, like
removing devices it is not optimal. libnm-glib will never see a device that was
removed, but not added during NMClient's lifetime.
So let's get devices list in NMClient's constructor and device properties
in NMDevice constructor to have the data from the beginning.
NMRemoteSettings's constructor requires a DBusGConnection, but there
currently aren't any usable gobject-introspection bindings for that class.
This means that NMRemoteSettings can't be used over gobject-introspection.
Move the default fallback to the system bus into the constructor path, so
that introspection bindings are usable.
Python test case:
from gi.repository import NMClient
NMClient.RemoteSettings()
Before, this produced a segfault. Now it returns a usable RemoteSettings
object.
When a partial connection is passed to nm_client_add_and_activate_connection(),
but it doesn't contain any settings, nm_connection_to_hash() returns NULL and
there's a crash later on the NULL hash.
G_VALUE_HOLDS will fail if the value variable is NULL, so we only
want to check that the GValue holds the right type if the value
is valid. NULL means "no object path" in demarshallers.
Since D-Bus doesn't allow NULL or zero-length object paths, NM
uses "/" as a placeholder here. Make sure the generic marshalling
code handles that so we don't have to do it in multiple places and
simplify handling of NULL objects somewhat.
Like the *_filter_connections() functions, but for just one connection,
and now the *_filter_connections() functions call these new ones so
it's really just moving code around and not anything new.
These new functions more closely match the usage I've seen from
gnome-shell's network.js and elsewhere.
If the client knows the UUID, add a convenience function to get
the connection path directly, instead of having to iterate the
whole connection list and get each connection's details and then
check the UUID.
A convenience so that clients which might key certain operations off
which connections are active (checking work mail only when on VPN for
example) can more easily get which connections are active. This would
allow those apps to store the UUID (which they would already be doing)
and not have to create a Connection proxy and then get the connection
properties just to retrieve the UUID of the connection. Instead they
can now get it from GetAll of the ActiveConnection object, which they
would already be doing.
Not just the ones we built; if you're switching often between
git branches, there will be some generated files left over from
the other branch, which then the docs generation stuff pick up
and pollute your autogenerated docs with stuff from other branches.
So just clean up everything on make clean.
To make the API more consistent, instead of returning an
ActiveConnection object path, return the actual NMActiveConnection
object itself. Suggested by Matthias Clasen.
Apparently dbus-glib will pass non-NULL parameters to proxy
callbacks in the error case, so we've got to make sure we don't
touch any return parameters if there's been an error.
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.
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.
DISCONNECTING: the only active network connection is now being disconnected
LOCAL, SITE, GLOBAL: one-stop items for level of connectivity, which
we'll use to show when we think we're actually connected to the internet
or behind a captive portal or something
sleep, wake, StateChange, all deprecated in 0.8, are now removed.
sleep & wake are replaced with the Sleep() method, while
StateChange is replaced with the StateChanged signal which has
the same arguments.
