| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
| |
Co-authored-by: Thomas Haller <thaller@redhat.com>
|
|
|
|
| |
Co-authored-by: Thomas Haller <thaller@redhat.com>
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |
| |
| |
| |
| |
| | |
The documentation paragraph contained deprecation information redundant
with the deprecation tag. It looks ugly when rendered into a manual
page.
|
| |
| |
| |
| |
| |
| |
| |
| | |
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').
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
|/ |
|
|
|
|
|
|
|
| |
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")
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
The parser will become stricter, and expect certain
things. The strictness should help, to avoid writing wrong annotations.
Adjust for that.
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
This reads a little better and performs marginally better.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1361
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1354
|
|
|
|
| |
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1355
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Because, why not?
The client side determines the UUID, so there is no security implication
by letting the nmcli user explicitly choose it.
$ nmcli connection add type ethernet con-name x connection.uuid 6965f79c-4424-4918-98e8-3c0982434011
Connection 'x' (6965f79c-4424-4918-98e8-3c0982434011) successfully added.
$ nmcli connection add type ethernet con-name x connection.uuid 6965f79c-4424-4918-98e8-3c0982434011
Error: Failed to add 'x' connection: a connection with this UUID already exists
$ nmcli connection modify x connection.uuid 6965f79c-4424-4918-98e8-3c0982434011
$ nmcli connection modify x connection.uuid 6965f79c-4424-4918-98e8-3c0982434012
Error: failed to modify connection.uuid: the property can't be changed.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It is useful to modify the UUID in offline mode. Otherwise, it's
cumbersome to clone a profile, because the cloned profile will
have the same UUID (and NetworkManager cannot load them both
at the same time).
umask 077
nmcli --offline connection modify \
connection.id profile2 \
connection.uuid new \
< /etc/NetworkManager/system-connections/profile1.nmconnection \
> /etc/NetworkManager/system-connections/profile2.nmconnection \
The doctext doesn't actually work for `man nm-settings-nmcli`. The
generation of our docs is still an incomprehensible mess that needs
fixing.
|
| |
|
|
|
|
|
|
|
|
| |
offline mode
We will want to know whether we are in offline mode.
Add an accessor to get environment flags, which libnmc-setting
can use.
|
|
|
|
|
|
|
|
| |
We really should not pass bogus values "1, 0" to g_set_error().
As we don't care about a particular error code, use
NM_UTILS_ERROR_UNKNOWN.
While at it, use nm_utils_error_set() everywhere.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
nm_uuid_generate_from_strings()
Try to first use a stack allocated buffer for the temporary string.
Only if the data is too large, NMStrBuf will automatically grow
the buffer on the heap.
In many cases, this buffer will be large enough, and we can avoid the
heap allocation.
|
|
|
|
|
|
| |
It's wrong, and it breaks certain uses.
Fixes: 13d25f9d0b2f ('glib-aux: add support for starting with stack-allocated buffer in NMStrBuf')
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
nmi_ibft_read()
- move the second g_file_test() inside the if-block. No need to check
twice, if the file exists.
- load_one_nic() can return NULL. Use nm_g_hash_table_lookup() to avoid
NULL pointer assertion.
- use cleanup attribute for "nic" variable, and explicitly pass
ownership on with g_steal_pointer().
|
|
|
|
|
|
|
|
|
|
| |
Honor firewall-backend for modules loading and ip forwarding enabling as
well:
* iptables: do not load nftables modules
* nftables: do not load iptables modules
* none: do not load any modules and do not enable ip forwarding
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1356
|
| |
|
|
|
|
|
|
|
| |
The user might still want to see the scan list, to decide whether to
stop the hotspot/ADHOC connection and connect to something else.
Allow explicit scans.
|
|
|
|
|
|
|
| |
ModuleNotFoundError was only introduced in later python 3 versions.
Use just "ImportError", which is the parent class anyway.
Fixes: f7e484c8eda4 ('tests: fix "test-client.py" ignoring missing "NM" module')
|
|
|
|
| |
Fixes: eec9efd98950 ('glib-aux: fix nicks for zero flag in nm_utils_enum_to_str()')
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the MAC changes there is the possibility that the DHCP client will
not be able to renew the address because it uses the old MAC as
CHADDR. Depending on the implementation, the DHCP server might use
CHADDR (so, the old address) as the destination MAC for DHCP replies,
and those packets will be lost.
To avoid this problem, restart the DHCP client when the MAC changes.
https://bugzilla.redhat.com/show_bug.cgi?id=2110000
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
connection assumed
The test in question leaves the device with a master set, which caused a
connection to get assumed and therefore the previous fix didn't kick in.
Fixes-test: @restart_L2_only_lacp
Fixes: 5b7f8f3f7051 ('device: wait for carrier even if it wasn't us who brought the device IFF_UP')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1348
|