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 d449d823046ac02f19d086575a19be7f40278bd0
Backport to 1.0.6 the following symbols:
- nm_utils_enum_from_str
- nm_utils_enum_to_str
added to 1.0.6 with commit f4ce6760e0ebb66aee3df35e9618be656355f318
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
prop_filter() gets invoked on another thread and we don't take
a strong reference to the manager when subscribing the filter.
Fix the race, by passing on a weak reference.
