test-dispatcher-envp.c: In function 'test_generic':
test-dispatcher-envp.c:507:3: error: format not a string literal and no format arguments [-Werror=format-security]
Don't disconnect the device when the DHCP renewal fails and there are
already configured static IP addresses on the device. Instead, keep
the device up and try DHCP again after some time.
https://bugzilla.redhat.com/show_bug.cgi?id=1168388
check_if_startup_complete() could be invoked from nm_settings_start() before
devices had chance to be added, which results in premature "startup complete"
and NM would quit when configure-and-quit=yes is set up.
Postpone actual check_if_startup_complete() resolution until we add all devices
and they are processed.
(gdb) bt
#0 0x00005555556401f3 in check_if_startup_complete (self=0x5555559f91d0)
at nm-manager.c:719
#1 0x00007ffff4d69de8 in g_closure_invoke () at /lib64/libgobject-2.0.so.0
#2 0x00007ffff4d7b70d in signal_emit_unlocked_R ()
at /lib64/libgobject-2.0.so.0
#3 0x00007ffff4d83471 in g_signal_emit_valist () at /lib64/libgobject-2.0.so.0
#4 0x00007ffff4d8372f in g_signal_emit () at /lib64/libgobject-2.0.so.0
#5 0x00007ffff4d6e4b5 in g_object_dispatch_properties_changed ()
at /lib64/libgobject-2.0.so.0
#6 0x00007ffff4d709d9 in g_object_notify () at /lib64/libgobject-2.0.so.0
#7 0x00005555556e232c in check_startup_complete (self=self@entry=0x555555a0e130) at settings/nm-settings.c:204
#8 0x00005555556e5203 in nm_settings_start (self=0x555555a0e130, error=error@entry=0x7fffffffe658) at settings/nm-settings.c:2122
#9 0x0000555555646d06 in nm_manager_start (self=0x5555559f91d0, error=0x7fffffffe658) at nm-manager.c:4153
#10 0x00005555555add43 in main (argc=1, argv=0x7fffffffe7c8) at main.c:428
(gdb)
Fixes:Beaker:NetworkManager_Test37_run_once_new_connection
https://bugzilla.redhat.com/show_bug.cgi?id=1256772
Add support for IFLA_LINK_NETNSID to properly handle linked parent
interfaces that reside in another netns.
This requires support of the IFLA_LINK_NETNSID from both the kernel
and libnl3.
https://bugzilla.gnome.org/show_bug.cgi?id=753726
The parent of a link (IFLA_LINK) can be in another network namespace and
thus invisible to NM.
This requires the netlink attribute IFLA_LINK_NETNSID which is supported
by recent versions of kernel and libnl.
In this case, set the parent field to NM_PLATFORM_LINK_OTHER_NETNS
and properly handle this special case.
The signal "notify:g-name-owner" is only emitted for well-known
names, but not for unique connection names (":1.x") such as the secret
agent's connection. Also, it will not be emited for private connections.
That meant that when the client disconnected without explicitly
unregistering, the NMSecretAgent was not cleaned up and leaked
indefinitely.
As only one instance of secret agent with a certain 'identifier/uid'
pair can register, this bug also prevented the client from registering
until restart of NetworkManager.
Fixes: df6706813a
This code was unused, because we never enqueued any hashes
to the @asked list. Note that hashing also might give wrong
hash collisions, so this was buggy anyway.
Also, note that impl_agent_manager_register_with_capabilities()
already ensures that duplicate agents are not registered
in the first place (find_agent_by_identifier_and_uid()).
Refactor the handling of the asynchronous requests so that now
NMSecretAgent has the following properties:
- The callback will *always* be invoked exactly once (sans crashes).
Even if you cancel the call or if you dispose NMSecretAgent with
pending calls. That allows the caller to rely on being called back
and possibly cleanup the user-data.
- Callbacks are always invoked asynchronously with respect to their
start-call.
- You can cancel all 3 types of operations, not only the 'GetSecrets'
call. Note that this will still not cancel the calls 'DeleteSecrets'
and 'SaveSecrets' on a D-Bus level.
When cancelling, the callback will be invoked synchronously with
respect to the cancel call, with an GError indicating the cancellation
(G_IO_ERROR_CANCELLED).
- During dispose, the callback is also invoked synchronously, with
some other error reason.
This also fixes a crash where handling of the asynchronous data was
messed up and the priv->requests hash would end up to containing dangling
pointers.
https://bugzilla.redhat.com/show_bug.cgi?id=1253407
The @dbus_owner field was only cleaned up when the
proxy disconnected and leaked otherwise.
Also, don't clear @dbus_owner together with the proxy.
Otherwise, get_description() might yield different results
after the proxy got cleared. That can lead to problems because
NMAgentManager tracks the secrets agents by their "dbus-owner" --
IOW, NMAgentManager uses the "dbus-owner" as identifer for the
secret agent. Thus it must not change.
Fixes: 2a2fd1216b
Allow scripts to be marked as "no-wait", so that the dispatcher will
schedule them immediately and in parallel with other no-wait scripts.
This is particularly useful for pre-up scripts to avoid excessive
delays when activating multiple interfaces in parallel.
https://bugzilla.gnome.org/show_bug.cgi?id=746703
Refactor logging so that all logging lines for a request/script
have the same prefix, indicating the event to which they belong.
Previously, we only scheduled one script at a time so it was always
clear for which request a script belongs. Now we schedule scripts
in parallel, so we must know the event (request) for which we log
a message.
Previously, dispatcher would start all "no-wait" script right away,
but it would also start the first "wait" script while the "no-wait"
script are still running (unless, there are other "wait" scripts that
delay the execution).
Now, do not start processing the "wait" scripts, as long as there are
any "no-wait" scripts from the same request running.
When a script is a symbolic link to the 'no-wait.d' subdirectory, the
dispatcher now schedules it immediately and in parallel with other
no-wait scripts.
https://bugzilla.gnome.org/show_bug.cgi?id=746703
Backport to 1.0.6 the following symbols:
- nm_setting_wired_get_wake_on_lan
- nm_setting_wired_get_wake_on_lan_password
- nm_setting_wired_wake_on_lan_get_type
added to 1.0.6 with commit d449d82304
API should be added with "Since:" of the next release on the same branch.
That means, new API on 1.1 branch (development), should be "Since: 1.2"
and new API on 1.0 branch (stable) will be "Since: 1.0.x". Similarly, new
API on master is NM_AVAILABLE_IN_1_2 and will be added with the linker
version libnl_1_2 -- never the versions of minor releases.
It is also strongly advised that for the 1.0 branch, we only add API
that was previously formerly added on master. IOW, that we only do true
backports of API that already exists on master.
API that gets backported, must also be added to master via NM_BACKPORT_SYMBOL().
That gives ABI compatibility and an application that was build against 1.0.x
will work with 1.y.z version (y > 0) without need for recompiling -- provided
that 1.y.z also contains that API.
There is one important caveat: if a major branch (e.g. current master) has a
linker section of backported APIs (e.g. libnm_1_0_6), we must do the minor release
(1.0.6) before the next major release (1.2). The reason is that after the major
release, the linker section (libnm_1_0_6) must not be extended and thus
the minor release (1.0.6) must be already released at that point.
In general, users should avoid using backported API because it limits
the ability to upgrade to arbitrary later versions. But together with the
previous point (that we only backport API to minor releases), a user that
uses backported API can be sure that a 1.y.z version is ABI compatible with
1.0.x, if the 1.y.z release date was after the release date of 1.0.x.
This reverts commit 02a136682c.
Without marking the enumeration as flags, the types will be "enumeration"
instead of "bitfield". And python raises ValueError exception.
Example:
from gi.repository import NMClient, NetworkManager
client = NMClient.Client.new()
for dev in client.get_devices():
if dev.get_device_type() == NetworkManager.DeviceType.WIFI:
for ap in dev.get_access_points():
ap.get_rsn_flags()
raises "ValueError: invalid enum value: 648"
https://bugzilla.redhat.com/show_bug.cgi?id=1255436
