The entry can't be empty. Otherwise removing the value and saving connection
would result in the primary option containing only the first character of the
original value.
clang warns about uninitialized variables @__cur_setting_name and
@__cur_property_name as used inside @__code. Before calling to @__code,
explicitly initialize the values.
Making all in tests
make[4]: Entering directory `./NetworkManager/libnm-core/tests'
CC test-general.o
test-general.c:2730:24: error: variable '__cur_property_name' is uninitialized when used here [-Werror,-Wuninitialized]
NMTST_VARIANT_DROP_PROPERTY (NM_SETTING_CONNECTION_SETTING_NAME,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../include/nm-test-utils.h:1079:20: note: expanded from macro 'NMTST_VARIANT_DROP_PROPERTY'
&& !strcmp (__cur_property_name, __property_name)) \
^~~~~~~~~~~~~~~~~~~
../../include/nm-test-utils.h:1023:3: note: expanded from macro 'NMTST_VARIANT_EDITOR'
__code; \
^
test-general.c:2729:2: note: variable '__cur_property_name' is declared here
NMTST_VARIANT_EDITOR (connection_dict,
^
../../include/nm-test-utils.h:1015:3: note: expanded from macro 'NMTST_VARIANT_EDITOR'
const char *__cur_setting_name, *__cur_property_name; \
^
[...]
Signed-off-by: Thomas Haller <thaller@redhat.com>
When the caller wants to clear all settings (thus providing
@setting_name NULL), a NM_VARIANT_TYPE_CONNECTION variant is
expected. This would lead to a crash when constructing the
@error literal due to uninitialized @key.
Clang also warns:
Making all in .
make[4]: Entering directory `./NetworkManager/libnm-core'
CC nm-connection.lo
../libnm-core/nm-connection.c:1016:25: error: variable 'key' is uninitialized when used here [-Werror,-Wuninitialized]
key);
^~~
../libnm-core/nm-connection.c:962:17: note: initialize the variable 'key' to silence this warning
const char *key;
^
= NULL
1 error generated.
Fixes: acf86f68b3
Signed-off-by: Thomas Haller <thaller@redhat.com>
Check whether NM is running before comparing nmcli and NM versions. Returning
NMC_RESULT_ERROR_NM_NOT_RUNNING is in accordance with other nmcli commands.
Applies to status commands such as "nmcli radio" or "nmcli g status".
This is consistent with other commands.
The "RUNNING" field is now always "running", the tool will just return
an error instead of setting it to "not running". It never signalled
whether the daemon was actually running anyway, only whether the client
managed to connect to it.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Seems like 128k is not enough for systems with many interfaces. This adds 4k
per device, while keeping the 128k minimum. Therefore this change only
affects systems with more than 32 interfaces.
https://bugzilla.redhat.com/show_bug.cgi?id=1141256
dcbw points out that g_dbus_connection_get_unique_name() can be used
to distinguish private from bus connections without us needing to keep
track ourselves.
_nm_dbus_new_connection_async() wasn't marking the connection as
private when it was private, causing
_nm_dbus_new_proxy_for_connection*() to pass the wrong args. Fix that.
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.)
