nm_access_point_get_ssid() used to return NULL if the AP didn't have a
visible SSID. This got broken in the NM_TYPE_SSID -> G_TYPE_BYTES
change. Fix that. (Fixes a crash in nmtui and nmcli with SSID-less
APs.)
https://bugzilla.gnome.org/show_bug.cgi?id=736802
Port libnm-core/libnm to GDBus.
The NetworkManager daemon continues to use dbus-glib; the
previously-added connection hash/variant conversion methods are now
moved to NetworkManagerUtils (along with a few other utilities that
are now only needed by the daemon code).
Several test programs create connection hashes and then modify them in
various ways. This becomes much more complicated with GVariants, since
they are immutable. Add NMTST_VARIANT_EDITOR() to simplify the process
of iterating the old variant and building a new, slightly-modified one.
In preparation for porting to GDBus, make nm_connection_to_dbus(),
etc, represent connections as GVariants of type 'a{sa{sv}}' rather
than as GHashTables-of-GHashTables-of-GValues.
This means we're constantly converting back and forth internally, but
this is just a stepping stone on the way to the full GDBus port, and
all of that code will go away again later.
dbus-glib's functions to get a DBusGConnection or a DBusGProxy return
right away, but gdbus's corresponding functions do some initial setup
and communication as part of initialization, and so either block or
run async. So split _nm_dbus_new_connection() and
_nm_dbus_new_proxy_for_connection() into sync and async versions now,
and update NMObject to use the correct one depending on whether it is
working synchronously or asynchronously.
NMObject has a system that lets devices and active connections get
created as the correct subtypes (NMDeviceFoo / NMActiveConnection vs
NMVpnConnection). But it was much more generic than it needed to be,
because NMDevice and NMActiveConnection both did the same thing (fetch
a D-Bus property and then look at its value). So move the
property-fetching part into NMObject, and only use the callback for
converting the property value to a GType.
Add _nm_object_class_add_interface(), for declaring that a class
implements a particular interface, and then have NMObject create the
corresponding proxies itself. (The subclass can get a copy with
_nm_object_get_proxy() if it needs it for something).
(In GDBus, creating a proxy is a heavier operation than in dbus-glib,
so we'll need to create the proxies asynchronously. Moving the
creation to NMObject makes that easier since we can do it as part
of the existing init/init_async.)
There's not much point in keeping them separate: all existing
libnm-glib-vpn users also link against libnm-glib, and the amount of
extra code added to libnm by merging in libnm-vpn is negligible.
Additionally, nm-vpn-plugin will later need access to some
libnm-internal APIs.
So, merge them together.
Compile srcdir into test-dispatcher-envp rather than passing it on the
command-line, to make it easier to run by hand, and so we can use
automake's TESTS support.
Reorganize some code in preparation for the GDBus port. (Most of the
diff is actually just reindentation.)
This also makes explicit something that was probably a bug;
IP4_NUM_ROUTES is always set, even if it's "0" (while the same is not
true of IP6_NUM_ROUTES). (This behavior is preserved for
compatibility.)
The rewrite mistakenly used nm_connection_add_setting() rather than
_nm_connection_add_setting(), causing it to emit the "changed" signal
while the connection was only partially rebuilt.
If two code paths try to asynchronously create the same object at the
same time (eg, because it shows up in two different properties), we
are supposed to deal with that. But at some point a race condition
appeared where we could end up returning a partially-initialized
object for one of the properties in the async case. Fix that.
Also add comments to both the sync and async cases explaining why they
work the way they do.
If _nm_object_create() hit an error, it would return the
(half-initialized) object anyway. If _nm_object_create_async() hit an
error, it would return NULL, but leak the half-initialized object. Fix
both cases.
libnm-util's connection deserializing/copying/replacing functions have
odd semantics where sometimes they both modify a connection AND return
an error. libnm-core tried to improve things by guaranteeing that the
connection would not be modified if the new settings were invalid, but
this ended up breaking a bunch of places that needed to be able to
work with invalid connections. So re-fix the functions by reverting
back to the old semantics, but having return values that clearly
distinguish whether the connection was modified or not.
For comparison:
- nm_connection_new_from_hash() / nm_simple_connection_new_from_dbus():
- libnm-util: returns a valid connection or NULL.
- OLD libnm-core: returned a valid connection or NULL.
- NEW libnm-core: returns a valid connection or NULL.
- nm_connection_duplicate() / nm_simple_connection_new_clone():
- libnm-util: always succeeds, whether or not the connection is
valid.
- OLD libnm-core: returned a valid connection or NULL
- NEW libnm-core: always succeeds, whether or not the connection
is valid.
- nm_connection_replace_settings_from_connection():
- libnm-util: always replaces the settings, but returns FALSE if
the connection is now invalid.
- OLD libnm-core: either replaced the settings and returned TRUE
(if the settings were valid), or else left the connection
unchanged and returned FALSE (if not).
- NEW libnm-core: always replaces the settings, and has no
return value. (The modified connection is valid if and only if
the replaced-from connection was valid; just like with the
libnm-util version.)
- nm_connection_replace_settings():
- libnm-util: returns TRUE if the new settings are valid, or
FALSE if either (a) the new settings could not be deserialized
and the connection is unchanged, or (b) the new settings were
deserialized, and the connection was updated, but is now not
valid.
- OLD libnm-core: either replaced the settings and returned TRUE
(if the settings were valid), or else left the connection
unchanged and returned FALSE (if not).
- NEW libnm-core: returns TRUE if the connection was updated
(whether or not it is valid), or FALSE if the new settings
could not be deserialized and the connection is unchanged.
It needs to be possible to deserialize a connection hash into an
invalid NMConnection; in particular, AddAndActivateConnection()
explicitly allows this.
Previously, the SetFunc and NotSetFunc passed to
_nm_setting_class_override_property() could return a verification
error immediately, but this functionality has to go away if we're
going to be able to deserialize invalid connections.
That functionality was only used in the handling of invalid virtual
interface names; reorganize how that code works so that
NMSettingConnection does all of the verification itself. (The code to
make sure that it returned the "correct" error domain in that case
turned out to be irrelevant, since the setting error domains don't get
serialized over D-Bus correctly anyway.)
Empty array-valued properties should return a 0-length array from
get_property(), but should also accept NULL as equivalent to a
0-length array from set_property().
UINT is just 32bit, truncating the GType on 64-bit platforms. We do already use
cast to SIZE, which is as wide as a pointer, when we need a GType in another
place (nmtui); let's do it here as well.
Broken by [0bc1b5138] core: add support for internal device factories
https://bugzilla.gnome.org/show_bug.cgi?id=736780
DHCP client may be killed by SIGPIPE when attempting to write to a broken pipe.
This can be observed, for example, when journald is restarted.
Fix that by redirecting both stdout and stderr to /dev/null. The client logs
into syslog anyway. When NetworkManager is run with '--debug' we duplicate
syslog to stderr, so the messages goes to terminal as well.
Testcase:
- start a NetworkManager service by systemd
- activate an DHCP ethernet connection
- sudo systemctl restart systemd-journald.service
- reactive the ethernet connection (nmcli con up <my-eth>)
- DHCP client is killed by SIGPIPE right after its startup:
<info> (enp0s25): DHCPv4 client pid 13959 exited with status -1
<warn> DHCP client died abnormally
Another possible fix would be ignoring SIGPIPE in the DHCP client as it is not
useful in most cases. E.g. systemd ignores SIGPIPE for its services, by
default:
http://cgit.freedesktop.org/systemd/systemd/commit/?id=353e12c2f4a9e96a47eb80b80d2ffb7bc1d44a1bhttps://bugzilla.gnome.org/show_bug.cgi?id=735962
