Use the new "expand enumvals" feature of the doc generation scripts
to document the accepted values more accurately. This way, all
possible values are shown.
New generated text for dbus man page:
The tunneling mode, valid values: NM_IP_TUNNEL_MODE_IPIP (1), NM_IP_TUNNEL_MODE_GRE (2), NM_IP_TUNNEL_MODE_SIT (3), NM_IP_TUNNEL_MODE_ISATAP (4), NM_IP_TUNNEL_MODE_VTI (5), NM_IP_TUNNEL_MODE_IP6IP6 (6), NM_IP_TUNNEL_MODE_IPIP6 (7), NM_IP_TUNNEL_MODE_IP6GRE (8), NM_IP_TUNNEL_MODE_VTI6 (9), NM_IP_TUNNEL_MODE_GRETAP (10), NM_IP_TUNNEL_MODE_IP6GRETAP (11)
New generated text for nmcli, both for interactive mode and for the
man page:
The tunneling mode, valid values: ipip (1), gre (2), sit (3), isatap (4), vti (5), ip6ip6 (6), ipip6 (7), ip6gre (8), vti6 (9), gretap (10), ip6gretap (11)
In this case, the "enumvals with docs expansion" hasn't been used
because the option names are self explanatory and their explanations don't
add additional value.
This script only supported parsing inline documentation comments, of the
type "@ENUM_VAL_NAME: description".
Support also docblock comments, of the type:
typedef enum {
/**
* ENUM_VAL_NAME
*
* description
*/
ENUM_VAL_NAME,
...
}
If both styles are used for the same enum value, the docblock takes
precedence since it's probably more detailed.
Without this change, adding a docblock comment was causing an error in
this script, and then the whole build failed completely.
We need to support this because gtkdoc annotations like "(attributes
NM.internal=1)" only work in docblock comments, not in inline comments,
and we want to start using them for the "enumvals expansion" in
documentation.
Allow to define a comma separated list of tags, like
"---nmcli,keyfile,dbus---", instead of having to define separate blocks
of comments for each one ("---nmcli---", "---keyfile---"), even for the
same content.
This can be useful to avoid repeating the same comment if 2 targets
needs the same modifications to the general documentation, although this
case might be rare.
It will be more useful to allow using the new "expand enumvals" feature
because it can't be used from gtkdoc comments.
When using "enumval expansion" in documentation comments (i.e.
"#IPTunnelMode:*"), sometimes there are values that are only for
internal usage, and not intended to be used from public APIs. Sometimes
this value is even rejected when trying to set it from public APIs.
Allow to prevent values from appearing in public APIs documentation,
marking it with the custom annotation "(attribute NM.internal=1)".
Note: currently, gtkdoc doesn't support annotations on enum fields when
using the inline style "@ENUM_VALUE_NAME: description". Instead, a
docblock needs to be used:
enum EnumTypeName {
/**
* ENUM_VALUE_NAME: (attributes NM.internal=1)
*
* description
*/
ENUM_VALUE_NAME
...
}
Having to type manually all the accepted values in each property's
documentation is very error prone: you can make typos and you will
probably forget to always update them when new possible values are
added.
If the possible values are the variant 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.
Also, for nmcli documentation we want to show the pretty nickname of
each value because it's the more user friendly way for users to enter
the data. C names like NM_IP_TUNNEL_MODE_IPIP have no value here so they
mustn't be shown, and the pretty nickname "ipip" must be shown instead.
With this commit, the special string "#EnumName:*" can be used in docs
and it will be expanded to the complete list of accepted values. If the
docs that are being generated are for nmcli, pretty nicknames will be used
instead of C names.
It is also desirable to show a description of what each value means in
nmcli man pages. To do this, the special string "#EnumName:**" can be
used. It will expand the same way than "#EnumName:*" in the
"description" field of the property, but it will expand to a formatted
list with all the values and their explanations in the
"description-docbook" field. The "description-docbook" field is
currently only used for the nm-settings-nmcli man page.
To expand a single enum value in the proper format (i.e. using nicknames
in nmcli docs), use the string "%ENUM_VALUE".
However, this feature has an important limitation: it can only be used
for man/nm-settings-*.5 files generation, and the expansion only happens
in the special tagged comments (like ---nmcli---), not in the normal
gtkdoc comments. There are 2 reasons:
1. Any other documentation, other than man/nm-settings-*.5, is generated
directly with gtkdoc, that doesn't support this expansion feature.
2. The gtkdoc comment applies to everything, either nmcli or dbus,
keyfile, etc. We can't format the expanded text in a proper way
without knowing where it's going to be used.
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.
When activating a port connection it will require the controller
connection is active or a valid controller device candidate is available
for activation.
One of the conditions we consider for a controller device to be a valid
candidate for the connection is that it is not active, therefore we
should also consider as valid a device that is currently deactivating.
Otherwise, we could fail during the port activation just because the
deactivation of the controller device candidate didn't finish yet.
https://bugzilla.redhat.com/show_bug.cgi?id=2125615https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1693
Kernel's dev_valid_name() calls isspace(), which also rejects '\v'
and '\240'.
As this tightens the check, the change can break code that partly worked
before. It surely didn't work to the point, where an interface with such
name could be created in kernel.
# ip link add name $'foo\240bar' type dummy
RTNETLINK answers: Invalid argument
If --offline and --ask were used at the same time, and endless loop
showing the readline's prompt but without waiting for user's input
happened.
This was because when using --offline, all arguments are parsed and
resolved before running the g_main_loop. In nmc_readline_helper it was
checked that the main loop is running, so if g_main_loop_quit is called
we can stop waiting for user's input.
Fix this bug by continue polling for user input if the main loop is
running or if we are in offline mode. Cancelling the user input is
still possible both in normal and offline mode with Ctrl+C or Ctrl+D.
Added a test case to verify that this still works after future changes.
This flag is a setting that changes the behaviour of nmcli, it's not
only the current state of the program, so it makes more sense to put it
in NmcConfig than in NmCli.
Furthermore, it's needed to fix a bug in next commit, too.
The `nm_device_hw_addr_reset()` should only set MAC address on NIC
with valid(>0) interface index.
The failure was found by `ovs_mtu` test of NMCI, failed to reproduce
the original problem (`ovs_mtu` test of NMCI) with 100 times retry.
And no trace log found for original test failure, hence cannot tell why
`nm_device_hw_addr_reset()` been invoked with iface index 0.
Signed-off-by: Gris Ge <fge@redhat.com>
We delete devices when the connection goes down and NetworkManager
created the device earlier.
Software devices like bond/bridge/team default to ignoring carrier.
However, when configuring them to not ignore carrier
([device].ignore-carrier), they were not deleted when deactivating the
devices.
This adjusts commit d0c2a24b71 ('device: do not remove software devices
on initial disconnected (rh #1035814)'). Note that back then there was
no check whether the device has an activation queued, so it behaved
differently then.
When the software device enters the UNAVAILABLE state from UNMANAGED,
during cleanup we shouldn't delete the link.
Co-Authored-By: Beniamino Galvani <bgalvani@redhat.com>
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1686
When matching two connections one might be using UUID and the other one
could be using interface-name for the controller property. When
recovering from a fresh start NM does not have any context and when
generating a connection we are using UUID as the controller.
It is always hard to guess what is the right candidate to pick but at
least something NM can do is checking if the UUID matches a connection
with the same controller interface-name. If there are no other
conflicts, then we can assume that is a good canditate to activate.
This is a follow up to `dc254f90e2b306700a0b81f7194e9b0438c62f4c`.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1684
