#0 0x00007fffea7481e5 in _g_log_abort (breakpoint=1) at gmessages.c:554
#1 0x00007fffea74951d in g_logv (log_domain=0x7fffea78e00e "GLib", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fffffffcbb0)
at gmessages.c:1371
#2 0x00007fffea7496f3 in g_log
(log_domain=log_domain@entry=0x7fffea78e00e "GLib", log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, format=format@entry=0x7fffea798320 "%s: assertion '%s' failed")
at gmessages.c:1413
#3 0x00007fffea749f2d in g_return_if_fail_warning
(log_domain=log_domain@entry=0x7fffea78e00e "GLib", pretty_function=pretty_function@entry=0x7fffea799d40 <__func__.4759> "g_atomic_ref_count_dec", expression=expression@entry=0x7fffea799ca1 "g_atomic_int_get (arc) > 0") at gmessages.c:2762
#4 0x00007fffea754c12 in g_atomic_ref_count_dec (arc=arc@entry=0x5555558c5280) at grefcount.c:260
#5 0x00007fffea7302c6 in g_hash_table_unref (hash_table=0x5555558c5240) at ghash.c:1101
#6 0x00007fffea4b6dbc in clear_op_res (simple=0x55555587ed90 [GSimpleAsyncResult]) at gsimpleasyncresult.c:248
#7 0x00007fffea4b6dbc in g_simple_async_result_finalize (object=0x55555587ed90 [GSimpleAsyncResult]) at gsimpleasyncresult.c:268
#8 0x00007fffea67b949 in g_object_unref (_object=<optimized out>) at gobject.c:3346
#9 0x00007fffea67b949 in g_object_unref (_object=0x55555587ed90) at gobject.c:3238
#10 0x00007fffe95dea2d in checkpoint_rollback_cb (object=<optimized out>, result=<optimized out>, user_data=0x55555587ed90) at libnm/nm-manager.c:1584
#11 0x00007fffea4ca834 in g_task_return_now (task=0x5555558b5c80 [GTask]) at gtask.c:1148
#12 0x00007fffea4cb196 in g_task_return (task=0x5555558b5c80 [GTask], type=<optimized out>) at gtask.c:1206
#13 0x00007fffea5096bb in reply_cb (connection=<optimized out>, res=<optimized out>, user_data=0x5555558b5c80) at gdbusproxy.c:2596
#14 0x00007fffea4ca834 in g_task_return_now (task=0x5555558b5d50 [GTask]) at gtask.c:1148
#15 0x00007fffea4cb196 in g_task_return (task=0x5555558b5d50 [GTask], type=<optimized out>) at gtask.c:1206
#16 0x00007fffea4fdd4a in g_dbus_connection_call_done (source=<optimized out>, result=0x5555558b5e20, user_data=0x5555558b5d50) at gdbusconnection.c:5715
#17 0x00007fffea4ca834 in g_task_return_now (task=0x5555558b5e20 [GTask]) at gtask.c:1148
#18 0x00007fffea4ca86d in complete_in_idle_cb (task=task@entry=0x5555558b5e20) at gtask.c:1162
#19 0x00007fffea73e97b in g_idle_dispatch (source=0x7fffdc04eb90, callback=0x7fffea4ca860 <complete_in_idle_cb>, user_data=0x5555558b5e20) at gmain.c:5620
#20 0x00007fffea74206d in g_main_dispatch (context=0x5555557c8410) at gmain.c:3182
#21 0x00007fffea74206d in g_main_context_dispatch (context=context@entry=0x5555557c8410) at gmain.c:3847
#22 0x00007fffea742438 in g_main_context_iterate (context=0x5555557c8410, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3920
#23 0x00007fffea742762 in g_main_loop_run (loop=0x55555584ed00) at gmain.c:4116
Fixes: c3efedf54b
(cherry picked from commit 25a3825b51)
input and output must be freed only when not NULL.
Also, ovsdb_disconnect() should do nothing if there is no client.
Fixes: 830a5a14cb
(cherry picked from commit 29984c07cd)
Since commit 9ecdba316 ('platform: create netlink messages directly
without libnl-route-3') we're unconditionally setting IFA_ADDRESS to
the peer address, even if there's no peer and it's all zeroes.
The kernel actually stopped caring somewhere around commit caeaba790
('ipv6: add support of peer address') in v3.10, but Ubuntu Touch likes
to run Android's v3.4 on some poorly supported hardware.
Fixes: 9ecdba316chttps://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/77
(cherry picked from commit ef6d461b7f)
When the parent device has a device default route (i.e. without
gateway) and we establish a VPN on top of it, 'ip route get' for the
VPN gateway returns a device route, which is the same result we get
for an unreachable VPN gateway. However it is necessary to add the
route to the gateway or otherwise it will possibly become unreachable
once the VPN gets activated.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/93
(cherry picked from commit 797eab2f6b)
When the supplicant does not support PMF we wrongly set
'ieee80211w=0', but since the option is not recognized the connection
fails. Don't set it when unsupported.
Fixes: a9ab50efb1
(cherry picked from commit 58c4cd9cc9)
If the child is respawning too fast, consider the plugin failed so
that upstream servers are written to resolv.conf until the plugin gets
restarted after the delay.
(cherry picked from commit e45636659b)
When the dnsmasq process dies, two events are generated:
(1) a NM_DNS_PLUGIN_FAILED signal in nm-dns-dnsmasq.c:name_owner_changed()
(2) a NM_DNS_PLUGIN_CHILD_QUIT signal in nm-dns-plugin.c:from watch_cb()
Event (1) is handled by updating resolv.conf with upstream servers,
(2) by restarting the child process.
The order in which the two signals are received is not deterministic,
so when (1) comes after (2) the manager leaves upstream servers in
resolv.conf even if a dnsmasq instance is running.
When dnsmasq disappears from D-Bus and we know that the process is not
running, we should not emit a FAILED signal because the disappearing
is caused by the process termination, and that event is already
handled by the manager.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/105
(cherry picked from commit f2a2012733)
nmcli connection modify t ipv4.dns-options ndots:2
nmcli connection modify t +ipv4.dns-options ndots:4
should set dns-options to 'ndots:4', so we must remove other
occurences of the same option before adding it, otherwise the setting
refuses to set the same option again.
(cherry picked from commit b11a20ded0)
Appending to the ipvx.dns-options property:
nmcli connection modify con +ipv4.dns-options rotate
currently is buggy because it resets the list to contain only
'rotate'. The setter function should not clear the list.
https://bugzilla.redhat.com/show_bug.cgi?id=1665649
(cherry picked from commit bcb91f4f65)
wpa_supplicant is going to change the global default for PMF from 0
(disabled) to 1 (optional) [1], so NM code needs to be adjusted to
work with all wpa_supplicant versions. Furthermore, it is better to
set optional PMF using the 'Pmf' property instead of the 'ieee80211w'
configuration option because the former better handles missing support
in driver [2].
Note that each interface in wpa_supplicant has its own copy of global
configuration and so 'global' options must still be set on each
interface. So, let's set Pmf=1 when each interface gets created and
override it with ieee80211w={0,2} if needed during association.
[1] http://lists.infradead.org/pipermail/hostap/2018-November/039009.html
[2] http://lists.infradead.org/pipermail/hostap/2019-January/039215.htmlhttps://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/104
(cherry picked from commit a9ab50efb1)
When STP is disabled, the bridge parameters 'priority', 'forward-delay',
'hello-time' and 'max-age' are irrelevant.
We already skip them when loading a connection profile from a ifcfg file.
Do the same when generating a connection from a configured device, in
order to possibly assume the connection.
(cherry picked from commit abc40618f1)
...also when the connection is created at NetworkManager
startup to map an already configured bridge.
Ensure the device has configuration values that fall inside
NetworkManager boundaries, otherwise map the value with a default.
(cherry picked from commit 30d9744534)
We have bridge min/max/default values in core-internal. Do the same
for bridge port ones.
We will soon use those values to enforce limits when assuming a
bridge port configuration.
(cherry picked from commit 0f6fe2a38a)
In NetworkManager we have a default port path-cost equal to 100.
In the linux kernel the default port cost depends upon the interface
speed: 2 for 10Gb, 4 for 1Gb, 19 for 100Mb and 100 for 10Mb (or when the
interface speed is not available, like current virtio_net driver).
Allow NetworkManager to assume bridge port connections also when the
path-cost differs: this will allow us to assume bridge ports created
outside NetworkManager (e.g. in initrd) that will likely have a different
"cost" value.
(cherry picked from commit cad905fce2)
There are various functions to set the DUID of a DHCPv6 client.
However, none of them allows to set arbitrary data. The closest is
sd_dhcp6_client_set_duid(), which would still do validation of the
DUID's content via dhcp_validate_duid_len().
Relax the validation and only log a debug message if the DUID
does not validate.
Note that dhcp_validate_duid_len() already is not very strict. For example
with DUID_TYPE_LLT it only ensures that the length is suitable to contain
hwtype and time. It does not further check that the length of hwaddr is non-zero
or suitable for hwtype. Also, non-well-known DUID types are accepted for
extensibility. Why reject certain DUIDs but allowing clearly wrong formats
otherwise?
The validation and failure should happen earlier, when accepting the
unsuitable DUID. At that point, there is more context of what is wrong,
and a better failure reason (or warning) can be reported to the user. Rejecting
the DUID when setting up the DHCPv6 client seems not optimal, in particular
because the DHCPv6 client does not care about actual content of the
DUID and treats it as opaque blob.
Also, NetworkManager (which uses this code) allows to configure the entire
binary DUID in binary. It intentionally does not validate the binary
content any further. Hence, it needs to be able to set _invalid_ DUIDs,
provided that some basic constraints are satisfied (like the maximum length).
sd_dhcp6_client_set_duid() has two callers: both set the DUID obtained
from link_get_duid(), which comes from configuration.
`man networkd.conf` says: "The configured DHCP DUID should conform to
the specification in RFC 3315, RFC 6355.". It does not not state that
it MUST conform.
Note that dhcp_validate_duid_len() has another caller: DHCPv4's
dhcp_client_set_iaid_duid_internal(). In this case, continue with
strict validation, as the callers are more controlled. Also, there is
already sd_dhcp_client_set_client_id() which can be used to bypass
this check and set arbitrary client identifiers.
ab4a88bc29
(cherry picked from commit d65ee3bb18)
sd_dhcp_client_set_client_id() is the only API for setting a raw client-id.
All other setters are more restricted and only allow to set a type 255 DUID.
Also, dhcp4_set_client_identifier() is the only caller, which already
does:
r = sd_dhcp_client_set_client_id(link->dhcp_client,
ARPHRD_ETHER,
(const uint8_t *) &link->mac,
sizeof(link->mac));
and hence ensures that the data length is indeed ETH_ALEN.
Drop additional input validation from sd_dhcp_client_set_client_id(). The client-id
is an opaque blob, and if a caller wishes to set type 1 (ethernet) or type 32
(infiniband) with unexpected address length, it should be allowed. The actual
client-id is not relevant to the DHCP client, and it's the responsibility of the
caller to generate a suitable client-id.
For example, in NetworkManager you can configure all the bytes of the
client-id, including such _invalid_ settings. I think it makes sense,
to allow the user to fully configure the identifier. Even if such configuration
would be rejected, it would be the responsibility of the higher layers (including
a sensible error message to the user) and not fail later during
sd_dhcp_client_set_client_id().
Still log a debug message if the length is unexpected.
bfda0d0f09
(cherry picked from commit 0d5fec5741)
Infiniband addresses are 20 bytes (INFINIBAND_ALEN), but only the last
8 bytes are suitable for putting into the client-id.
This bug had no effect for networkd, because sd_dhcp_client_set_client_id()
has only one caller which always uses ARPHRD_ETHER type.
I was unable to find good references for why this is correct ([1]). Fedora/RHEL
has patches for ISC dhclient that also only use the last 8 bytes ([2], [3]).
RFC 4390 (Dynamic Host Configuration Protocol (DHCP) over InfiniBand) [4] does
not discuss the content of the client-id either.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1658057#c29
[2] https://bugzilla.redhat.com/show_bug.cgi?id=660681
[3] 3ccf3c8d81/f/dhcp-lpf-ib.patch
[4] https://tools.ietf.org/html/rfc4390b9d8071458
(cherry picked from commit 24a62f90c7)
When the link is up and goes down link_changed_cb() schedules
device_link_changed() to be run later. If the function is dispatched
when the link is already up again, it does not detect that the link
was down.
Fix this by storing in the device state that we saw the link down so
that device_link_changed() can properly restore the IP configuration.
https://bugzilla.redhat.com/show_bug.cgi?id=1636715https://github.com/NetworkManager/NetworkManager/pull/264
(cherry picked from commit 7bd193ef30)
The reasons to block autoconnection at settings level are not the same
as the ones to block autoconnection at device level.
E.g. if the SIM-PIN is wrong, you may want to block autoconnection
both at settings level (as the PIN configured in settings is wrong)
and at device level (so that no other setting is tried automatically).
For some other reasons, you may want to block autoconnection only at
setting level (e.g. wrong APN).
And for some other reasons you may want to block autoconnection at
device level only (e.g. SIM missing), so that the autoconnection
blocking is removed when the device goes away. This is especially
important with SIM hotplug events processed by ModemManager, as a
device without SIM will be removed from MM when a new SIM is
inserted, so that a completely new object is exposed in MM with the
newly detected SIM.
https://github.com/NetworkManager/NetworkManager/pull/259
(cherry picked from commit 90e9695af5)
When updating a connection passing agent-owned secret, they are lost
from @reread_connection after the settings-plugin persists the
connection. Therefore we need to cache and reapply them separately to
the connection so that they can be saved to secret agents later.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/82
(cherry picked from commit a3383726dc)
src/devices/nm-device.c: In function '_set_state_full':
src/devices/nm-device.c:14766:19: error: assignment from incompatible pointer type [-Werror]
if ( (s_sriov = nm_device_get_applied_setting (self, NM_TYPE_SETTING_SRIOV))
^
Fixes: 6ae1f64351
