Seems that a quite common openswitch basic configuration consist of a
one bridge, one port and one interface, all with the same interface
name. When performing such configuration in NetworkManager you need to
specify the slave-type for the ovs-interface, otherwise the master
interface specified there may match the bridge interface, resulting in
an error.
So, let's specify the slave-type for the ovs-interface, so that the
example will work also when the same interface name is specified for
both the ovs-bridge and the ovs-port.
https://bugzilla.redhat.com/show_bug.cgi?id=1638038
nmtst: initialize nmtst_get_rand() with NMTST_SEED_RAND=0
/link/bogus: OK
/link/loopback: OK
/link/internal: OK
/link/external: OK
/link/software/bridge: OK
/link/software/bond: OK
/link/software/team: NMPlatformSignalAssert: ../src/platform/tests/test-link.c:331, test_slave(): failure to accept signal [0,2] times: 'link-changed-changed' ifindex 15 (3 times received)
--- stderr ---
/builds/NetworkManager/NetworkManager/tools/run-nm-test.sh: line 264: 106682 Trace/breakpoint trap --quiet --error-exitcode= --leak-check=full --gen-suppressions=all --num-callers=100 --log-file=
The test failed. Also check the valgrind log at '/builds/NetworkManager/NetworkManager/build/src/platform/tests/test-link-linux.valgrind-log'
In file included from ./shared/systemd/sd-adapt-shared/nm-sd-adapt-shared.h:21,
from shared/systemd/src/shared/dns-domain.c:3:
./shared/nm-default.h:106:10: fatal error: config-extra.h: No such file or directory
#include "config-extra.h"
^~~~~~~~~~~~~~~~
compilation terminated.
make[1]: *** [Makefile:12933: shared/systemd/src/shared/libnm_systemd_shared_la-dns-domain.lo] Error 1
Fixes: 7d3098ff90 ('systemd: add dns-domain utils to systemd static library')
If the master is activated by user, propagate the for-user-request to
slaves activations when autoconnecting slaves, so that they can manage
slaves device as needed.
Reproducer:
ip l add eth1 type veth peer name eth2
ip l set eth1 up
ip l set eth2 up
sleep 2
echo " * Initial state"
echo " - eth1: $(nmcli -g general.state device show eth1)"
nmcli con add type ethernet ifname eth1 con-name slave-test+ master br-test slave-type bridge
nmcli con add type bridge ifname br-test con-name br-test+ connection.autoconnect-slaves yes ip4 172.25.1.1/24
nmcli con up br-test+
echo " * After user activation"
echo " - br-test: $(nmcli -g general.state device show br-test)"
echo " - eth1: $(nmcli -g general.state device show eth1)"
should give:
* Initial state
- eth1: 10 (unmanaged)
* After user activation
- br-test: 100 (connected)
- eth1: 100 (connected)
The previous code returned that the device was available when it had
only unmanaged-flags that can be overridden by user, without actually
considering the @flags argument.
Fixes: 920346a5b9 ('device: add and use overrule-unmanaged flag for nm_device_check_connection_available()')
Some linux distros (e.g., RHEL, CentOS and Fedora) ship a dispatcher
script with their dhclient package in order to run user dhclient hook
scripts also when connections are run by NetworkManager.
The scripts convert the var names in the environment to the ones
expected in the dhclient hook scripts.
This feature is currently use by cloud-init to retrieve the MS Azure
server endpoint address, which is sent in the private dhcp option 245.
We just redefined the default dhclient var names for the private options
from "unknown_xyz" to "private_xyz". In order to let current cloud-init
version to be able to retrieve the Azure server endpoint address, add
the legacy var name "unknown_245" to the dispatcher script environment.
when dhclient is used as the dhcp client in NetworkManager we expose on
D-Bus all the variables that are passed to our script file. In
particular, we use the variable names there as labels (stripping the
heading "new") taking whatever dhclient passes us.
There are few exception to this. Dhclient allows to redefine option
variable names and we use this functionality for a few dhcp options:
dhcp option code 121 --> "rfc3442_classless_static_routes"
dhcp option code 249 --> "ms_classless_static_routes"
dhcp option code 252 --> "wpad"
Note that for private dhcp options (224-254) default dhclient labels are
in the form "unknown_$OPTNUM".
When using the internal dhcp client we skip exporting on D-Bus many of
the dhcp options received from the dhcp server. We instead export almost
all of them when using the dhclient dhcp client, using the variable
names passed by dhclient itself.
Map more DHCP options to dhclient variable names in order to allow the
internal client to retrieve them easily, namely: the server identifier,
the broadcast address, the renewal time, the rebinding time and the timezone.
Note that not all the DHCP options can be exported at this time because
systemd-networkd code drops many it won't process, so we have no way to
retrieve them without changing core systemd-networkd code.
It was already exposed implicity as the expiration time: add also the
explicit option using same format of dhclient dhcp plugin.
In the meanwhile, drop the SD_DHCP_OPTION_CLIENT_IDENTIFIER as not used.
Use DEBUG logging level for the parsing result of lease file.
Moreover, use consistent labels for the dhcp options: same labels of
what is exposed on D-Bus.
The probe takes a reference to the current lease and so it must
release it upon destruction.
Signed-off-by: Beniamino Galvani <bgalvani@redhat.com>
https://github.com/nettools/n-dhcp4/pull/1
Drop nm_platform_link_get_address_as_bytes() and introduce
nmp_link_address_get_as_bytes() so that it becomes possible to obtain
also the broadcast address without an additional lookup of the link.
Add the reason to error messages to make debugging easier.
Note that n_dhcp4_client_new() also returns positive internal error
values, so we can't use nm_utils_error_set_errno().
I think that artificially slowing down DHCP is not going to make users
happier, so let's decrease it to the minimum allowed value (1 ms).
Note that also dhclient and the internal client have it disabled. From
the dhclient.conf man page:
*initial-delay* parameter sets the maximum time client can wait after
start before commencing first transmission. According to RFC2131
Section 4.4.1, client should wait a random time between startup and
the actual first trans‐ mission. Previous versions of ISC DHCP client
used to wait random time up to 5 seconds, but that was unwanted due
to impact on startup time. As such, new versions have the default
initial delay set to 0. To restore old behavior, please set
initial-delay to 5.
Add nm_sd_dns_name_to_wire_format() based on systemd utilities to
convert a name into its wire format according to RFC 1035 section
3.1. It will be used to build the content of the DHCP FQDN option.
dns-domain.c contains useful functions for manipulating DNS names.
Add it to the systemd static library we build in shared/, similarly to
what we already do for other utility files that were originally in
src/systemd/src/basic/.
In particular, avoid including linux/netdevice.h from headers. This is
not a problem on newer distros, but required for CentOS 7.6.
Signed-off-by: Tom Gundersen <teg@jklm.no>
This is inspired by the existing systemd integration, with a few differences:
* This parses the WPAD option, which systemd requested, but did not use.
* We hook into the DAD handling, only making use of the configured address
once DAD has completed successfully, and declining the lease if it fails.
There are still many areas of possible improvement. In particular, we need
to ensure the parsing of all options are compliant, as n-dhcp4 treats all
options as opaque, unlike sd-dhcp4. We probably also need to look at how
to handle failures and retries (in particular if we decline a lease).
We need to query the current MTU at client startu, as well as the hardware
broadcast address. Both these are provided by the kernel over netlink, so
it should simply be a matter of hooking that up with NM's netlink layer.
Contribution under LGPL2.0+, in addition to stated licenses.
The DHCP client is not meant to use the assigned address before DAD
has completed successfully, if enabled. And if DAD fails, the server
should be notified with a DECLINE, in order to potentially blacklist
the address.
Currently, none of the clients support this, but add the required
callbacks, and allow clients to opt in if they want.
NMDevicePPP only handles connections with the pppoe.parent property
set. match_connection() already checks this when we creating a new
device. We should also perform the same check in
check_connection_compatible().
Fixes: 6c3195931e ('core: implement activation of PPP devices')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/203
Dracut documents the BOOTIF argument to be a MAC address and so we
accept one in any of the conventions we recognize. However, the PXE boot
loaders like to prepend a "01-" to denote an ethernet hardware type.
Accept that too.
https://bugzilla.redhat.com/show_bug.cgi?id=1726240
The callback from NMSettings about adding/updating a settings comes
from a deep call-stack already. We don't know the context of it, and
we shouldn't just right away create the profile. Instead, schedule an
action to create it in an idle handler.
The function only has one caller and it should be simple enough
to perform the necessary steps right in nms_ifcfg_rh_writer_write_connection().
More functions don't (always) simplify the code.
