summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-09-08device: allow autoconnect on externalth/wl/tmpWen Liang4-3/+21
In some scenarios, autoconnect should not be blocked if the device is activated on the external connection (e.g. autoconnect on the loopback device). Adding the `allow_autoconnect_on_external` flag to support such behavior.
2022-09-08support loopback interfaceWen Liang44-50/+846
Support managing the loopback interface through NM as the users want to set the proper mtu for loopback interface when forwarding the packets. Additionally, the IP addresses, DNS, route and routing rules are also allowed to configure for the loopback connection profiles. https://bugzilla.redhat.com/show_bug.cgi?id=2060905
2022-09-08glib-aux,platform: merge branch 'th/misc'Thomas Haller9-98/+147
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1370
2022-09-08platform: simplify nm_platform_ip_route_get_prune_list() to not reuse variablesThomas Haller1-56/+41
This optimization seems unnecessary. Just initialize a new route struct and use it. The advantage is that we can have the variable in the scope closer to where it's used, and don't need to think about what happens outside the scope.
2022-09-08platform: add NMPIPAddressSyncFlags parameter to nm_platform_ip_address_sync()Wen Liang3-23/+47
Previously, nm_platform_ip_address_sync() would always add the "IFA_F_NOPREFIXROUTE" flag. Add a way to let the caller control that. Add a flags argument, with a new flag "with-noprefixroute". By default (with flags "none"), nm_platform_ip_address_sync() would no longer add "IFA_F_NOPREFIXROUTE" flag, but the caller can now opt-in to that. The purpose is that on "lo" interface we will want to let kernel handle the prefix route. So have a per-ifindex opt-in for controlling this. During nm_platform_ip_address_flush() we use "none" flags, because the function anyway doesn't add any addresses, so it wouldn't matter. There is no change in behavior. Co-authored-by: Thomas Haller <thaller@redhat.com>
2022-09-08libnm-base,all: add and use NM_LOOPBACK_IFINDEX defineWen Liang4-4/+11
Co-authored-by: Thomas Haller <thaller@redhat.com>
2022-09-08glib-aux: add "NM_IPV4LO_NETWORK" defines and similarWen Liang2-3/+11
Co-authored-by: Thomas Haller <thaller@redhat.com>
2022-09-08glib-aux: add NM_IN6ADDR_INIT() macro and use itThomas Haller2-1/+26
2022-09-08platform/tests: use NM_ETHER_ADDR_INIT() macroThomas Haller1-13/+13
2022-09-08libnm: avoid serializing "ipv6.addr-gen-mode" default to D-BusThomas Haller1-2/+1
When serializing setting properties to GVariant/D-Bus, we usually omit values that are set to the default. That is done by libnm(-core), so it happens both on the daemon and client side. That might be useful to avoid a large number of properties on D-Bus. Before changing the default value for "ipv6.addr-gen-mode" ([1]), we would not serialize the previous default value ("stable-privacy"). Now we would serialize the new default value ("default). This change causes problems. Scenario 1: have a profile in the daemon with "ipv6.addr-gen-mode=stable-privacy", have an older daemon version before [1] and a newer client after [1]. Result: The daemon exposes the profile on D-Bus without the addr-gen-mode field (because it's the default). To the client, that is interpreted differently, as "ipv6.addr-gen-mode=default". This is already somewhat a problem. More severe is when modifying the profile, the client would now serialize the value "default" on D-Bus, which the older daemon rejects as invalid. That means, you could not modify the profile, unless also resetting addr-gen-mode to "stable-privacy" or "eui64". You can imagine other scenarios where either the daemon or the client is before/after change [1] and the addr-gen-mode is set to either "default" or "stable-privacy". Depending on what scenario you look, that can either be good or bad. Scenario 1 is pretty bad, because it means `dnf upgrade NetworkManager && nmcli connection modify ...` will fail (if the daemon was not restated). So try to fix Scenario 1, by also not serializing the new default value on D-Bus. Of course, some of the scenarios will get different problems, by exacerbating one side misunderstanding the actually set value and interpreting a missing value on D-Bus wrongly. But those problems are likely less severe. In case both client and daemon are older/newer than [1], it doesn't matter either way. The problem happens with different version and is caused by a change of the default value. [1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/e6a33c04ebe1ac84e31628911e25bdfd7534dd3c https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1372
2022-09-08man: update "--print-config" text in `man NetworkManager`Thomas Haller1-3/+11
2022-09-08contrib: fix syntax error in "configure-for-system.sh"Thomas Haller1-2/+2
2022-09-08device: don't ignore external slave removalsLubomir Rintel1-6/+10
We've been outright ignoring master-slave checks if the link ended up without a master since commit 2e22880894cf ('device: don't remove the device from master if its link has no master'). This was done to deal with OpenVSwitch port-interface relationship, where the interface's platform link lacked an actual master in platform (what matters there is the OVSDB entry), but the fix was too wide. Let's limit the special case to devices whose were not enslaved to masters that lack a platform link, which pretty much happens for OpenVSwitch only. Morale: Write better commit messages of future you is going to be upset Fixes: 2e22880894cf ('device: don't remove the device from master if its link has no master') https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1358
2022-09-08release: bump version to 1.41.2 (development)1.41.2-devThomas Haller2-2/+2
2022-09-08style: fix python black formatting of "generate-docs-nm-settings-docs-merge.py"Thomas Haller1-0/+2
2022-09-07Merge branch 'wl/ifcfg' into mainWen Liang4-50/+92
https://bugzilla.redhat.com/show_bug.cgi?id=2122703 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1357
2022-09-07ifcfg-rh: rework error handling in parse_infiniband_p_key()wl/ifcfgThomas Haller1-22/+20
2022-09-07ipoib: skip validating the DEVICE when reading the ifcfg fileWen Liang4-28/+73
For the ipoib connection, it is still considered as valid if the profile does not set the device name. Also, the ifcfg reader should not duplicate the checks that `nm_connection_verify()` performs (especially not wrongly). Therefore, NM should skip validating the DEVICE when reading the ifcfg file for the ipoib connection. https://bugzilla.redhat.com/show_bug.cgi?id=2122703
2022-09-07infiniband: avoid normalizing the p-key when reading from ifcfgWen Liang1-1/+0
When writing the p-key setting to the ifcfg file and reading the setting back, the value has to be consistent. This is not limited to p-key only, any setting value during the ifcfg write and read also has to be consistent. This was probably added in commit cb5606cf1c7a ('ifcfg-rh: add support for Infiniband partitions') as this is also what ifup-ib does ([1]). For NetworkManager profiles however, the p-key is also valid without the high bit set, so the ifcfg-rh reader must honor that. [1] https://github.com/alaahl/rdma/blob/0c9fb6ca7bcb4f24a6134e68338a88a84c4ab56c/rdma.ifup-ib#L75
2022-09-07Revert "platform: add the `a_no_auto_noprefixroute` flag"Wen Liang2-39/+23
This flag won't be used. Instead we will pass a flag to nm_platform_ip_route_sync() to disable addition of the prefix route flag. This reverts commit bd84ae4dc5a1e2b44a7471c3b0b4c3428b789a04.
2022-09-07manager: don't bring up master connections on devices that are not disconnectedLubomir Rintel1-5/+3
Otherwise we're likely interfering with an in-progress activation. Consider the following connections, first two being active: id=bond0a type=bond interface-name=bond0, (Active) id=dummy0a type=dummy interface-name=dummy0 master=bond0a, (Active) id=bond0b type=bond interface-name=bond0 id=dummy0b type=dummy interface-name=dummy0 master=bond0b Note there's two hierarchies with bond0 bond having a dummy0 port, first one (bond0a, dummy0a) being active. Suppose the users wants to bring the other one up (bond0b, dummy0b) and does a "nmcli c up bond0b". This is what happens: 1.) bond0b starts activation due to user request 2.) bond0a starts deactivation due to new activation 3.) dummy0 loses its master, begins deactivation 4.) dummy0 finishes deactivation 5.) both dummy0 being deactivated and bond0b check for slaves enqueues auto-activation check for dummy0 6.) auto-activation picks dummy0a for dummy0 7.) dummy0a begins activation 8.) dummy0a looks for master connection, picks bond0a 9.) bond0a starts activating on bond0, kicks bond0b away 10.) bond0a and dummy0a end up finishing activation 11.) Everybody unhappy :( NM's auto-activation logic is only takes autoconnect priority into account when figuring out a connection to activate and can't be expected to bring up most sensible combination of connection when there's multiple ones for the same devices with complex dependencies. Nevertheless, it shouldn't ever undo the activations if the user is bringing up the connections manually. This patch prevents bringing up of master devices that are not DISCONNECTED and therefore shouldn't be up for grabs. This was previously done for hardware devices only whereas I believe it should be the case for *all* realized devices. https://gitlab.freedesktop.org/NetworkManager/NetworkManager-ci/-/merge_requests/1172 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1364
2022-09-07merge: branch 'lr/docs-deprec-props'Lubomir Rintel9-55/+85
The documentation of property deprecation was not great in nm-settings-nmcli(5). This aims to improve that, essentially changing: number Legacy setting that used to help establishing PPP data sessions for GSM-based modems. Deprecated: 1 Into number Legacy setting that used to help establishing PPP data sessions for GSM-based modems. This property is deprecated since version 1.16. User-provided values for this setting are no longer used. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1367
2022-09-07generate-docs-nm-settings-docs-gir: remove space from the beginning of a paralr/docs-deprec-propsLubomir Rintel1-3/+3
From nm-settings-dbus(5): Before (ugly, offensive, possibly in violation of geneva protocol): ... | set, the authentication retries for 3 | times before failing the connection. | | Currently, this only applies to 802-1x | authentication. After (beautiful, smells good, in harmony with nature): ... | set, the authentication retries for 3 | times before failing the connection. | | Currently, this only applies to 802-1x | authentication.
2022-09-07setting-bridge,wireless: improve some deprecation warningsLubomir Rintel4-10/+8
The documentation paragraph contained deprecation information redundant with the deprecation tag. It looks ugly when rendered into a manual page.
2022-09-07setting-8021x: add deprecation tagsLubomir Rintel3-10/+12
Add deprecation tags to "subject-match" and "phase2-subject-match" properties and adjust the documentation slightly. They've been deprecated since commit 64b76ba90656 ('libnm-core: add domain-suffix-match properties to NMSetting8021x').
2022-09-07generate-docs-nm-settings-docs-gir: move deprecation info to a separate tagLubomir Rintel3-17/+42
Previously, the deprecation data was included in <description*>, in form of an integer. E.g.: /** * NMSettingLala:hello: * * Does this and that. * * Deprecated: 1.12: Be sad instead. **/ Results in: <property name="hello"> <description>Does this and that. Deprecated: 1</description> </property> Let's make it do this instead: <property name="hello"> <description>Does this and that.</description> <deprecated since="1.12">Be sad instead.</description> </property>
2022-09-07generate-docs-nm-settings-docs-merge: merge <deprecated*> elementsLubomir Rintel1-0/+7
They will be used to include property deprecation data.
2022-09-07generate-docs-nm-settings-docs-merge: streamline a bitLubomir Rintel1-18/+8
Replace a pair of overly sophisticated expressions with something that's easier to follow, avoiding code duplication at the same time.
2022-09-07man/nm-settings-nmcli: include deprecation description, if presentLubomir Rintel1-0/+6
2022-09-07man/nm-settings-dbus: include deprecation description, if presentLubomir Rintel1-1/+3
2022-09-07contrib: update bash history for "nm-in-container.sh" and motdThomas Haller1-3/+14
2022-09-06l3cfg: re-use plen variable in NMIPRoute creationFernando Fernandez Mancera1-2/+2
2022-09-06dhcp: merge branch 'bg/dhcp6-dad-pt2'Beniamino Galvani2-69/+125
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1363 https://bugzilla.redhat.com/show_bug.cgi?id=2096386
2022-09-05dhcp: implement decline on IPv6 DAD failure with dhclientBeniamino Galvani2-33/+33
The dhclient plugin already supports sending a decline when IPv4 ACD fails. Also implement support for IPv6 DAD. See-also: 156d84217ced ("dhcp/dhclient: implement accept/decline (ACD) for dhclient plugin")
2022-09-05dhcp: decline IPv6 lease if all adresses fail DADBeniamino Galvani1-36/+92
Currently we accept the DHCPv6 just after addresses are configured on kernel, without waiting DAD result. Instead, wait that DAD completes and decline the lease if all addresses are detected as duplicate. Note that when an address has non-infinite lifetime and fails DAD, kernel removes it automatically. With iproute2 we see something like: 602: testX6 inet6 2620::1234:5678/128 scope global tentative dynamic noprefixroute valid_lft 7500sec preferred_lft 7200sec Deleted 602: testX6 inet6 2620::1234:5678/128 scope global dadfailed tentative dynamic noprefixroute valid_lft 7500sec preferred_lft 7200sec Since the address gets removed from the platform cache, at the moment we don't have a way to check the flags of the removal message. Therefore, we assume that any address that goes away in tentative state was detected as duplicate. https://bugzilla.redhat.com/show_bug.cgi?id=2096386
2022-09-03device: don't emit recheck-assume if there is a queued activation requestBeniamino Galvani1-1/+1
The @dracut_NM_vlan_over_team_no_boot sometimes fails, among other things, because it fails to assume an indicated connection after a restart. That seems to happen because after the decision to activate the indicated connection, the device does not move from DISCONNECTED state quickly enough. Another assumption recheck runs in between and decides to generate a connection, because the assume state was already reset in between. First start, creates and activates b3a61b68-f744-4a4c-a513-61399c154a67 on vlan0017: NetworkManager (version 1.41.1-30921.55767cf5.el9) is starting... (asserts:10000, boot:caf7301a-19cd-498b-b5ba-5d36ee939ffe) ... settings: update[b3a61b68-f744-4a4c-a513-61399c154a67]: adding connection "vlan0017" (45113870df0a4cfb/keyfile) Second start: NetworkManager (version 1.41.1-30921.55767cf5.el9) is starting... (after a restart, asserts:10000, boot:caf7301a-19cd-498b-b5ba-5d36ee939ffe) Assumption attempt successfully picks the right connection and thus proceeds to reset the assume state: manager: (vlan0017): assume: will attempt to assume matching connection 'vlan0017' (b3a61b68-f744-4a4c-a513-61399c154a67) (indicated) device[c7c5101cf0b73f5f] (vlan0017): assume-state: set guess-assume=0, connection=(null) Everything great so far, activation of the right connection is enqueued and the device moves away from unavailable state. However, the activation can't proceed immediately: device (vlan0017): state change: unmanaged -> unavailable (reason 'connection-assumed', sys-iface-state: 'assume') device (vlan0017): state change: unavailable -> disconnected (reason 'connection-assumed', sys-iface-state: 'assume') active-connection[0x55ba1162f1c0]: set device "vlan0017" [0x55ba1163c4f0] device[c7c5101cf0b73f5f] (vlan0017): queue activation request waiting for carrier Now another assumption attempt is done. The original assume state is gone, so a connection is generated: platform-linux: UDEV event: action 'add' subsys 'net' device 'vlan0017' (6); seqnum=1959 device[c7c5101cf0b73f5f] (vlan0017): queued link change for ifindex 6 manager: (vlan0017): assume: generated connection 'vlan0017' (57627119-8c20-4f9e-bf4d-4fc427b4a6a9) keyfile: commit: 57627119-8c20-4f9e-bf4d-4fc427b4a6a9 (vlan0017) added as "/run/NetworkManager/system-connections/vlan0017-57627119-8c20-4f9e-bf4d-4fc427b4a6a9.nmconnection" (nm-generated,volatile,external) I think this shouldn't have happened. We've picked the correct connection already and it's enqueued for activation! Change the check in nm_device_emit_recheck_assume() to also consider any queued activation. Fixes-test: @dracut_NM_vlan_over_team_no_boot Co-authored-by: Lubomir Rintel <lkundrak@v3.sk> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1351
2022-09-02libnm: merge branch 'th/libnm-doc-annotation-fixes'Thomas Haller11-53/+52
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1352
2022-09-02libnm: fix invalid doc annotations for missing end tagThomas Haller1-0/+1
2022-09-02libnm: style cleanups for property annotationsThomas Haller9-24/+46
The parser will become stricter, and expect certain things. The strictness should help, to avoid writing wrong annotations. Adjust for that.
2022-09-02libnm: avoid "tag:" text inside documentationThomas Haller1-2/+2
The parser is reworked, and this line could be wrongly parsed because it starts with " * value:" which could be misinterpreted as a tag. It actually won't be parsed wrongly and is not parsed wrongly now. Still, avoid this potential ambiguity by breaking the line differently.
2022-09-02libnm: drop invalid "---ifcfg-rh---" blocksThomas Haller1-24/+0
2022-09-02libnm: fix documentation annotations for ifcfg-rh pluginThomas Haller3-3/+3
2022-09-02team: restore port configuration after teamd respawnLubomir Rintel1-16/+40
If teamd crashes, we restore it. That's very nice, but if it really crashed then it left ports attached and the slave connections are not going to fail and the port configuration (e.g. priority or link watcher) in teamd's memory will be gone. This will restore the port configuration when the teamd connection is re-established. This probably also fixes a race where a slave connection would be enslaved (only possible externally and manually?) while we didn't establish a connection to teamd yet. We'll just send the port configuration in once're connected. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1361
2022-09-02team: trivial: use a variable instead of nm_device_get_ip_iface() callsLubomir Rintel1-10/+9
This reads a little better and performs marginally better. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1361
2022-09-02ovs: merge branch 'add-ovs-option'Vojtech Bubela7-5/+65
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1322
2022-09-02ovs: add ofport_request option to ovs interfaceadd-ovs-optionVojtech Bubela7-5/+65
Add option to set ofport_request when configuring ovs interface. When connection with ofport_request configured is activated ovsdb will first try to activated on the port set by ofport_request.
2022-09-01version: reformat file for latest styleThomas Haller1-35/+34
the .h.in file is not formatted by our nm-code-format.sh file. It also contains .in template parameters that the formatting would destroy. Still, follow our current style and reformat the parts manually.
2022-09-01contrib: add "reset" command to "nm-in-container.sh"Thomas Haller1-9/+14
It's between "stop" and "clean". It removes the container, but keeps the container images. This is to fast restart without rebuilding the container (image).
2022-09-01nmcli: don't translate "%s"Lubomir Rintel1-1/+1
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1354
2022-09-01manager: drop useless use of a format stringLubomir Rintel1-1/+1
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1355
generated by cgit v1.2.3 (git 2.39.1) at 2024-09-21 10:27:36 +0000