This now gives every logging line of a NMVpnConnection
a fully descriptive prefix.
Especially for non-debug logging, this looks a bit verbose
and repetitive, so we could suppress the prefix in that case.
I still add it because I think the verbose information does help
during debugging.
connection_added() can be called before init_get_settings_cb(), and we can't
complete the connection until it is visible, else it would be uninitialized.
Test case:
* have 'em1' interface
$ nmcli con add type ethernet con-name myeth ifname em1 autoconnect no
(process:9039): libnm-CRITICAL **: nm_connection_get_id: assertion 's_con != NULL' failed
Connection '(null)' ((null)) successfully added.
$ nmcli con add type ethernet con-name myeth ifname em1X autoconnect no
Connection 'myeth' (71159504-c2af-4773-8ca9-a3626aa0da33) successfully added.
https://bugzilla.gnome.org/show_bug.cgi?id=754767https://bugzilla.gnome.org/show_bug.cgi?id=754794
[lkundrak@v3.sk: This is not quite the correct fix, we shouldn't emit
NMObject:connection-added for an unfinished object. Nevertheless, let's go with
it until we have a better one. Will revert this afterwards. See linked bugs.]
Refactor agent-manager to always invoke the complete function for
nm_agent_manager_get_secrets().
In general, the complete function is always invoked asnychronously
when starting the operation. On the other hand, when cancelling the
operation or disposing the manager with pending operations, we now
(always) synchronously invoke the callback.
This makes it simpler for the user to reliably cancel the request
and perform potential cleanup.
This behavior bubbles up through NMSettingsConnection and NMActRequest,
and other callers that make directly or indicrectly make use of
nm_agent_manager_get_secrets().
Instead of having the call_id of type guint32, make it an (opaque)
pointer type.
This has the advantage of strong typing and avoids the possiblity
of reusing an invalid integer (or overflow of the call-id counter).
OTOH, it has the disadvantage, that after a call_id is disposed,
it might be reused for future invocations (because malloc might
reuse the memory).
In fact, it is always an error to use a call_id that is already
completed. This commit also adds assertions to the cancel() calls
that the provided call_id is a pending call. Hence, such a bug
will be uncovered by assertions (that only might not tigger in
certain unlikely cases where a call-id got reused).
Note that for NMAgentManager, save_secrets() and delete_secrets()
both returned a call_id. But they didn't also provide a callback when
the operation completes. So the user trying to cancel such a call,
cannot know whether the operation is still in process and he cannot
avoid triggering an assertion.
Fix that by not returning a call-id for these operations. No caller
cared about it anyway.
For NMSettingsConnection, also track the internally scheduled requests
for so that we can cancel them on dispose.
- move nm_auth_chain_check_done() and nm_auth_chain_remove_call()
into the only caller auth_call_complete().
- take a ref of the "context" argument.
- in nm_auth_chain_add_call(), assert that we didn't yet invoke the
done-callback. The auth-chain should not be reusued.
- use slice allocator for ChainData, AuthCall and NMAuthChain
This way, the function matches the other names like nm_device_set_unmanaged().
Arguably, the name currently makes some sense. But future commits will make
nm_device_get_unmanaged() more to be a counterpart of nm_device_set_unmanaged().
Subscribe to the UPDATED_BY_USER signal (instead of UPDATED) to listen
for changes to the firewall zone and metered properties of a
connection since these modifications are supposed to come from user
intervention.
If the metered property of a connection is changed, an activated
device associated to the connection must be updated immediately with
the new metered value.
https://bugzilla.gnome.org/show_bug.cgi?id=754409
When we receive an update for a link, cancel a scheduled
REFRESH_LINK delayed-action for that ifindex. At the point when we
scheduled refrehing the link, we only cared about receiving a
notification that was newer then the current state.
We scheduled requesting this new notification to resync the cache.
It is not necessary to actually request a new update, any update we
receive *after* requesting a new update will suffice.
This potentially saves extra round-trips re-requesting the link.
When moving a link to another netns, it gets removed from
NMPlatform's view.
Currently kernel does not sent a notification to inform about
that change (see related bug rh#1262908).
Ensure that we reload all linked interfaces which now might
have an invisible parent.
Defect type: CHECKED_RETURN
3. NetworkManager-1.0.6/src/platform/nm-linux-platform.c:1145: check_return: Calling "clock_gettime" without checking return value (as is done elsewhere 6 out of 7 times).
The GATEWAY from /etc/sysconfig/network file is used as a default value when
no GATEWAY is in ifcfg file. However, we have to ignore that GATEWAY for
connections without static addresses. Otherwise such connections would be
invalid and would disappear after restart/reaload.
Some notes:
Putting GATEWAY into /etc/sysconfig/network is not recommended, because it
inherently belongs to the ifcfg file as it is a per-interface property.
The recommended practice is to specify GATEWAY in individual ifcfg files and
define DEFROUTE=no if the interface should not get the default route.
But we continue to read GATEWAY from /etc/sysconfig/network for compatibility
reasons.
See also
https://bugzilla.redhat.com/show_bug.cgi?id=896198#c25https://bugzilla.redhat.com/show_bug.cgi?id=896198#c27
Fixes: f17699f4e3https://bugzilla.redhat.com/show_bug.cgi?id=1262972
Upstream systemd made a previously "public" API internal. In commit
e82f430eae I fixed that up by reverting
the upstream patch. Revise that, and instead adjust our usage of the
API to use the internal API.
After all, we anyway make use of systemd API that is not (currently)
intended to become part of the public API. Before the systemd library
happens, we must revisit this.
This reverts commit e82f430eae.
Optimally, we only make use of systemd API that is intended to be public
and that will be later part of the system-library. That is currently
not yet possible and we need "-Isrc/systemd/src/basic" to build
"nm-dhcp-systemd.h". Still, split the include paths to build systemd
code itself, contrary to the user of the API.
