Previous commits added the capability to persist to disk the value of
'managed' received via the D-Bus API. Users might need to clear the
previous content, thus reseting it to its default.
Although this is specially useful for the PERMANENT flag, we need to be
consistent and reset the runtime state too.
If the NM_DEVICE_MANAGED_FLAGS_PERMANENT flag is used, the value will be
stored to disk, to the NetworkManager-intern.conf file, in a [device-*]
section.
To modify the runtime value, the NM_DEVICE_MANAGED_FLAGS_RUNTIME must be
passed. This allows to control independently whether to modify only one
or both.
To support setting devices as managed or unmanaged via D-Bus API in a
permanent way, we need a way to store this configuration on disk. Before
this commit, only config files manually edited allowed it. Following
commits will make use of the new functions to store [device-*] sections
into NetworkManager-intern.conf depending on D-Bus method invocations.
The 'Managed' property only sets the managed state in runtime, but it is
not possible to persist it to disk. Add a SetManaged method that will be
able to persist it to disk. In this commit, it just modify the runtime
state, so it actually only does the same than setting the property.
Storing to disk will be added in next commits.
With `nmcli -f SLAVE` the PORT column will be shown. In this case we
don't duplicate the field because it's typically shown in columns and
having duplicated columns is more annoying than a duplicated row.
They show the same than the old BRIDGE/TEAM.SLAVES and GENERAL.MASTER-PATH.
We missed this when we did the changes in favour of conscious language.
Instead of replacing them, we add a new field that will show the same
value with the new name. This way we avoid breaking users doing
`nmcli -f BRIDGE.SLAVES` or `nmcli ... | grep SLAVES`.
RFC 3442 says:
If the DHCP server returns both a Classless Static Routes option and
a Router option, the DHCP client MUST ignore the Router option.
Currently the internal client is ignoring the Router option only if
the Classless Static Routes option doesn't include a default route,
which is different from what is recommended in the RFC. Fix the behavior.
Fixes: 6adade6f21 ('dhcp: add nettools dhcp4 client')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/834
In kernel, the onlink flag (RTNH_F_ONLINK) is associated with each
nexthop (rtnh_flags) rather than the route as a whole. NM previously
stored it only per-route in NMPlatformIPRoute.r_rtm_flags, which meant
that two nexthops only differing with the onlink flag were combined
as one entry in the platform cache.
Fix this by tracking the onlink flag per-nexthop.
Resolves: https://issues.redhat.com/browse/NMT-1486
This adds some low-hanging food to improve our score with "systemd-analyze
security" by one point:
Before:
→ Overall exposure level for NetworkManager.service: 7.8 EXPOSED 🙁
After:
→ Overall exposure level for NetworkManager.service: 6.8 MEDIUM 😐
Nothing particularly impactful here: we still got DAC_OVERRIDE, we still
can insert loadable modules (as opposed to relying on autoload) and
read user home directories. But there's a slight chance this may save
our butts one day, who knows.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2062
dns-search parameters set on VPN connections should be merged with
domains received through the VPN (which may be empty if the connection
sets ignore-auto-dns).
This is currently not the case because domains received by the VPN
connection are only added through nm_l3_config_data_add_domain.
If dns-search is unset, this behaves correctly because the structure
built in _mgr_configs_data_construct in src/core/dns/nm-dns-manager.c
correctly uses the domains from nm_l3_config_data_get_domains.
However if dns-search is set, nm_l3_config_data_get_searches is no
longer empty and it takes precedence because of the "n_searches > 0"
condition.
The previous check was based only on the presence of a non-NULL
"existing_secrets" GVariant. That GVariant is created via:
nm_connection_to_dbus(nm_settings_connection_get_connection(self),
NM_CONNECTION_SERIALIZE_WITH_SECRETS_SYSTEM_OWNED)
The function returns a GVariant containing a first-level dictionary
for each setting, even for those that doesn't contain any secrets. As
a result, the check was requiring the system.modify permission even if
there weren't any cached secrets to send to the agent.
Fix the check to actually check for the presence of any secrets in the
cached dictionary. Some connection types have a third-level
dictionary that can be empty, for example VPNs have vpn.secrets.
The "modify.system" polkit permission allows a user to modify settings
for connection profiles that belong to all users.
For this reason, when an agent returns system secrets (i.e. secrets
that are going to be stored to disk), NetworkManager checks that the
agent has the modify.system permission.
If a secret has the AGENT_OWNED flag, it's stored in the agent
itself. If the secret has the NOT_SAVED flag, it will be asked to
users at the beginning of every connection attempt.
In both those cases the profile is not modified and there is no need
for the modify.system permission. Fix the check to also consider the
NOT_SAVED flag.
Properties that define a .to_dbus_function() as a D-Bus override, need
to return early if the flags only ask to serialize secrets.
Fixes: 7fb23b0a62 ('libnm: add NMIPRoutingRule API')
Added support for the following properties in connection profile:
id (VNI), remote IPv4/IPv6, ttl, tos, df, destination port.
See IP-LINK(8) manual page with command `man 8 ip-link` for more details
on the properties. See also previous commit for nm supported attributes.
id and remote are mandatory attributes:
```
$ nmcli connection add type geneve save no
Error: 'id' argument is required.
$ nmcli connection add type geneve id 42 save no
Error: 'remote' argument is required.
```
GENEVE (Generic Network Virtualization Encapsulation) is a network
tunneling protocol that provides a flexible encapsulation format for
overlay networks. It uses UDP as the transport protocol and supports
variable-length metadata in the tunnel header.
This patch adds GENEVE tunnel to NM's platform layer:
- Add platform API functions (nm_platform_link_geneve_add,
nm_platform_link_get_lnk_geneve)
- Netlink message parsing for the following attributes:
* IFLA_GENEVE_ID - VNI (Virtual Network Identifier)
IPv4 and IPv6 remote
* IFLA_GENEVE_REMOTE
* IFLA_GENEVE_REMOTE6
TTL, TOS, and DF flags
* IFLA_GENEVE_TTL
* IFLA_GENEVE_TOS
* IFLA_GENEVE_DF
UDP destination port
* IFLA_GENEVE_PORT
- Add test cases for GENEVE tunnel creation and detection with two test
modes covering IPv4 and IPv6.
The implementation tries to follow the same patterns as other tunnel
types (GRE, VXLAN, etc.) and integrates with the existing platform
abstraction layer.
`use_carrier` is removed from kernel since 6.18 [1], and returns
the following error if set to 0:
> option obsolete, use_carrier cannot be disabled
This causes a failure of test-link-linux, so let's set it to 1.
[1] https://lore.kernel.org/all/2029487.1756512517@famine/
(cherry picked from commit d40e88fd02)
The formula is wrong for channels above 144 because the layout of the
80MHz channels is not regular. Use a lookup table.
Fixes: 7bb5961779 ('supplicant: honor the 'wifi.channel-width' property in AP mode')
(cherry picked from commit 5763b9b4de)
On a i686 machine the build fails with:
../src/nm-cloud-setup/main.c: In function ‘_oci_new_vlan_dev’:
../src/nm-cloud-setup/main.c:800:47: error: format ‘%ld’ expects argument of type ‘long int’, but argument 2 has type ‘gssize’ {aka ‘int’} [-Werror=format=]
800 | macvlan_name = g_strdup_printf("macvlan%ld", config_data->iface_idx);
| ~~^ ~~~~~~~~~~~~~~~~~~~~~~
| | |
| long int gssize {aka int}
| %d
../src/nm-cloud-setup/main.c:801:42: error: format ‘%ld’ expects argument of type ‘long int’, but argument 3 has type ‘gssize’ {aka ‘int’} [-Werror=format=]
801 | connection_id = g_strdup_printf("%s%ld", connection_type, config_data->iface_idx);
| ~~^ ~~~~~~~~~~~~~~~~~~~~~~
| | |
| long int gssize {aka int}
| %d
Fixes: 68d7e17737 ('Reapply "cloud-setup: create VLANs for multiple VNICs on OCI"')
(cherry picked from commit 748be9a3e7)
