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>
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.
Yes, there probably are not multiple threads here. It's a matter of principle to
not use smelly functions.
Also, copy the "errno" value we want to print, before calling various functions.
We have nm_strerror_native_r(), which is the wrapper around strerror_r() that
we want to use in glib components (it also will ensure that the string is valid
UTF-8). However, it's not usable from non-glib components.
Move the part that abstracts strerror_r() out to libnm-std-aux as _nm_strerror_r().
The purpose is that non-glib componenent can use the thread-safe wrapper around
strerror_r().
Systemd does not use strerror(), so this define was unused.
Even if it would use it, we would better patch the upstream
sources, as strerror() is not suitable in multi-threadded applications.
Show all valid properties for ip-tunnel.mode, not only 2 examples.
Show constants as values suitable for user input in nmcli. That means
showing, for example, "ipip (1)" instead of "IP_TUNNEL_MODE_IPIP (1)".
f-string is not supported in python2, and the autotool build complains
about it as follows:
```
LIBTOOL="/bin/sh ./libtool" "../src/tests/client/test-client.sh" "." ".." "python2" -- TestNmCloudSetup
File "/builds/NetworkManager/NetworkManager/src/tests/client/test-client.py", line 722
return f"{major}.{minor}.{micro}"
^
SyntaxError: invalid syntax
test-client.py failed!!
make[3]: *** [check-local-tests-client] Error 1
File "/builds/NetworkManager/NetworkManager/src/tests/client/test-client.py", line 722
return f"{major}.{minor}.{micro}"
^
SyntaxError: invalid syntax
test-client.py failed!!
```
Also, python2 complains about extra comma during argument unpacking.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1718
When rolling back a checkpoint, NM will crash due to dereference a NULL
pointer of `priv->removed_devices->len`.
To fix it, we just place a NULL check before that code block.
Fixes: 1f1b71ad9f ('checkpoint: preserve devices that were removed and
readded')
Reference: https://issues.redhat.com/browse/RHEL-1526
Signed-off-by: Gris Ge <fge@redhat.com>
The device authentication request is an async process, it can not know
the answer right away, it is not guarantee that device is still
exported on D-Bus when authentication finishes. Thus, do not return
SUCCESS and abort the authentication request when device is not alive.
https://bugzilla.redhat.com/show_bug.cgi?id=2210271
When we register the auto-activate, the device has to be registered in
NMPolicy, the assertion is correct and ensure that.
This reverts commit 712729f652.
It's not strictly necessary, because GObject.constructed() is
intentionally a NOP, to optionally allow chaining the parent method.
However, for consistency, this is what we commonly do.
l3cfg emits a log for ACD conflicts. However, l3cfg is not aware of
what are the related NMDevice or the currently active connection, and
so it can't log the proper metadata fields (NM_DEVICE and
NM_CONNECTION) to the journal.
Instead, let NMDevice log about ACD collisions; in this way, it is
possible to get the message when filtering by device and connection.
For example:
$ journalctl -e NM_CONNECTION=d1df47be-721f-472d-a1bf-51815ac7ec3d + NM_DEVICE=veth0
<info> device (veth0): IP address 172.25.42.1 cannot be configured because it is already in use in the network by host 00:99:88:77:66:55
<info> device (veth0): state change: ip-config -> failed (reason 'ip-config-unavailable', sys-iface-state: 'managed')
<warn> device (veth0): Activation: failed for connection 'veth0+'
When a collision is detected by the Address Conflict Detection
mechanism, store the conflicting MAC address in NML3AcdAddrInfo, so
that it is available to listeners of NML3Cfg for events of type
NM_L3_CONFIG_NOTIFY_TYPE_ACD_EVENT.
When a device belonging to a checkpoint is removed, we clear the
device pointer from the DeviceCheckpoint and move the object from the
devices list to the removed-devices list of the checkpoint.
Later, when restoring the connection we need to set again the device
pointer in DeviceCheckpoint; otherwise, any connection on that device
can't be reactivated if changed.
Fixes: 0e2f7ac7b5 ('nm-checkpoint: drop reference to NM_DEVICE objects on removal signal')
With flag DISCONNECT_NEW_DEVICES, on rollback we delete devices that
are present in the system and are not in the checkpoint.
The problem is that we remove the device from
`NMCheckpointPriv->devices` when it is deleted and so we lose the
information that the device was in the checkpoint. We need to also
look in the `removed_devices` list.
Fixes: 0e2f7ac7b5 ('nm-checkpoint: drop reference to NM_DEVICE objects on removal signal')
The macros NM_MIN()/NM_MAX()/NM_CLAMP() use typeof() to accept any
integer type as argument. Internally, they rely on standard C integral
conversions of the <> operators and the ternary operator for evaluating
the comparison and the result(type).
That works mostly great. Except, comparing signed and unsigned values in
C leads to oddities and the caller should explicitly take care of that.
Add static assertions to check that the compared arguments have the same
signedness.
When updating NetworkManager to a new version, normally the service is
not restarted by the installer to avoid interrupting networking.
However, next nmcli invocation will use the updated version, but against
the older version of the daemon that is still running. Although this is
suposed to work, it is advisable that nmcli and daemon's versions are
the same. Emit a warning recommending restarting the daemon.
Add nmcli test to check the new feature. To avoid breaking the existing
tests, test-networkmanager-service now reports the same version than the
running nmcli except if it's instructed to report a different one.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1703
Parse the access point announced bandwidth in MHz. This is considering
both HT and VHT. Please notice that for VHT 80+80 MHz we are representing it
as 160 MHz.
Software devices that are controllers like bond/bridge/team when
configured to not ignore carrier are being deleted when deactivating the
device. Software devices that are not controllers, shouldn't be deleted.
Otherwise, if a VLAN link is deleted because the ethernet carrier-change
then NetworkManager won't be able to reactivate the VLAN once the
ethernet gets carrier because the link is not present.
This is restoring the previous behaviour and it's know to be relied on
by users.
https://bugzilla.redhat.com/show_bug.cgi?id=2224479https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1701
Fixes: efa63aef3a ('device: delete software device when software devices lose carrier')
Move the warning about the presence of ifcfg-rh profiles from the
plugin to NMSettings. In this way, it will be easier to implement the
migration option in the next commit.
