We call _platform_link_cb_idle() on idle, so we must take care of the lifetime
of NMManager.
We don't want to take a reference, so that the manager is not kept alive
by platform events.
Refactor the previous implementation with weak pointers to use a linked list
instead. Let's not have any pending idle actions after the manager instance
is destroyed. Instead, properly track and cancel the events.
We should reduce uses of singletons in general. Instead, the platform
instance should be passed around and kept for as long as it's needed.
Especially, as we subscribe platform_link_cb() signal. Currently, we
never unsubscribe it (wrongly). Subscribing signals is a strong
indication that the target object should keep the source object alive
until the signal is unsubscribed.
In case the connection is blocked because it failed, the availability
of a master is a good reason to unblock it so that it can be tried
again.
Fixes: a1ea422aad
Distinguish between connections blocked from autoconnecting by user
request and connections blocked because they failed (and would fail
again).
Later, the reason will be used to unblock failed connection when some
conditions change.
We already have various ways to mark a device as unmanaged.
1) via udev-rule ENV{NM_UNMANAGED}. This can be overwritten via D-Bus
at runtime.
2) via settings plugin. That is NM_CONTROLLED=no for ifcfg-rh and
keyfile.unmanaged-devices in NetworkManager.conf.
3) at runtime, via D-Bus. This is persisted in the run state file
and persists restarts (but not reboot).
This adds another way via NetworkManager.conf file. Note that the
existing keyfile.unmanaged-devices (above 2) is also a configuration
optin in NetworkManager.conf. However it has various downsides:
- it cannot be overwritten at runtime (see commit
c210134bd5).
- you can only explicitly mark a device as unmanaged. That means,
you cannot use it to manage a device which is unmanaged due to
a udev rule.
- the name "keyfile.*" sounds like it's only relevant for the keyfile settings
plugin. Nowadays the keyfile plugin is always loaded, so the option applies
to NetworkManager in general.
https://github.com/NetworkManager/NetworkManager/pull/29
We currently don't support marking a device a managed/unmanaged via
the [device] section. Eventually, I think we should, because the
existing "keyfile.unmanaged-devices" looks keyfile specific (which
it isn't). But more importantly, "keyfile.unmanaged-devices" sets the
unmanaged flag NM_UNMANAGED_USER_SETTINGS, which cannot be overruled
via D-Bus (see commit c210134bd5).
A device.managed flag would make sense for a more sensible way to
express configuration in NetworkManager.conf, which still can be
overwritten via D-Bus.
Anyway, it's not yet implemented. Fix the example.
nm_device_match_parent() is called to check whether a device is
compatible with a given parent (UUID or interface). Accept any UUID If
there is no connection active on the device.
Without this, when there is a VLAN/MACVLAN connection with a parent
UUID the manager would create the device in
system_create_virtual_device(), realize it and then at the next call
of system_create_virtual_device() it would notice that the connection
is not compatible with the device because of the parent UUID;
therefore the manager would try to create again the same device,
failing.
https://mail.gnome.org/archives/networkmanager-list/2017-September/msg00034.html
Expose previously internal function nm_ip_route_equal_full(). It's
just useful API.
However, add a @cmp_flags argument, so that in the future we could
extend it.
For kernel and NetworkManager's core, route identity is a complicated topic
(see NM_PLATFORM_IP_ROUTE_CMP_TYPE_ID). For example, a route
without explity table is treated identical to "table 254" or "table 0".
It would be complicated to have nm_setting_ip_config_add_route()
implement that logic, especially since libnm offers not public API
to expose kernel's logic.
However, previously nm_setting_ip_config_add_route() would only consider
dest/prefix,next_hop,metric when comparing for equality. Hence, with
nmcli connection modify "$CON" +ipv4.routes '192.168.5.0/24'
nmcli connection modify "$CON" +ipv4.routes '192.168.5.0/24 table=42'
the second route was not actually added, although it is a very different
route. Fix that, and consider attributes too. Note that this allows the user
to add two routes that look different to libnm, but are actually idential:
nmcli connection modify "$CON" +ipv4.routes '192.168.5.0/24'
nmcli connection modify "$CON" +ipv4.routes '192.168.5.0/24 table=254'
In the above example, the route instances look different, but
sementically they are both the same route in the main table (254).
This also allows the user to add routes that are semantically different, but
are treated as the same route by kernel:
nmcli connection modify "$CON" +ipv6.routes 'a🅱️c::/120'
nmcli connection modify "$CON" +ipv6.routes 'a🅱️c::/120 mtu=600'
I think libnm should allow to add routes as long as they look different
to libnm. Regardless how kernel and NetworkManager-core thinks about
route identity.
This changes API of nm_setting_ip_config_add_route(). However, I think
the previous behavior was just broken.
Same for nm_setting_ip_config_remove_route_by_value().
GArray's and GPtrArray's plen argument is unsigned. The index variable
to iterate the list, should not have a smaller range (or different data type).
Also, assert against negative idx argument.
Since commit d61eaf2545 ("service: don't
install dependency for "NetworkManager-wait-online.service" to
"network-online.target.wants") we no longer install NM-w-o.service
in "network-online.target.wants" directory.
Obviously, for previous RPM versions NM-w-o.service was always enabled.
For current versions, it depends now on the preset. Most importantly,
this allows the user to disable the service, without masking it.
Previously NM-w-o.service was always implicitly enabled.
But presets are not applied during package upgrade, so it means that
after upgrade the service will be disabled. Hack around that via an RPM
scriptlet.
https://bugzilla.redhat.com/show_bug.cgi?id=1455704
The return value of g_hash_table_add() was added in GLib 2.40, use the
wrapper to avoid compile error on older versions:
src/nm-policy.c: In function ‘auto_activate_device’:
src/nm-policy.c:1279:7: error: void value not ignored as it ought to be
Fixes: a1ea422aad
When a connection is autoactivated NMPolicy only detects a failure by
watching the device state, or when the activation fails immediately.
If the activation fails after the asynchronus authorization check
before the device enters the PREPARE state, no other connection is
tried.
Let NMPolicy watch the active-connection state to detect early
failures and disconnect the signal handler when we detect that the
device state is progressing.
https://bugzilla.redhat.com/show_bug.cgi?id=1310676
Add initial support for policy-routing/source-routing.
It does not support rules (yet), only configuring routes
in a different routing table then 254 (main). And this
currently only works for manually configured routes,
not routes from DHCP or the default-route.
https://bugzilla.redhat.com/show_bug.cgi?id=1436531
Whenever we call a platform operation that reads or writes the netlink
socket, there is the possibility that the cache gets updated, as we
receive netlink events.
It is thus racy, if nm_platform_ip_route_sync() *first* adds routes, and
then obtains a list of routes to delete. The correct approach is to
determine which routes to delete first (and keep it in a list
@routes_prune), and pass that list down to nm_platform_ip_route_sync().
Arguably, this doesn't yet solve every race. For example, NMDevice
calls update_ext_ip_config() during ip4_config_merge_and_apply().
That is good, as it resyncs with platform. However, before calling
nm_ip4_config_commit() it calls other platform operations, like
_commit_mtu(). So, the race is still there.
Since commit a21b8882cc ("device: update
external configuration before commit"), we correctly re-sync the
external IP configuration before a merge, in case we notice that
there were some changes in platform.
Go a step further, and do the full update_ext_ip_config(). We should
have one way how to capture the external config, including intersect
and subtract. Otherwise, we end up with an @ext_ip4_config, which is
different from how it looks usually.
Refactor the code. There should be no changes in behavior at all.
The point is, to be able to reuse update_ext_ip_config() in the
next commit.
And also, I think it's an antipattern to have mirroring functions like
ip4_xyz() and ip6_xyz(). Instead, there should be one function, with
extra addr_family argument. That way, it'much clearer where two
implementations differ and where they are identical.
Basically, it moves the differentiation per the address family down
the call stack, closer to the place where the behavior is actually
different.
nm_dedup_multi_obj_ref() is a trivial function, that only uses the field
which is already declared in the same header file. Move it to the header
so that it can be inlined (without LTO).
Kernel does not allow to add a route with table 0 (RT_TABLE_UNSPEC). It
effectively is an alias for the main table. We must consider that when
comparing routes sementically.
If the commit of static connection parameters fails before starting
RA, we should reset @con_ip6_config; otherwise any external update
arriving before the commit of RA parameters will remove from
@con_ip6_config all parameters not present externally, because in
update_ip6_config() we do:
/* This function was called upon external changes. Remove the configuration
* (addresses,routes) that is no longer present externally from the internal
* config. This way, we don't re-add addresses that were manually removed
* by the user. */
if (priv->con_ip6_config)
nm_ip6_config_intersect (priv->con_ip6_config, priv->ext_ip6_config);
Instead if @con_ip6_config is cleared it will be rebuilt from the
connection setting at the next commit.
Fixes-test: @ipv6_preserve_cached_routes
Use consistently $() instead of ${}.
Don't use the $(top_*) variables, because we don't do recursive make
and the toplevel directory is the same as the current directory.
For consistency, only use the non-toplevel versions of the variables.
No need for duplicate log lines
<debug> [1506146476.8462] platform: link: adding tap tap0 owner 107 group -1
<debug> [1506146476.8462] platform-linux: link: add tap tap0 owner 107 group -1
Merge them.
Also, for consistency change the logging output for adding generic
interfaces in nm_platform_link_add().
GNOME Settings 3.26 is crashing every time a VPN connection changed its
state. After some digging, a debug message was put on dispose, and this
issue was found:
libnm-Message: Object 0x55555633c070 disposed
libnm-Message: Object 0x55555633c730 disposed
libnm-Message: Object 0x55555633eae0 disposed
libnm-Message: Object 0x555556340a80 disposed
Thread 1 "gnome-control-c" received signal SIGSEGV, Segmentation fault.
g_type_check_instance_cast (type_instance=type_instance@entry=0x55555633c070, iface_type=93825006537856) at /.../glib/gobject/gtype.c:4057
4057 node = lookup_type_node_I (type_instance->g_class->g_type);
(gdb) bt
NetworkManager is calling callbacks on disposed objects, which leads to
crashes in clients (e.g. GNOME Settings).
Fix this issue by disconnecting signal handlers when the objects are
disposed.
Patch originally by Georges Basile Stavracas Neto <georges.stavracas@gmail.com>
https://bugzilla.gnome.org/show_bug.cgi?id=787893
When a device managed by NetworkManager is configured manually (adding
ip addresses), NetworkManager will track the device configuration with
an in-memory only config, marking the device as "external".
Devices marked external should be just tracked but left untouched.
This does not happens on current code base: if an ipv4 address is added,
NM generates the in-memory connection, marking the ipv6.method as "ignore".
While activating the connection, NM will process the IPv6 "ignore" method:
this implies leaving the IPv6LL address generation to the kernel. To
trigger this NM will disable/enable IPv6 on the interface.
This not only may change the device configuration but may cause also
a potential race with an external IPv6 assignment on the device.
NetworkManager should do nothing to IPv6 when method is "ignore" and
connection is marked as "external": this commit fixes this behavior.
Note that if/once an IPv6 address is externally added, IPv6 method in the
tracked connection is changed to "manual" and a link local address will be
generated if needed.
https://bugzilla.redhat.com/show_bug.cgi?id=1462260
