sysfs is deprecated and kernel will not add new bridge port options to
sysfs. Netlink is a stable API and therefore is the right method to
communicate with kernel in order to set the link options.
The commit causes the following assertion failure:
0 0x00007f4187e22884 in __pthread_kill_implementation () from target:/lib64/libc.so.6
1 0x00007f4187dd1afe in raise () from target:/lib64/libc.so.6
2 0x00007f4187dba87f in abort () from target:/lib64/libc.so.6
3 0x00007f4188386f4e in g_assertion_message (domain=domain@entry=0x6fc1bc "nm", file=file@entry=0x722e94 "../src/core/nm-l3cfg.c", line=line@entry=2134,
func=func@entry=0x727730 <__func__.49> "_l3_acd_data_add_all", message=message@entry=0x23b3bb0 "assertion failed: (acd_data->info.track_infos[i]._priv.acd_dirty_track)")
at ../glib/gtestutils.c:3450
4 0x00007f41883f1597 in g_assertion_message_expr (domain=domain@entry=0x6fc1bc "nm", file=file@entry=0x722e94 "../src/core/nm-l3cfg.c", line=line@entry=2134,
func=func@entry=0x727730 <__func__.49> "_l3_acd_data_add_all", expr=expr@entry=0x726450 "acd_data->info.track_infos[i]._priv.acd_dirty_track") at ../glib/gtestutils.c:3476
5 0x0000000000587209 in _l3_acd_data_add_all (self=self@entry=0x23a7020, infos=infos@entry=0x0, infos_len=infos_len@entry=0, reapply=reapply@entry=1)
at ../src/core/nm-l3cfg.c:2134
6 0x0000000000587702 in _l3cfg_update_combined_config (self=self@entry=0x23a7020, to_commit=to_commit@entry=1, reapply=reapply@entry=1, out_old=out_old@entry=0x7ffd09ea4ca8,
out_changed_combined_l3cd=out_changed_combined_l3cd@entry=0x7ffd09ea4c7c) at ../src/core/nm-l3cfg.c:3858
7 0x000000000058a202 in _l3_commit (self=0x23a7020, commit_type=commit_type@entry=NM_L3_CFG_COMMIT_TYPE_REAPPLY, is_idle=is_idle@entry=0) at ../src/core/nm-l3cfg.c:5046
8 0x000000000058a49f in nm_l3cfg_commit (self=<optimized out>, commit_type=commit_type@entry=NM_L3_CFG_COMMIT_TYPE_REAPPLY) at ../src/core/nm-l3cfg.c:5115
9 0x00000000004856cd in nm_device_l3cfg_commit (self=self@entry=0x23ab870, commit_type=commit_type@entry=NM_L3_CFG_COMMIT_TYPE_REAPPLY, commit_sync=commit_sync@entry=1)
at ../src/core/devices/nm-device.c:4155
10 0x00000000004b1814 in nm_device_cleanup (self=self@entry=0x23ab870, reason=reason@entry=NM_DEVICE_STATE_REASON_NEW_ACTIVATION,
cleanup_type=cleanup_type@entry=CLEANUP_TYPE_DECONFIGURE) at ../src/core/devices/nm-device.c:15884
11 0x00000000004b26c9 in _set_state_full (self=self@entry=0x23ab870, state=state@entry=NM_DEVICE_STATE_DISCONNECTED, reason=NM_DEVICE_STATE_REASON_NEW_ACTIVATION,
quitting=quitting@entry=0) at ../src/core/devices/nm-device.c:16291
12 0x00000000004b2fe4 in nm_device_state_changed (self=self@entry=0x23ab870, state=state@entry=NM_DEVICE_STATE_DISCONNECTED, reason=<optimized out>)
at ../src/core/devices/nm-device.c:16505
13 0x00000000004b69de in queued_state_set (user_data=user_data@entry=0x23ab870) at ../src/core/devices/nm-device.c:16532
14 0x00007f41883bf4fd in g_idle_dispatch (source=0x23a88e0, callback=0x4b6956 <queued_state_set>, user_data=0x23ab870) at ../glib/gmain.c:6163
15 0x00007f41883c34fc in g_main_dispatch (context=0x22c4d10) at ../glib/gmain.c:3460
16 g_main_context_dispatch (context=0x22c4d10) at ../glib/gmain.c:4200
17 0x00007f41884216b8 in g_main_context_iterate.isra.0 (context=0x22c4d10, block=1, dispatch=1, self=<optimized out>) at ../glib/gmain.c:4276
18 0x00007f41883c2aff in g_main_loop_run (loop=0x22c3b50) at ../glib/gmain.c:4479
19 0x0000000000423a37 in main (argc=<optimized out>, argv=<optimized out>) at ../src/core/main.c:519
This reverts commit ed565f9146.
It seems more useful to have a best effort approach and configure
everything we can; in that way we achieve at least some connectivity,
and then sysadmin can check the logs in case something is
missing. Currently instead, the whole activation fails (so, no address
is configured) if just one of the addresses fails DAD.
Ideally, we should have a way to make this configurable; but for now,
implement the more useful behavior as default.
IPv4 and IPv6 DAD work slightly differently: for IPv4 the presence or
absence of carrier doesn't have any effect on the duration of the
probe; for IPv6, DAD never completes without carrier because kernel
never removes the tentative flag.
In both cases, we shouldn't ignore the DAD result because that would
mean that we complete the ipmanual method without addresses actually
configured.
We don't know the reason why the DHCP client is being stopped. It is
wrong to schedule a commit of type "update" because the device could
be now unmanaged. Schedule instead a commit of type "auto", which
automatically determines the type of commit based on registered
handles.
If a commit is invoked without any change to the l3cd or to the ACD
data, in _l3cfg_update_combined_config() we skip calling
_l3_acd_data_add_all(), which should clear the dirty flag from ACDs.
Therefore, in case of such no-op commits the ACDs still marked as
dirty - but valid - are removed via:
_l3_commit()
_l3_acd_data_process_changes()
_l3_acd_data_prune()
_l3_acd_data_prune_one()
Invoking a l3cfg commit without any actual changes is allowed, see the
explanation in commit e773559d9d ('device: schedule an idle commit
when setting device's sys-iface-state').
The bug is visible by running test 'bond_addreses_restart_persistence'
with IPv4 ACD/DAD is enabled by default: after restart IPv6 completes
immediately, the devices becomes ACTIVATED, the sys-iface-state
transitions from ASSUME to MANAGED, a commit is done, and it
incorrectly prunes the ACD data. The result is that the IPv4 address
is never added again.
Fix this by doing the pruning only when we update the dirty flags.
Interfaces with IFF_NOARP don't support Address Conflict Detection,
which is based on ARP. Trying to start ACD on them would result in
ENOBUFS always being returned by send(), and n-acd handles such error
by retrying indefinitely.
Fixes: 58287cbcc0 ('core: rework IP configuration in NetworkManager using layer 3 configuration')
On interfaces not supporting ACD (for example, layer3 interfaces), the
probe fails to be created with message:
l3cfg[...,ifindex=2]: acd[172.25.17.1, init]: probe-good (interface does not support acd, initial post-commit)
l3cfg[...,ifindex=2]: acd[172.25.17.1, ready]: set state to ready (probe is ready, waiting for address to be configured)
During the post-commit event, if the address is not yet configured, we
need to schedule a new commit to actually add it.
Fixes: 58287cbcc0 ('core: rework IP configuration in NetworkManager using layer 3 configuration')
Currently, all the probes of an acd instance share the same seed
state. This means that the state is updated by all the probes, and as
a consequence they get different jitters for the wait timeouts;
therefore the order in which addresses become available (and are
configured on the interface) is not deterministic.
Keep a separate seed state for each probe, initialized from the acd
seed. This ensures that all the probes use the same timeouts when
sending probe requests, and that in case of no collision, addresses
are available in the order of probe start.
n-acd pull request: https://github.com/nettools/n-acd/pull/10
Currently, IPv4 shared mode fails to start when DAD is enabled because
dnsmasq tries to bind to an address that is not yet configured on the
interface. Delay the start of dnsmasq until the shared4 l3cd is ready.
Fixes: 58287cbcc0 ('core: rework IP configuration in NetworkManager using layer 3 configuration')
Adds a new WiFi 6GHz capability flag, NM_WIFI_DEVICE_CAP_FREQ_6GHZ,
along side the existing NM_WIFI_DEVICE_CAP_FREQ_2GHZ &
NM_WIFI_DEVICE_CAP_FREQ_5GHZ flags.
Gnome settings utilizes the 2 existing flags to present supported
bands in gnome-settings. I will be using this additional flag in
modifications there.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1739
This commit removes the upper bound check for the PID, letting NetworkManager recognize a PID from the pidfile higher than 2^16.
The PID limit is often set higher than 2^16 (65536) on 64-bit systems, resulting in the pidfile being ignored and subsequently deleted if the currently running instance of NetworkManager has a pid higher than 2^16.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1727
The condition in `_get_maybe_ipv6_disabled()` is improperly set which
returns the wrong value on if an device is disabled or not when
generating the assume connection. And when
`/proc/sys/net/ipv6/conf/$DEV/disable_ipv6` is not existed (not
disabling ipv6 through sysctl setting), IPv6 is disabled by default.
Fixes: be655e6ed1 ('core: read "disable_ipv6" sysctl before nm_ip6_config_create_setting()')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1743
The bottom border of the generated QR code had a different thickness
compared to other borders.
Improve it by using Upper Half Block so that all borders have similar
thickness.
Instruct the `NMDnsManager` to emit `CONFIG_CHANGED` signal even
`dns=none` or failed to modify `/etc/resolv.conf`.
The `NMPolicy` will only update hostname when DNS is managed.
Signed-off-by: Gris Ge <fge@redhat.com>
Remove all the code that was added for the CSME coexistence.
The Intel WiFi team can't commit on when, if at all, this feature will
be completely integrated and tested in the NetworkManager.
The preferred solution for now is the solution that involves the kernel
only.
Remove the code that was merged so far.
An empty value NO_COLOR= should not be treated to disable colors.
This is also what [1] says (changed a while ago [2]).
[1] https://no-color.org/
[2] 99f90e27d0
On very particular timing, if a connection is currently activating
on a modem device and user remove the remote settings associated
an device state change:
prepare -> deactivating (reason 'connection-removed', sys-iface-state: 'managed')
pops before entering into modem_prepare_result, resulting to a crash
on assertion.
We can simply check for the modem state to failed, set the success flag
to FALSE and continue.
Closes: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1354
Signed-off-by: Frederic Martinsons <frederic.martinsons@unabiz.com>
Addition of list and string is allowed but only from version 0.60 of
meson. We claim to support building with meson 0.47, and there are
distributions like Debian and CentOS Stream 8 that uses versions older
than 0.60. Fix it by converting the offending string to a single item
list.
On newer versions, we get this warning only:
Project targets '>= 0.47.2' but uses feature introduced in
'0.60.0': list.<plus>. The right hand operand was not a list.
Fixes: 984642e33f ('build: meson: fix some missing dependencies')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1737
The get_gtype field in property_typ_data is intended to specify an enum
type for properties that are really defined as (u)int in the NMSetting
class. Specifying get_gtype for properties that are already defined as
enum in the NMSetting class is rejected as a runtime error. However, the
error message doesn't explain the reason. Put a code comment explaining
the reason.
Explaining it in a comment is actually enough because:
- The error is a runtime assertion that indicates a programming error
- The assertion is checked any time that the property is read or
written, so it should always be detected at developing time when doing
changes to the property.
Anyway, the code that did this checks was very difficult to read, so
let's take the opportunity to refactor it, with no functional changes.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1728
Some targets related to documentation generation had missing
dependencies, like xsl templates or the python generator. If these files
are changed, their output changes too, but as they were not listed as
dependencies (custom_target's input), meson wasn't aware.
In Makefile.am they already were correctly listed as dependencies.
Gtkdoc comments are used, among other things, to generate the various
nm-setting-* manual pages. When a constant is referenced in a gtkdoc
comment (i.e. `%NM_IP_TUNNEL_MODE_IPIP`) it is expanded to show the C name
and the value (i.e. `NM_IP_TUNNEL_MODE_IPIP (1)`). To generate the
nm-setting-* manual pages, we don't use gtkdoc, but we process this data
with the custom script tools/generate-docs-nm-settings-docs-gir.py.
This script was expanding the constants in the same way than gtkdoc.
Showing the constants in that way in nm-setting-* manual pages makes
little sense, because users are not going to use the C identifiers.
Let's show them with a more appropriate format.
Additionally, the different nm-setting-* pages might require different
formats than the other. For example, for nm-setting-nmcli a format like
`"ipip" (1)` is prefered, but for nm-setting-dbus it's better
`1 (ipip)`. Let's generate different nm-settings-docs-gir-*.xml files for
nmcli, dbus, keyfile and ifcfg-rh, using the right format for each one.
