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.
In some cases, properties documentation might require to provide an
explanation of each of the possible values that the property accepts.
If the possible values are the variants of an enum, we can use the
introspection data to get all the possible values for that enum and
their descriptions. With that info, we can automatically generate the
documentation with an always up to date list of accepted values.
Add a new "expand enumvals" feature: it will convert a token with the
format `#EnumName:*` to a list of all the possible values. For the
docbook (description-docbook field in the XML), it is expanded to a
bulleted list of all the values and their respective documentations.
This feature is limited to the "property-infos" comments (those like
---nmcli---, ---dbus---, etc). This comments are used only to generate
the nm-settings-* manual pages. For the documentation under the doc/
folder this is not needed: it's not supported by gtkdoc and, anyway,
it's better to use just `#EnumName` that will generate an HTML link.
Additionally, expansion of `%ENUM_VALUE` is now supported in the
property-infos comments. Instead of expanding them in the same style
than gtkdoc "ENUM_VALUE (num)", it is expanded in a format more suitable
for the nm-setting-* manual pages:
- for nmcli: value_nick (num)
- others: num (value_nick)
Also, fix typo in meson build file propery -> property.
If there are properties that accept special values apart from the
normally accepted values, or any of those values has an special meaning,
it can be shown as "Special value", indicating the nicknames and numbers
that can be used to select it.
Show a new field called "Valid values" in those properties that only
accept a limited set of values, like enums, ints with a valid range of
values, etc.
As there is some complex logic behind getting this information, this
logic has been put in nm-meta-setting-desc and nm-enum-utils so they can
be re-used, avoiding duplicity and errors. Some refactor has been done
in nm-meta-setting-desc in this direction, too.
Instead of deducing the type from the GLib's types, use the properties'
metadata available in nm-meta-setting-desc.c which is the most accurate
representation of what the expected input from the user is.
Message of the day was shown twice because the same bashrc.my file than
for containers was used. That file contained some code to show motd in
the container, where it is not shown by default. But in the VM, the motd
is shown by default, so it was shown twice.
Move the code to show motd to a file used only by nm-in-container and
not by nm-in-vm.
Also, modify the explanation about using prepare-for-system.sh because
it's only valid for Fedora but nm-in-vm can be used with other SOs too.
The $VM name is used also as hostname in the guest so ssh connection can
be made to root@$VM. However, valid hostnames can only contain letters,
numbers and '-'. If other characters are used, they are removed from the
hostname so you cannot connect to root@$VM. Fix it by not allowing
invalid hostnames in $VM at VM creation.
Also, fix some incorrect bash regexes.
Install missing repositories required to install all the packages.
Unluckily, it doesn't support 9P filesystem shares, and virtiofs is not
supported for non-root hosts. Emit a warning about that.
Images of qcow2 format dynamically grow up to the maximum size that they
have been configured at creation time. Because of this, higher size can
be selected without wasting unnecesary space in the host. Rise image
size to 20G.
Also, allow to set an empty value to IMAGE_SIZE, and don't resize in
that case. This is useful because virt-resize fails with some guest
partition layouts (like with ubuntu-20.04).
Using more than one VM can be a quite common use case. Insteado of
having to do VM=vm_name ./nm-in-vm, allow the more common way of passing
options ./nm-in-vm --vm vm_name.
Also, in build command, accept one positional argument to set OS_VERSION.
The connectivity with the host depends on getting a DHCP lease from the
host. With the latest commit's customizations, the virtual NIC is not
managed by NM so it is not configured.
Keep it unmanaged so debuging NetworkManager doesn't affect to this
virtual NIC. Use dhclient to get a DHCP lease from the host. Assign a
fixed interface name (host_net) to match it from NM and dhclient config
files.
The script was generating the data-* files that later copies to the
container.
In order to the files being reusable for nm-in-vm, put them as separate
files inside the data directory.
However, some of the files need the full path to NetworkManager project,
which varies for each user. Instead, make a sed replacement on them and
generate the actual files that will be copied. Replacement:
{{BASEDIR_NM}} -> $BASEDIR_NM
Also, rename the files to more descriptive names, using some prefixes
that give a hint of where those files will be put, and the .in extension
to indicate that they will be processed.
nm-in-vm can use the same generated files than nm-in-container, so let's
move them to a place common for both: tools/nm-guest-data.
With this change, it is not worth it to have the nm-in-container
directory, so move the script to tools and delete the subdirectory.
Script to download, configure and install a virtual machine to build and
test NetworkManager. This is useful because there are some things that
doesn't work properly on containers so a VM is needed to test.
It works almost the same way than nm-in-container.
Configurations specific to NetworkManager such as installing the required
packages are not implemented yet.
Separate the explanation of the format in various paragraphs so it is
better structured and easier to follow and understand.
Add a note about the properties that, instead of using a semicolon
separated list, use individual key-value pairs per list element
(addresses, routes and routing-rules), since this is also a relevant
difference from the standard key file format and from the settings
specification format.
