GitLab

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.

The .h file should have the same name as the .c file.

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.)

Use the #defines provided by libdbus instead.

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.

The test settings service wasn't exporting a Connections property.

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.

Port nm-dispatcher to GDBus, mostly, using dbus-glib's GVariant
utilities to translate the return value of nm_connection_to_dbus().

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.)

Accept NULL as equivalent to a 0-length array from set_property().

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.

nmtui-connect.c claimed that it didn't implement deactivation yet, but
that was implemented long ago.

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.

Now that NMRemoteConnection is an NMObject, the code only creates
NMObjects, so we don't need that check.

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().

This reverts commit c0ecd2f6.

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 [0bc1b513] core: add support for internal device factories

https://bugzilla.gnome.org/show_bug.cgi?id=736780

https://bugzilla.gnome.org/show_bug.cgi?id=736753

Allow each page type to specify whether it should be shown by default,
letting us simplify NmtPageMain.

A "Cur Hop Limit" field value of 0 in a router advertisement means
"unspecified by this router" and should not be set in the kernel.

NMSettingIP4Config:dns is NULL if no DNS servers are set

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=353e12c2f4a9e96a47eb80b80d2ffb7bc1d44a1b

https://bugzilla.gnome.org/show_bug.cgi?id=735962

Fix build broken by beb18050

https://bugzilla.gnome.org/show_bug.cgi?id=736289