In some cases, code may look at the value of an array-valued property
during object initialization, before NMObject has set it to its actual
initial value. So ensure that we initialize all such properties to an
empty array, rather than leaving them NULL.
Also fix another bug in NMClient that could result in
priv->active_connections being NULL during certain signal emissions,
and fix nm_client_get_active_connections() to not return NULL when NM
was not running.
PPPoE connections involve two different network connections, making it
ambiguous what the "Device" field refers to. Clarify that it refers to
the Ethernet device, not the PPP device.
Routing configuration fails to apply if the device is not IFF_UP, so if
we're going to apply IP configuration to the device, make sure it's IFF_UP
first.
https://bugzilla.gnome.org/show_bug.cgi?id=738479
When a child device is found and an IP configuration already exists
for it even though it is under NM control (like when pppd applies
IP config to a WWAN device before NM gets the IP details from the pppd
plugin), don't deconfigure the child device when removing it from the
device list, because this breaks the device's configuration.
https://bugzilla.gnome.org/show_bug.cgi?id=738479
A generated connection contains a copy of the device's existing
configuration, so it's entirely redundant to merge the connection
back into the device's IP config. But even though that should
result in no changes to the IP config, NMSettingIPxConfig treats a
route metric of '0' as the device priority, while NMIPxConfig
allows 0 as a valid route metric. Since the setting values
are preferred (they are supposed to be user-supplied and thus
override anythign else, but in this case they are generated and
thus not user-supplied) external routes with a metric of 0 are
overwritten with the device priority metric.
https://bugzilla.gnome.org/show_bug.cgi?id=738268
When using a private bus connection, the service is never marked
as running when settings are initialized asynchronously. Successfully
opening a socket in NM's runtime directory should already imply
a running service, so just mark it as such (as we already do in
the synchronous path).
This adds service discovery via SDP and RFCOMM tty management to
NetworkManager, as it was dropped from Bluez.
Based on work by Dan Williams <dcbw@redhat.com>.
The SDP discovery is based on code from Bluez project.
We'll need it for bluez5 DUN support.
[lkundrak@v3.sk: Turn the addresses to strings from guint8[ETH_ALEN], as that
is what rest of NetworkManager uses for MAC addresses and what Bluez utility
functions expect as well.]
Previously, nm_setting_diff() (and thus nm_connection_diff()), returned
only properties that are different AND not set to the default value.
However, if the opposite setting 'B' was missing, it would always
include all properties from 'A', even the default ones.
This behaviour was asymetric. Add two new compare flags
@NM_SETTING_COMPARE_FLAG_DIFF_RESULT_WITH_DEFAULT and
@NM_SETTING_COMPARE_FLAG_DIFF_RESULT_NO_DEFAULT to control the
behaviour of whether to include default properties.
Signed-off-by: Thomas Haller <thaller@redhat.com>
The functions nm_setting_clear_secrets(),
nm_setting_clear_secrets_with_flags(), and nm_setting_need_secrets()
are not used outside of libnm-core. Remove them from public API.
Signed-off-by: Thomas Haller <thaller@redhat.com>
When secret providers return the connection hash in GetSecrets(),
this hash should only contain secrets. However, some providers also
return non-secret properties.
for_each_secret() iterated over all entries of the @secrets hash
and triggered the assertion in nm_setting_get_secret_flags() (see
below).
NM should not assert against user provided input. Change
nm_setting_get_secret_flags() to silently return FALSE, if the property
is not a secret.
Indeed, handling of secrets is very different for NMSettingVpn and
others. Hence nm_setting_get_secret_flags() has only an inconsistent
behavior and we have to fix all call sites to do the right thing
(depending on whether we have a VPN setting or not).
Now for_each_secret() checks whether the property is a secret
without hitting the assertion. Adjust all other calls of
nm_setting_get_secret_flags(), to anticipate non-secret flags and
assert/warn where appropriate.
Also, agent_secrets_done_cb() clears now all non-secrets properties
from the hash, using the new argument @remove_non_secrets when calling
for_each_secret().
#0 0x0000003370c504e9 in g_logv () from /lib64/libglib-2.0.so.0
#1 0x0000003370c5063f in g_log () from /lib64/libglib-2.0.so.0
#2 0x00007fa4b0c1c156 in get_secret_flags (setting=0x1e3ac60, secret_name=0x1ea9180 "security", verify_secret=1, out_flags=0x7fff7507857c, error=0x0) at nm-setting.c:1091
#3 0x00007fa4b0c1c2b2 in nm_setting_get_secret_flags (setting=0x1e3ac60, secret_name=0x1ea9180 "security", out_flags=0x7fff7507857c, error=0x0) at nm-setting.c:1124
#4 0x0000000000463d03 in for_each_secret (connection=0x1deb2f0, secrets=0x1e9f860, callback=0x464f1b <has_system_owned_secrets>, callback_data=0x7fff7507865c) at settings/nm-settings-connection.c:203
#5 0x000000000046525f in agent_secrets_done_cb (manager=0x1dddf50, call_id=1, agent_dbus_owner=0x1ddb9e0 ":1.39", agent_username=0x1e51710 "thom", agent_has_modify=1, setting_name=0x1e91f90 "802-11-wireless-security",
flags=NM_SETTINGS_GET_SECRETS_FLAG_ALLOW_INTERACTION, secrets=0x1e9f860, error=0x0, user_data=0x1deb2f0, other_data2=0x477d61 <get_secrets_cb>, other_data3=0x1ea92a0) at settings/nm-settings-connection.c:757
#6 0x00000000004dc4fd in get_complete_cb (parent=0x1ea6300, secrets=0x1e9f860, agent_dbus_owner=0x1ddb9e0 ":1.39", agent_username=0x1e51710 "thom", error=0x0, user_data=0x1dddf50) at settings/nm-agent-manager.c:1139
#7 0x00000000004dab54 in req_complete_success (req=0x1ea6300, secrets=0x1e9f860, agent_dbus_owner=0x1ddb9e0 ":1.39", agent_uname=0x1e51710 "thom") at settings/nm-agent-manager.c:502
#8 0x00000000004db86e in get_done_cb (agent=0x1e89530, call_id=0x1, secrets=0x1e9f860, error=0x0, user_data=0x1ea6300) at settings/nm-agent-manager.c:856
#9 0x00000000004de9d0 in get_callback (proxy=0x1e47530, call=0x1, user_data=0x1ea10f0) at settings/nm-secret-agent.c:267
#10 0x000000337380cad2 in complete_pending_call_and_unlock () from /lib64/libdbus-1.so.3
#11 0x000000337380fdc1 in dbus_connection_dispatch () from /lib64/libdbus-1.so.3
#12 0x000000342800ad65 in message_queue_dispatch () from /lib64/libdbus-glib-1.so.2
#13 0x0000003370c492a6 in g_main_context_dispatch () from /lib64/libglib-2.0.so.0
#14 0x0000003370c49628 in g_main_context_iterate.isra.24 () from /lib64/libglib-2.0.so.0
#15 0x0000003370c49a3a in g_main_loop_run () from /lib64/libglib-2.0.so.0
#16 0x000000000042e5c6 in main (argc=1, argv=0x7fff75078e88) at main.c:644
Signed-off-by: Thomas Haller <thaller@redhat.com>
Add configuration option NMSettingConnection:autoconnect-priority.
This new option is only relevant for connections that are set to
autoconnect. When having more then one candicate for autoconnect, this
new setting allows to always prefer one connection over the other.
If both connections have the same priority setting, the previous
automatism is used to choose the best candidate. That is, NM will
choose the least recently connected candidate.
See also the still unresolved but related bug bgo#737356 that asks
for providing a different automatism.
https://bugzilla.gnome.org/show_bug.cgi?id=580018
Signed-off-by: Thomas Haller <thaller@redhat.com>
Next we want to sort the array, g_slist_sort() is not guaranteed to be
stable, while g_ptr_array_sort() is. Also, sorting a GSList has
worse performance.
Signed-off-by: Thomas Haller <thaller@redhat.com>
nm_device_get_best_auto_connection() was only used at one place.
It was a very simple function, just iterated over a list finding
the first can_auto_connect() connection. At the very least, the name
was misleading, because it did not return the 'best', but the 'first'
connection.
Get rid of the function altogether.
Signed-off-by: Thomas Haller <thaller@redhat.com>
The autoconnect priority has only any relevance, if the connection
is autoconnect too.
The priority defaults to zero, with higher numbers meaning preferred.
The valid range is limited to [-999,999].
Signed-off-by: Thomas Haller <thaller@redhat.com>
If the assertion in verifies_without_normalization() fails due to
@was_modified, the error message is not helpful.
Assert first against the content of the connection. This prints
most likely the settings that were actually modified.
Signed-off-by: Thomas Haller <thaller@redhat.com>
nm_client_new_async() got broken in the NMManager split. Fix it, and
use it from one of the tests in test-nm-client to make sure it's
getting tested in the future.
NMActiveConnection:connection was an object path rather than an
NMRemoteConnection because in the past the NMObject property system
wasn't capable of handling NMRemoteConnection-valued properties.
NMActiveConnection:master was an object path rather than an NMDevice
entirely by accident. Fix both.
NMActiveConnection:specific-object can't currently be converted to an
object, because we don't know ahead of time what object type it is,
and NMObject can't deal with that. Instead, we rename it to
:specific-object-path (and likewise for its get function), both to
emphasize that it doesn't behave like other properties, and to leave
the old name open for an actual object-valued property later on.
Add a single function to check if NM is running and set a GError if
not, then use it as appropriate.
Don't bother to check if NM is running in get_*() functions if
nm_running_changed_cb() would have reset the field anyway (and fix
that up to reset a few more fields).
Rearrange the NMClient function declarations and the functions
themselves, and group them into "general", "device", and "active
connection" sections.
No code changes, just moving things around.
Add utility function to kill non-child processes and fix the wrong
use of nm_utils_kill_child_process_sync() in nm-dhcp-client.c
https://bugzilla.gnome.org/show_bug.cgi?id=737731
Signed-off-by: Thomas Haller <thaller@redhat.com>
