The fact that NMRemoteConnection has to be an NMConnection and
therefore can't be an NMObject means that it needs to reimplement bits
of NMObject functionality (and likewise NMObject needs some special
magic to deal with it). Likewise, we will need a daemon-side
equivalent of NMObject as part of the gdbus port, and we would want
NMSettingsConnection to be able to inherit from this as well.
Solve this problem by making NMConnection into an interface, and
having NMRemoteConnection and NMSettingsConnection implement it. (We
use some hacks to keep the GHashTable of NMSettings objects inside
nm-connection.c rather than having to be implemented by the
implementations.)
Since NMConnection is no longer an instantiable type, this adds
NMSimpleConnection to replace the various non-D-Bus-based uses of
NMConnection throughout the code. nm_connection_new() becomes
nm_simple_connection_new(), nm_connection_new_from_hash() becomes
nm_simple_connection_new_from_hash(), and nm_connection_duplicate()
becomes nm_simple_connection_new_clone().
NMRemoteConnection had two DBusGConnection properties
(NMRemoteConnection:bus and NMRemoteConnection:dbus-connection) and
two D-Bus path properties (NMConnection:path and
NMRemoteConnection:dbus-path). The former of each pair were the
traditional names, and the latter were added for compatibility with
NMObject.
In libnm, we can just drop NMRemoteConnection:bus, and use the
NMObject-compatible :dbus-connection name instead.
For the path properties, we need to rename either NMConnection:path or
NMObject:dbus-path. Since NMObject already has "nm_object_get_path()"
rather than "nm_object_get_dbus_path()", and it already mistakenly
referred to the property as "NMObject:path" in the gtk-docs, it seemed
to make sense to rename that one rather than the NMConnection one.
(And then, for consistency, rename "nm_object_get_connection()" to
"nm_object_get_dbus_connection()" to also match its property.)
nm_connection_lookup_setting_type() and
nm_connection_lookup_setting_type_by_quark() have nothing to do with
NMConnection. So move them to NMSetting (and rename them to
nm_setting_lookup_type() and nm_setting_lookup_type_by_quark()).
Previously, src/nm-ip4-config.h, libnm/nm-ip4-config.h, and
libnm-glib/nm-ip4-config.h all used "NM_IP4_CONFIG_H" as an include
guard, which meant that nm-test-utils.h could not tell which of them
was being included (and so, eg, if you tried to include
nm-ip4-config.h in a libnm test, it would fail to compile because
nm-test-utils.h was referring to symbols in src/nm-ip4-config.h).
Fix this by changing the include guards in the non-API-stable parts of
the tree:
- libnm-glib/nm-ip4-config.h remains NM_IP4_CONFIG_H
- libnm/nm-ip4-config.h now uses __NM_IP4_CONFIG_H__
- src/nm-ip4-config.h now uses __NETWORKMANAGER_IP4_CONFIG_H__
And likewise for all other headers.
The two non-"nm"-prefixed headers, libnm/NetworkManager.h and
src/NetworkManagerUtils.h are now __NETWORKMANAGER_H__ and
__NETWORKMANAGER_UTILS_H__ respectively, which, while not entirely
consistent with the general scheme, do still mostly make sense in
isolation.
The prototype of dhclient_start() changed in 30cdd1248 but that
commit didn't update stop() correctly. Clearly treating a gboolean
as pid_t isn't going to work. Second, we don't want to watch the
child process on DHCP release because we're just going to kill it
shortly after.
libnm-util is expected to end up behind the curve in terms of knowing
about new NMSetting properties, so if it sees an unknown property, it
should just assume that there will also be a backward-compatibility
equivalent rather than printing a warning.
(In particular, it should not warn when it sees the
"ipv4.address-labels" property now that it now longer knows about it.)
For devices where we don't set the hardware address at construct time,
the first call to nm_device_update_hw_address() was hitting a
return-if-fail.
Also, when updating the hardware address, we were leaking the old
value.
Due to behavioral change of test-networkmanager-service.py, the test
/remote_settings/remove_connection fails (test_remove_connection() at
test-remote-settings-client.c:318).
Fixes: 66a3480329
Signed-off-by: Thomas Haller <thaller@redhat.com>
Rather than having test-crypto and test-setting-8021x be programs that
you have to pass arguments to to get them to run a single test, just
have them run all of the tests themselves.
This lets us get rid of the big "check-local" rule in Makefile.am and
just use TESTS to run everything.
https://bugzilla.gnome.org/show_bug.cgi?id=734388
Since NMRemoteSettings doesn't announce new connections until it has
fetched their properties, it's possible that a connection could get
deleted while we're waiting for it to be created. NMRemoteSettings has
code to deal with this, so add a test to make sure that it works.
NMRemoteSettings was looking for a signal handler on an
NMRemoteConnection using only G_SIGNAL_MATCH_FUNC, which means it
would get tripped up if a connection was known to two different
NMRemoteSettings objects at once. Although that can't happen now, it
might in the future if NMRemoteConnection became an NMObject, so use
G_SIGNAL_MATCH_DATA too.
Remove NMRemoteConnection::updated, which since 0.9.10 has been
redundant with NMConnection::changed. (We still handle the incoming
D-Bus signal, we just don't re-emit it as "updated", since the call to
nm_connection_replace_settings() already results in it emitting
"changed".)
NMRemoteSettings duplicates a bunch of NMObject's functionality that
it doesn't need to. In libnm-glib, it wouldn't have been possible to
port NMRemoteSettings to NMObject without breaking ABI, but now in
libnm we can do that.
As a side effect of this, NMRemoteSettings gains a "connections"
property, and "connection-added" and "connection-removed" signals
(with the former replacing the old "new-connection" signal). This also
removes the "connections-loaded" signal, since the connections will
now always be loaded (via the initialization of the "connections"
property) during init()/init_async().
Also, this removes NMRemoteConnection's "removed" signal, since it's
redundant with the new NMRemoteSettings::connection-removed (and
having the signal on NMRemoteSettings instead is more consistent with
other objects).
NMClient was watching to see whether NetworkManager was running, but
its parent class NMObject was already doing that anyway, so NMClient
doesn't need to do it itself.
This also requires making NMClient:init_async() wait for NMObject's
init_async() code to finish before calling GetPermissions, rather than
running the two in parallel like before (since we don't know if NM is
running or not until after NMObject's init_async() returns). This is
probably more correct anyway in terms of inheritance, and it's not as
much slower than the original code as it sounds, since previously
we were calling NameHasOwner twice (in serial) anyway.
_nm_client_is_object_path() had been copied from
g_variant_is_object_path() with a note that it should be replaced when
we depended on GLib > 2.24, but it got missed when we actually updated
the dependency. Fix it now. (Also fix a nearby typo.)
Now that we have nm_utils_hwaddr_matches() for comparing addresses
(even when one is a string and the other binary), there are now places
where it's more convenient to store hardware addresses as strings
rather than binary, since we want them in string form for most
non-comparison purposes. So update for that.
In particular, this also changes nm_device_get_hw_address() to return
a string.
Also, simplify the update_permanent_hw_address() implementations by
assuming that they will only be called once. (Since they will.)
Add nm_utils_hwaddr_matches(), for comparing hardware addresses for
equality, allowing either binary or ASCII hardware addresses to be
passed, and handling the special rules for InfiniBand hardware
addresses automatically. Update code to use it.
Include <linux/if_ether.h> and <linux/if_infiniband.h> from
nm-utils.h, to get ETH_ALEN and INFINIBAND_ALEN, and remove those
includes (as well as <net/ethernet.h> and <netinet/ether.h>, and
various headers that had been included to get the ARPHRD_* constants)
from other files where they're not needed now.
Lots of old code used struct ether_addr to store hardware addresses,
and ether_aton() to parse them, but more recent code generally uses
guint8 arrays, and the nm_utils_hwaddr_* methods, to be able to share
code between ETH_ALEN and INFINIBAND_ALEN cases. So update the old
code to match the new. (In many places, this ends up getting rid of
casts between struct ether_addr and guint8* anyway.)
(Also, in some places, variables were switched from struct ether_addr
to guint8[] a while back, but some code still used "&" when referring
to them even though that's unnecessary now. Clean that up.)
Drop the arptype-based nm_utils_hwaddr funcs, and rename the
length-based ones to no longer have _len in their names. This also
switches nm_utils_hwaddr_atoba() to using a length rather than an
arptype, and adds a length argument to nm_utils_hwaddr_valid() (making
nm_utils_hwaddr_valid() now a replacement for nm_utils_hwaddr_aton()
in some places, where we were only using aton() to do validity
checking).
This test is quite broken and fails often. It does not fail
always, but the changes for a failure are high.
We certainly should fix that, but for now exclude the test from
`make check`.
Signed-off-by: Thomas Haller <thaller@redhat.com>
test_libnm_linking() executes ./test-libnm-linking which
is supposed to crash. When the user set `ulimit -c unlimited`
before, this will leave a left-over core file.
In case of `make distcheck`, this is quite bad because it lets
the make target fail:
ERROR: files left in build directory after distclean:
./libnm-util/tests/core.31481
Fix this by setting the (soft) rlimit for writing core files
to 0 before executing the test binary.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Types passed to dbus-glib need to be GTypes, not D-Bus type. While the
DBUS_TYPE_G_* macros are GTypes from libdbus-glib, the other DBUS_ types
aren't.
Signed-off-by: Geoffrey Thomas <gthomas@mokafive.com>
Signed-off-by: Thomas Haller <thaller@redhat.com>
