Instead of passing the setting on during ip4_start()/ip6_start(), make
it a property of NMDhcpClient.
This property is currently only set by OLPC devices, and is only
implemented by NMDhcpDhclient. As such, it also does not need to change
or get reset. Hence, and immutable, construct-only property is clearer,
because we don't have to pass parameters to ip[46]_start().
Arguably, the parameter is still there, but being immutable and always
set, make it easier to reason about it.
Kernel will coerce values like
ethtool -A eth0 autoneg on rx off
to have autonet still on.
Also, if autoneg on the interface is enabled, then `ethtool -A eth0 tx off`
has no effect.
In NetworkManager, the user cannot configure "autoneg on" together with
any rx/tx settings. That would render the profile invalid. However, we
also need to take care that a profile
nmcli connection add ... ethtool.pause-autoneg ignore ethtool.pause-tx off
really means off. That means, we must coerce an unspecified autoneg
setting to "off".
Setting pause-rx/pause-tx to an explicit value, implies that the user
does not want to enable autoneg. Reject that as invalid value in the
connection profile.
When writing XML text with XML library, single quote will not be
escaped. So remove the escaping for single quote in current tool.
Signed-off-by: Wen Liang <liangwen12year@gmail.com>
In order to make the generated XML file format consistent before and
after using XML library, replace self-closing `property` tag with
paired `property` tag.
Signed-off-by: Wen Liang <liangwen12year@gmail.com>
Currently we commit the MTU to the device when updating the IP
configuration, or when a port device is added to the controller. This
means that for a connection with DHCP, the MTU is set only after DHCP
has completed. In particular, if DHCP doesn't complete and the
connection has an infinite timeout, the MTU is never set.
_commit_mtu() tracks different sources for the MTU of a device, and
each source has a different priority. Among these sources there are
the parent link (for VLANs), a dynamic IP configuration (DHCP, PPP)
and the connection profile.
A MTU from the connection always has the highest priority and
overrides other sources.
Therefore, if the connection specifies an MTU it can be applied at
stage2, even before configuring IP addressing.
https://bugzilla.redhat.com/show_bug.cgi?id=1890234https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/859
If the device is still unmanaged by platform-init (which means that
udev didn't emit the event for the interface) when the device gets
realized, we currently clear the assume state. Later, when the device
becomes managed, NM is not able to properly assume the device using
the UUID.
This situation arises, for example, when NM already configured the
device in initrd; after NM is restarted in the real root, udev events
can be delayed causing this race condition.
Among all unamanaged flags, platform-init is the only one that can be
delayed externally. We should not clear the assume state if the device
has only platform-init in the unmanaged flags.
ntables backend is not yet well tested. Don't flip the default yet
but for now always use iptables.
Once nftables is shown to work well, revert this patch.
Add support for nftables, as a second backend beside iptables (firewalld
still missing).
Like iptables, choose to call the `nft` tool. The alternative would be
to use libnftables or talk netlink.
It's ugly to blocking wait for a process to complete. We already do that
for iptables, but we better should not because we should not treat other
processes as trusted and not allow untrusted code to block NetworkManager.
Fixing that would require a central manager that serializes all requests.
Especially with firewalld support, this will be interesting again,
because we don't want to synchronously talk D-Bus either.
For now, `nft` is still called synchronously. However, the internal
implementation uses an asynchronous function. That currently
serves no purpose except supporting a timeout. Otherwise, the only
reason why this is asynchronous is that I implemented this first, and
I think in the future we want this code to be non-blocking. So, instead
of dropping the asynchronous code, I wrap it in a synchronous function
for now.
The configured nft table is:
table inet nm-shared-eth0 {
chain nat_postrouting {
type nat hook postrouting priority srcnat; policy accept;
ip saddr 192.168.42.0/24 ip daddr != 192.168.42.0/24 masquerade
}
chain filter_forward {
type filter hook forward priority filter; policy accept;
ip daddr 192.168.42.0/24 oifname "eth0" ct state { established, related } accept
ip saddr 192.168.42.0/24 iifname "eth0" accept
iifname "eth0" oifname "eth0" accept
iifname "eth0" reject
oifname "eth0" reject
}
}
The new name makes it more generic, because the limitation exists
for iptables chains. Everything else (iptables comments, nftables
tables) has no such length limit.
Our clang-format style doesn't work well with these gtk-doc
tags.
For NetworkManager core, we don't use glib-mkenums. Thus, these
comments serve no purpose. Drop them for better formatting.
D-Bus 1.3.1 (2010) introduced the standard "PropertiesChanged" signal
on "org.freedesktop.DBus.Properties". NetworkManager is old, and predates
this API. From that time, it still had it's own PropertiesChanged signal
that are emitted together with the standard ones. NetworkManager
supports the standard PropertiesChanged signal since it switched to
gdbus library in version 1.2.0 (2016).
These own signals are deprecated for a long time already ([1], 2016), and
are hopefully not used by anybody anymore. libnm-glib was using them and
relied on them, but that library is gone. libnm does not use them and neither
does plasma-nm.
Hopefully no users are left that are affected by this API break.
[1] 6fb917178a
Probably pid_t is always signed, because kill() documents that
negative values have a special meaning (technically, C would
automatically cast negative signed values to an unsigned pid_t type
too).
Anyway, NMDhcpClient at several places uses -1 as special value for "no
pid". At the same time, it checks for valid PIDs with "pid > 1". That
only works if pid_t is signed.
Add a static assertion for that.
nmc_string_to_ternary() is much more flexible, in that it case
insensitive and accepts any unambiguous abbreviation.
Also, nmc_string_to_ternary() accepts "unknown" as alias for "default".
Also, nmc_string_to_ternary() accepts numeric values -1, 0, 1.
By using nmc_string_to_ternary(), we treat ethtool boolean options like
other ternary properties and accept the same keywords.
Introducing ethtool PAUSE support with:
* ethtool.pause-autoneg on/off
* ethtool.pause-rx on/off
* ethtool.pause-tx on/off
Limitations:
* When `ethtool.pause-autoneg` is set to true, the `ethtool.pause-rx`
and `ethtool.pause-tx` will be ignored. We don't have warning for
this yet.
Unit test case included.
Signed-off-by: Gris Ge <fge@redhat.com>
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/829
It's not the task of the writer to mangle/normalize profiles. If a profile
for a virtual device can have an [ethernet] setting, then unsuitable values
like s390 options must be either rejected by nm_connection_verify() or normalized
by nm_connection_normalize(). In no way it's right that the writer simple
pretends they are not set.
"/etc/NetworkManager/VPN" was historically the place for .name files for
VPN plugins. In the meantime, those should be under "/usr/lib/NetworkManager/VPN".
Still, NetworkManager honors (and possibly watches) the directory in
/etc. Mark the directory as %ghost.
The exact effect of this is not clear to me. It seems however right to
do, and works for my testing.
Since commit a447942fc0 ('contrib/rpm: rename package
"NetworkManager-config-routing-rules" to
"NetworkManager-dispatcher-routing-rules"'), the config-routing-rules
subpackage is gone.
This way to specify the version number with a variable parameter, causes
repeated messages in rpmdiff:
INFO NetworkManager-dispatcher-routing-rules changed from Obsoletes: NetworkManager-config-routing-rules < 1:1.32.0-0.2.el8 to Obsoletes: NetworkManager-config-routing-rules < 1:1.32.0-0.3.el8 on noarch
Avoid this by hard coding the obsoleted version.
This "Conflicts" is since commit b85b8ed6fa ('contrib/rpm: let
NetworkManager-libnm and NetworkManager-glib of differing version
conflict'). This was probably fine back then, but NetworkManager-glib is
long gone.
Also, not hard coding the version number leads to rpmdiff messages like:
NEEDS INSPECTION NetworkManager-libnm changed from Conflicts: NetworkManager-glib < 1:1.32.0-0.2.el8 to Conflicts: NetworkManager-glib < 1:1.32.0-0.3.el8 on all architectures
As NetworkManager-glib is long gone, hard code the version with which
we conflict.
The string buffer may be empty and _priv_str still %NULL. Doing
pointer arithmetic with a %NULL pointer is undefined behavior.
Avoid that.
It's probably not an issue, because it results in computing &(((char *) NULL)[0],
and then g_vsnprintf() would not even inspect the pointer (so it doesn't
matter whether the computed pointer is bogus). But still, there is
undefined behavior involved.
