As NM_SETTING_SECRET_FLAGS_ALL is used in libnm/nm-vpn-plugin-utils.c,
it is exposed as internal API and should be declared in
nm-core-internal.h.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Add a header file to expose private utility functions from libnm-core
that can be used by NetworkManager (core) and libnm.so. The header
is also used to give privileged access to libnm-core. Since NM links
statically, these functions are not exported and not part of public ABI.
This also removes the NM_UTILS_PRIVATE_CALL() macro and libnm.so no
longer exports nm_utils_get_private().
Before, this functionality was partly declared in nm-utils-private.h.
This was wrong because nm-utils-private.h is for functionality
entirely private to libnm-core.
Signed-off-by: Thomas Haller <thaller@redhat.com>
A few of the settings plugins were calling nm_connection_clear_secrets()
from their finalize() method, but this call can emit signals, and by
the time finalize() runs, the object has a refcount of 0. Signals
cannot be emitted from a finalized object, but instead could be
emitted from dispose() before the object is finalized.
Instead of moving the nm_connection_clear_secrets() to dispose() in each
plugin, make the behavior generic instead. The settings plugins' parent
object is NMSettingsConnection, so clear secrets there. Plus,
NMSettingsConnection caches system & agent secrets with NMSimpleConnection
objects, so clear secrets in NMSimpleConnection's dispose too.
Commit fb6cde50 changed from setBlobs in the old wpa_supplicant D-Bus
interface, which returned an integer status code, to AddBlob in the new
one, which doesn't, but didn't account for that change. That caused
error messages of the form "Couldn't set network certificates: Too few
arguments in reply." on valid connection requests.
Signed-off-by: Geoffrey Thomas <gthomas@mokafive.com>
When connecting a master connection, no slave devices will be activated
automatically. The user is supposed to activate them individually.
Hence nmcli should not wait for the connection to be fully activated
because that is not going to happen (unless the user connects a slave
connection from another terminal).
Instead, for master connections behave differently and signal success
once the master device reaches IP_CONFIG state.
This revises behavior introduced by commit
47710f8211.
https://bugzilla.gnome.org/show_bug.cgi?id=733641
Signed-off-by: Thomas Haller <thaller@redhat.com>
Signed-off-by: Jiří Klimeš <jklimes@redhat.com>
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.
