The only reason is consistency. The majority of times we
do use g_snprintf(). As there are no strong reasons to
prefer one over the other, prefer the one that use use
most of the time.
Add and call the new `nm_platform_link_get_permanent_address()` to
obtain `l_perm_address` via netlink or lookup via ethtool if kernel
does not expose the `IFLA_PERM_ADDRESS`.
And call the new `nm_platform_link_get_permanent_address()` in the unit
tests.
https://bugzilla.redhat.com/show_bug.cgi?id=1987286
Signed-off-by: Wen Liang <liangwen12year@gmail.com>
Replace the arguments "buf+length" of
`nm_platform_link_get_permanent_address()` with "NMPLinkAddress *out_addr"
Signed-off-by: Wen Liang <liangwen12year@gmail.com>
Add `l_perm_address` in `NMPlatformLink` and add it to
`nm_platform_link_to_string`, `nm_platform_link_hash_update`,
`nm_platform_link_cmp` functions, and parse it from netlink.
Signed-off-by: Wen Liang <liangwen12year@gmail.com>
No actual caller should use the API without providing either a filename
or the directory name. I don't think this can actually happen, hence
fail and assert in that case.
Have an ifcfg file loaded in NetworkManager, then move/remove the file and try
to modify it. That will fail with:
"failed to update connection: Could not read file '/etc/sysconfig/network-scripts/ifcfg-eth0': No such file or directory"
That is not right.
If the user didn't move/remove the file but merely modified it, NetworkManager
would silently overwrite it. There is no reason why move/remove should behave
differently and not just write a completely fresh file.
The reason why NetworkManager first loads the file before writing, is to
preserve comments and unrecognized shell variables. This is a certain effort
to play nice with users editing the file. It's not essential to load the file
first and a failure to do so should not result in a failure.
And of course, keyfile writer doesn't behave like this either.
This bug exists since 2009, but let's not add a "Fixes" comment for
commit 1974b257e0 ('ifcfg-rh: begin adding write support'), because
it seems not right to backport this patch to all the old releases.
Use `_nm_connection_ensure_setting()` to eliminate the
duplicated codes. This function will retrieve the specific setting from
connection, if not found, create new one and attach to the connection.
Signed-off-by: Gris Ge <fge@redhat.com>
Introduce internal function `_nm_connection_ensure_setting()` to
`libnm-core-aux-intern` and add specified setting to connection if not
found.
Signed-off-by: Gris Ge <fge@redhat.com>
Commit df0dc912cc ('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 df0dc912cc ('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/965
For IPv4, the order is not like for IPv6. Of course not.
Fixes: 7aa4ad0fa2 ('nmcli/docs: better describe ipv[46].addresses in `man nm-settings-nmcli`')
Commit c631aa48f0 ('platform: capture NMIP[46]Config from platform
with correct (reversed) order of IP addresses') changed this for IPv6
and IPv4, but it's not correct for IPv4.
For IPv6, later `ip addr add` calls adds a new primary address, which
is also listed in `ip addr show` first. Hence, as NMIP6Config tracks
addresses in increasing priority, while NMPlatform tracks them as
exposed by kernel, the order when appending addresses form platform
to NMIP6Config must be reversed.
That is not the case for IPv4. For IPv4, later `ip addr add` calls
add a secondary IP address. Also, in `ip addr show` output they are
appended. Consequently, IPv4 addresses are tracked by NMPlatform with
decreasing priority (in the reverse order than for IPv6).
Fix constructing the NMIP4Config by fixing the address order. This is
important, because during restart devices get assumed and our code would
configure the order of addresses as it finds them.
Fixes: c631aa48f0 ('platform: capture NMIP[46]Config from platform with correct (reversed) order of IP addresses')
Do "bother" to read/write settings.
For the umpteenth time, it's not up to the reader/writer to decide
what properties are valid for a profile or which makes sense.
Only nm_connection_verify() can decide that. For example nm_connection_verify()
has no problem with ipv6.method=disabled while also setting ipv6.addr-gen-mode.
We cannot just shortcut the parsing/writing.
The reader only ignores addresses, dns and dns-searches, so that we don't start
parsing invalid files, where the setting would have been ignore
previously.
In particular,
echo "DEVICE=eth0" > /etc/sysconfig/network-scripts/ifcfg-xxx
nmcli connection load /etc/sysconfig/network-scripts/ifcfg-xxx
nmcli -f ipv6.method,ipv6.addr-gen-mode connection show /etc/sysconfig/network-scripts/ifcfg-xxx
needs to show eui64 addr-gen-mode.
It's not the task of the ifcfg reader to pre-normalize profiles
to truncate the DNS server list. It's only nm_connection_verify()'s
task to indicate what is valid and what not.
Increase the number to something excessive. Note that the parsing
scales with O(n^2). So don't have it totally unbounded and have an
overall limit (of 10000 entries).
Fix the order of IP addresses when assuming devices (service restart).
The order of IP addresses matters to kernel for selection of source IP
address.
If all other properties are equal ([1]), for IPv6, the address added *last*
will be preferred. That is the address you see *first*` in `ip -6 addr show`.
NMPlatform also preserves that order, so the address *first* is the most
important one.
On the other hand, in a connection profile, `ipv6.addresses` lists
addresses in increasing priority (the last address is the primary one).
That is for compatibility with initscripts, which iterates over the
list of addresses and calls `ip addr add` (meaning, the last address
will be added last and is thus preferred by kernel).
As the priority order in the profile is reversed, also the priority
order in NMIP[46]Config is reversed. Fix creating an NMIP[46]Config
instance from platform addresses to honor the priority.
This has real consequences. When restarting NetworkManager, the interface
stays up with the addresses configured in the right order. After
restart, the device gets assumed, which means that the NMIP[46]Config
instance from the connection is not yet set, only the config from the
platform gets synchronized. Previously the order was wrong, so during
restart the order of IP addresses was reverted.
[1] https://access.redhat.com/solutions/189153https://bugzilla.redhat.com/show_bug.cgi?id=1988751
It seems slightly nicer not to leave a dangling pointer at the
end of the iteration. Then you could do something like
nm_dedup_multi_iter_init(&iter, head_entry);
while (nm_dedup_multi_iter_next(&iter)) {
if (some_condition())
break;
}
if (!iter.current)
printf("iterated to the end\n");
As nm_dedup_multi_iter_next() and nm_dedup_multi_iter_init() are inline
functions, the compiler should even be able to see that the initial
setting becomes unnecessary (the field will be initialized by the
first nm_dedup_multi_iter_next()). Likewise, the final clearing
of the field might also be optimized away at the end of the iteration
(if, as in the common case, the iterator is not accessed afterwards).
Depending on sizeof(policy) to be sizeof(NULL) is not a good check
whether the macro argument may be NULL. That is, because the size
of the policy array might accidentally be the same as the size of
a pointer. Use _Generic() instead.
