The user does not want to send machine hostname to the DHCP server
globally by default to avoid ddns record getting created in IPAM.
otherwise, IPAM creates ddns records which might interfere with user's
regular host record. Thus, introduce the ternary property
dhcp_send_hostname_v2 to warrant this behavior.
Notice that we set the GSpec of dhcp-send-hostname-v2 to int, because
defining it as enum would make that it cannot be expanded in a backwards
compatible way if we need to add more values: old clients using libnm
would reject it due to the new value being unknown. Follow the same
strategy than _nm_setting_property_define_direct_enum, defining the
NMSettInfoPropertType as enum, but the glib's GSpec as int.
Resolves: https://issues.redhat.com/browse/RHEL-56565https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2029https://gitlab.freedesktop.org/NetworkManager/NetworkManager-ci/-/merge_requests/1765
Initial support for OCI. It doesn't support VLAN configuration yet as
the requirements are not clear. It doesn't support secondary IP
addresses because the IMDS server doesn't expose them.
Instead of using plain text format, it gets a single response in JSON
format and parses it. The dependency to jansson is now mandatory for
that.
When the "ipvX.routed-dns" property is set to true, add a route for
each DNS server via the current interface. The feature works in the
following way.
A new routing rule is created ("priority $PRIO not fwmark $MARK lookup
$TABLE") where $PRIO, $MARK and $TABLE are fixed values and are the
same for all interfaces. This rule is evaluated before standard rules
and tries to look up routes in table $TABLE, where NM adds the routes
to DNS servers.
To determine the next-hop to the name server, NM issues a RTM_GETROUTE
netlink request to kernel, specifying to return the route via the
current interface. In order to avoid results from $TABLE, NM also sets
the fwmark as $MARK in the request.
I think the current semantics of the NMDevice's "l3cd-changed" signal
is not useful, as it reports that the layer-3 configuration changed
before it is committed to platform.
In this way, the only current subscriber (NMPolicy), reacts to the
change too early: it updates the DNS servers in the system when the
interface doesn't have yet addresses and routes ready. Therefore, the
resolver (libc, systemd-resolved, ...) will try to contact the DNS
server using the wrong parameters.
Change the semantics so that the signal is emitted *after* the commit
to platform.
During a commit of layer-3 configuration, multiple signals are
emitted:
- if the combined l3cd configuration changes, we first emit a
L3CD_CHANGED signal, with flag `commited` FALSE;
- if the previously committed configuration is different from the one
we want to commit, we emit again the same signal with `commited`
TRUE;
- a PRE_COMMIT signal
- a POST_COMMIT signal
The usefulness of the first and third signals is questionable: there
is no need to signal that the configuration changes if we are not
going to commit it. Also, PRE_COMMIT is redundant as we just emitted
L3CD_CHANGED. Nobody is using those 2 signals.
Simplify this by leaving only PRE_COMMIT and POST_COMMIT, which are
always emitted during a commit and provide information on the l3cd
changes.
This commit doesn't change behavior.
Since NMSettingIPConfig is an abstract type that cannot be
instantiated, the overrides for the direct properties are defined on
the subclasses (NMSettingIP4Config and NMSettingIP6Config).
Silence the warning about using direct properties.
When performing integration tests for the IPv6-only DHCP option, we
want to test that the option is honored and that NM restarts DHCP if
the option goes away. However, the minimum wait time according to the
RFC is 5 minutes, which makes the test take long time.
Allow changing the value via the "NM_TEST_IPV6_ONLY_MIN_WAIT"
environment variable.
Add support for handling the IPv6-Only Preferred option. When enabled,
the client adds the option code to the "Parameter Request List" option
of the DHCPDISCOVER and DHCPREQUEST messages. If the server sends the
option back in the DHCPOFFER and DHCPACK, the host stops the DHCP
client for the time interval specified in the option. After the
timeout expires, DHCP is restarted.
In the next commit, a mechanism will be added to stop the DHCP plugin
and restart it without destroying the NMDhcpClient object. For this to
work, we must reset some members of the object when stopping or
starting the plugin.
Add a new "ipv4.dhcp-ipv6-only-preferred" property to control the
"IPv6-Only Preferred" DHCPv4 option (RFC 8925). The option indicates
that a host supports an IPv6-only mode and is willing to forgo
obtaining an IPv4 address if the network provides IPv6 connectivity.
Store the effective IP method computed by evaluating the profile,
checking kernel support, or querying device's method
get_ip_method_auto().
The value will be used in a next commit to enable or disable features.
NetworkManager current code will refuse to activate a connection if its
interface has no SRIOV capacity but holding a empty SRIOV settings.
This patch only valid SRIOV capacity when it is enabled(total_vfs > 0).
Resolves: https://issues.redhat.com/browse/RHEL-58397
Signed-off-by: Gris Ge <fge@redhat.com>
Add chains and rules to steer the IGMP reports to the primary member
port. This rules are adapted from the script provided by Eric Garver.
https://gitlab.com/egarver/virtual-networking/-/blob/master/mlag.sh
Fixes: e9268e3924 ('firewall: add mlag firewall utils for multi chassis link aggregation (MLAG) for bonding-slb')
from its previous location unter the users `$HOME` directory to
`$XDG_CACHE_HOME/nmcli-history`. This makes `nmcli` compliant with the
[XDG Base Directory Specification][1].
[1]: https://specifications.freedesktop.org/basedir-spec/latest/
VPN plugin factory can never fail, it always returns an object, much
like g_object_new(). If the (GUI) editor is unavailable, it might be
okay for some use cases, notably import()/export(). In such case, the
absence of GUI editor is indicated via capability flags.
nm-connection-editor (and presumably the Control Center) expects the
nm_vpn_editor_plugin_factory() to fail if the editor plugin (the thing
that goes into the *-gnome subpackage in Fedora) is not installed.
However, factory() never fails, because the plugin is checked for
existence only when get_editor() is called.
The plugins tend to exit right away after receiving the "quit" signal,
which may come before the ConnectInteractive() response went out.
This may make NM miss the response, and the error details it contains.
Let's make sure we flush the pending traffic out.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2045
When the attach_port()/detach_port() methods do not return immediately
(currently, only for OVS ports), the following situation can arise:
- nm_device_controller_attach_port() starts the attachment by sending
the command to ovsdb. Note that here we don't set
`PortInfo->port_is_attached` to TRUE yet; that happens only after
the asynchronous command returns;
- the activation of the port gets interrupted because the connection
is deleted;
- the port device enters the deactivating state, triggering function
port_state_changed()
- the function calls nm_device_controller_release_port() which checks
whether the port is already attached; since
`PortInfo->port_is_attached` is not set yet, it assumes the port
doesn't need to be detached;
- in the meantime, the ovsdb operation succeeds. As a consequence,
the kernel link is created even if the connection no longer exists.
Fix this by turning `port_is_attached` into a tri-state variable that
also tracks when the port is attaching. When it is, we need to perform
an explicit detach during deactivation.
Fixes: 9fcbc6b37d ('device: make attach_port() asynchronous')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2043
Resolves: https://issues.redhat.com/browse/RHEL-58026
