NetworkManager merge requestshttps://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests2021-09-16T15:42:34Zhttps://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/974[th/cloud-setup-fix-containers] better handle other route configuration (incl...2021-09-16T15:42:34ZThomas Haller[th/cloud-setup-fix-containers] better handle other route configuration (including containers)nm-cloud-setup is supposed to automatically configured the network in the cloud environment.
As such, when a user wants a special network configuration, then it seems reasonable and expected that they disable the automatism -- if it does...nm-cloud-setup is supposed to automatically configured the network in the cloud environment.
As such, when a user wants a special network configuration, then it seems reasonable and expected that they disable the automatism -- if it doesn't do what they want.
Still, the automatism needs to work well in common cases. In particular, in cases where the user doesn't do something special. Such a case is running containers. The container runtime might create another interface and setup routes in the `main` table.
With the current setup of having
```
0: from all lookup local
30400: from 10.0.10.5 lookup 30400
32766: from all lookup main
32767: from all lookup default
```
and
```
default via 10.0.10.1 dev eth0 table 30400 proto static metric 10
10.0.10.1 dev eth0 table 30400 proto static scope link metric 10
```
it means that the "default" route hijacks all routes. That's wrong.
For issues see:
- https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/740
- in particular: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/740#note_956692
- https://bugzilla.redhat.com/show_bug.cgi?id=1977984#c27
===
This branch tries to fix that in two ways:
1) commit 'cloud-setup: skip configuring policy routing if there is only one interface/address':
\
\
If nm-cloud-setup only detects only one interface/address, there is no reason to configure any policy routing at all. That should solve the majority of cases, because having multiple IP addresses is in fact not something that is commonly done (I claim).
2) commit 'cloud-setup: use suppress_prefixlength rule to honor non-default-routes in the main table'
\
\
Add a rule
```
30300: from all lookup main suppress_prefixlength 0
```
This means to first look at the route table for any non-default routes. If found, that one is used and we skip our source-based policy routing rules. Only if the destination is only reachable via the default route, continue with source based routing (and look at tables 30400+, which has default routes configured). This effectively shortcuts the mechanism in many scenarios. Which by itself might be a problem, and maybe this make what nm-cloud-setup does useless. Dunno...
@nmeyerhans, what do you think?https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/973[th/fix-nm-sudo-symbols-for-ovs] fix build failure with clang on rhel/centos 72021-08-31T14:29:33ZThomas Haller[th/fix-nm-sudo-symbols-for-ovs] fix build failure with clang on rhel/centos 7https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/972[th/ethtool-autoneg-fixes] fix autoneg handling to advertise only requested s...2021-09-07T06:47:52ZThomas Haller[th/ethtool-autoneg-fixes] fix autoneg handling to advertise only requested speed and for re-activation- with autoneg=on and a speed/duplex set to advertise, ensure that we clear all the other modes.
- during re-activate of a device, fix resetting the mode.
https://bugzilla.redhat.com/show_bug.cgi?id=1897004#c10- with autoneg=on and a speed/duplex set to advertise, ensure that we clear all the other modes.
- during re-activate of a device, fix resetting the mode.
https://bugzilla.redhat.com/show_bug.cgi?id=1897004#c10https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/968[th/device-cleanup-and-kernel-features]2021-09-02T08:39:36ZThomas Haller[th/device-cleanup-and-kernel-features]- refactor some handling of activation state in `NMDevice`
- drop support for older kernels w.r.t. to some netlink features that they don't have.- refactor some handling of activation state in `NMDevice`
- drop support for older kernels w.r.t. to some netlink features that they don't have.https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/966Backport 'ip.required-timeout' to nm-1-302021-09-07T14:30:45ZBeniamino GalvaniBackport 'ip.required-timeout' to nm-1-30https://bugzilla.redhat.com/show_bug.cgi?id=1990460https://bugzilla.redhat.com/show_bug.cgi?id=1990460https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/9658021x: request PINs for PKCS#11 certs unless explicitly not-required2021-08-20T16:15:57ZBeniamino Galvani8021x: request PINs for PKCS#11 certs unless explicitly not-requiredCommit df0dc912cc6d ('8021x: don't request secrets if they are empty
and system owned') changed the setting so that NM doesn't request the
PIN for PKCS#11 certificates and keys when the password property has
NM_SETTING_SECRET_FLAG_NONE. ...Commit df0dc912cc6d ('8021x: don't request secrets if they are empty
and system owned') changed the setting so that NM doesn't request the
PIN for PKCS#11 certificates and keys when the password property has
NM_SETTING_SECRET_FLAG_NONE. From the commit message:
Empty secrets are fine. In particular, for PKCS#11 it means that
protected authentication path is used (the secrets are obtained
on-demand from the pinpad).
This change breaks the scenario in which PINs are stored in the
connection, as the setting indicates that no secrets are required, and
thus PINs are not sent to the supplicant.
If the PIN is entered through a pinpad, users should set the secret
flags as 'not-required'.
This reverts commit df0dc912cc6d ('8021x: don't request secrets if
they are empty and system owned').
https://bugzilla.redhat.com/show_bug.cgi?id=1992829https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/961obtain permanent hardware address via netlink or lookup via ethtool2021-08-30T06:24:03ZWen Liangobtain permanent hardware address via netlink or lookup via ethtoolSigned-off-by: Wen Liang <liangwen12year@gmail.com>Signed-off-by: Wen Liang <liangwen12year@gmail.com>https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/960nm-initrd-generator: remove duplex option, include man entry2021-08-17T18:23:49ZAna Cabralnm-initrd-generator: remove duplex option, include man entryhttps://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/958aliyun: reuse ipv4 gateway address returned by metadata server2021-10-05T07:35:57ZWen Liangaliyun: reuse ipv4 gateway address returned by metadata serverThe default ipv4 gateway address of the VPC in Aliyun cloud is not the
first IP address in the CIDR subnet block, we should instead use the
ipv4 gateway address retrieved from the metadata server in
`_nmc_mangle_connection()`.
Signed-of...The default ipv4 gateway address of the VPC in Aliyun cloud is not the
first IP address in the CIDR subnet block, we should instead use the
ipv4 gateway address retrieved from the metadata server in
`_nmc_mangle_connection()`.
Signed-off-by: Wen Liang <liangwen12year@gmail.com>https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/955device: store the original MTU before force-setting it2021-08-18T12:46:41ZBeniamino Galvanidevice: store the original MTU before force-setting itIn case the MTU is force-set (e.g. for bridges), priv->mtu_initial and
priv->ip6_mtu_initial must be initialized before changing the MTU,
otherwise the wrong value will be restored on deactivation.
Fixes: e23798a5e5e8 ('bridge: force (h...In case the MTU is force-set (e.g. for bridges), priv->mtu_initial and
priv->ip6_mtu_initial must be initialized before changing the MTU,
otherwise the wrong value will be restored on deactivation.
Fixes: e23798a5e5e8 ('bridge: force (hack)-set of the MTU when explicitly set in the profile')
https://bugzilla.redhat.com/show_bug.cgi?id=1973536https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/953[th/l3cfg-21] various minor cleanups for daemon2021-08-05T16:50:32ZThomas Haller[th/l3cfg-21] various minor cleanups for daemonthese patches fell out of L3Cfg rework, and should be merged early.
They are mostly small, and independent of the later changes that are still in WIP.
There is no real common theme, aside that they are in preparation for future l3cfg w...these patches fell out of L3Cfg rework, and should be merged early.
They are mostly small, and independent of the later changes that are still in WIP.
There is no real common theme, aside that they are in preparation for future l3cfg work.https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/948[th/move-macros-to-std-aux]2021-08-02T07:16:26ZThomas Haller[th/move-macros-to-std-aux]move some macros from libnm-glib-aux to libnm-std-aux.
These macros are independent of glib, so they should not reside in libnm-glib-aux.
Also add _NM_ENSURE_POINTER(), for a compile time check that the argument is a pointer type. And ...move some macros from libnm-glib-aux to libnm-std-aux.
These macros are independent of glib, so they should not reside in libnm-glib-aux.
Also add _NM_ENSURE_POINTER(), for a compile time check that the argument is a pointer type. And use it.https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/942[th/setting-update-one-secret] refactor update_one_secret() handling of NMSet...2021-08-02T12:16:32ZThomas Haller[th/setting-update-one-secret] refactor update_one_secret() handling of NMSettinghttps://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/941nm-initrd-generator: add kernel command line options ethtool.autoneg and...2021-08-12T18:59:27ZAna Cabralnm-initrd-generator: add kernel command line options ethtool.autoneg and...nm-initrd-generator: add kernel command line options ethtool.autoneg and ethtool.speed to configure NICsnm-initrd-generator: add kernel command line options ethtool.autoneg and ethtool.speed to configure NICshttps://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/933[th/setting-more-direct]2021-07-23T17:53:48ZThomas Haller[th/setting-more-direct]continuation of !921.continuation of !921.https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/929core: persist the bootfile-name from DHCP2021-07-27T07:46:50ZBeniamino Galvanicore: persist the bootfile-name from DHCPThe bootfile location is needed by the anaconda dracut module; write it to the device state file.
https://bugzilla.redhat.com/show_bug.cgi?id=1979387The bootfile location is needed by the anaconda dracut module; write it to the device state file.
https://bugzilla.redhat.com/show_bug.cgi?id=1979387https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/925[th/ifcfg-warn-invalid]2021-07-15T08:10:29ZThomas Haller[th/ifcfg-warn-invalid]warn about badly formatted ifcfg files.
https://bugzilla.redhat.com/show_bug.cgi?id=1959656warn about badly formatted ifcfg files.
https://bugzilla.redhat.com/show_bug.cgi?id=1959656https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/919nmcli: include 'searches' field for nmcli device show2021-07-13T11:15:30ZAna Cabralnmcli: include 'searches' field for nmcli device show~~The rpm packaging is failing in tests due to a diff not expecting the new field, as we can see here:~~
~~test_003: https://gitlab.freedesktop.org/acabral/diff/-/commit/5d053cbd1539912653240a9c8776c6b1fa9a47e5~~
~~test_004: https://gi...~~The rpm packaging is failing in tests due to a diff not expecting the new field, as we can see here:~~
~~test_003: https://gitlab.freedesktop.org/acabral/diff/-/commit/5d053cbd1539912653240a9c8776c6b1fa9a47e5~~
~~test_004: https://gitlab.freedesktop.org/acabral/diff/-/commit/f8faa587d127b81881be7bb00a20314d4b93f7c9~~
~~Complete CI log (for fedora:34 failing test, that is failing the above tests): https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/jobs/11609072/raw~~
---
I edited the tests to support the new feature, now it can be reviewed and merged without test conflicts.https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/917device: send ARP announcements when there is carrier2021-07-13T07:41:35ZBeniamino Galvanidevice: send ARP announcements when there is carrierPreviously we sent announcements immediately for non-controllers, or
after the first port was attached for controllers.
This has two problems:
- announcements can be sent when there is no carrier and they would
be lost;
- if a co...Previously we sent announcements immediately for non-controllers, or
after the first port was attached for controllers.
This has two problems:
- announcements can be sent when there is no carrier and they would
be lost;
- if a controller has a port, the port could be itself a controller;
in that case we start sending ARPs with the fake address of the
port. Later, when a leaf port is added to the second-level
controller, the correct port MAC will be propagated by kernel up to
both controllers.
To solve both problems, send ARP announcements only when the interface
has carrier. This also solves the second issue because controllers
created by NM have carrier only when there is a port with carrier.
Fixes: de1022285a6c ('device: do ARP announcements only after masters have a slave')
https://bugzilla.redhat.com/show_bug.cgi?id=1956793https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/913Include peer_notif_delay bond option2021-07-16T16:19:31ZAna CabralInclude peer_notif_delay bond optionInclude peer_notif_delay bond option.Include peer_notif_delay bond option.