Vladimír Beneš authored Sep 20, 2021 and Vladimír Beneš committed Sep 20, 2021

 * one more dummy check added
 * when pulling hostname we might need to sleep 1 before asking again
 * change order in mac address revert

David Jaša authored Sep 20, 2021 and Vladimír Beneš committed Sep 20, 2021

On el7, connection fail because wpa_supplicant or openssl can't load
shared library despite it being registered in p11-kit, see [1] for
details. Unless this bug gets fixed, let's disable these test on el7.
https://bugzilla.redhat.com/show_bug.cgi?id=2005936

OTOH, this should work on Fedora with wifi as well as on ethernet so
let's remove the same checks over there.

Vladimír Beneš authored Sep 17, 2021 and Vladimír Beneš committed Sep 20, 2021

There were both addresses used 0 as a subnet and 255 as broadcast
 but the former is no more used in el9. Removing it too.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=94c821c74bf5fe0c25e09df5334a16f98608db90

Interface names might not be valid UTF-8. But JSON strings must be
UTF-8. iproute2 will just return invalid JSON in the case where the
interface name is not a unicode name.

We need nmci.ip to work properly also in case where we have unexpected
interface names. For that reason, there was already a fallback path that
tired to parse the text output, and not use JSON.

If we already have a non-JSON variant that MUST work, there is no point
in keeping the JSON code. Drop it and always do our manual parsing.

This also fixes the "binary=True" argument, which is supposed to return
the interface name as bytes.

David Jaša authored Sep 15, 2021 and Vladimír Beneš committed Sep 17, 2021

This step was actually used until 1cfc489c for copying of uuid of
preexisting connection for newly created one. We don't use it since then
nor there is any check of uuid in latter steps, there are no errors when
the test is run without this step so it's removal should be safe.

This effectively reverts commit 1a5da593 ('ipv4: dns: wait for nameserver
to be wriitten').

Back then, the workaround was necessary due to rh#1778798. I can no
longer reproduce that old issue, so presumably it was fixed.

Drop the workaround (by setting the wait-time to zero).

Note that this also re-enables the test for older NetworkManager, which
potentially still have the problem. I would like to see that happen, to
understand how this happens. So this change intentionally affects older
versions too, to possibly reproduce the original problem.

https://bugzilla.redhat.com/show_bug.cgi?id=1778798

- properly handle a wait-time of 0. That means, to check once and enter the
  loop, but don't wait.

- waiting for a time using time.sleep() is not good. For one, a sleep
  can be interrupted. Also, it is not always exact, so errors pile up.
  Instead, take the start timestamp, and compare it until an upper
  limit.

- the last sleep() should be with a shorter interval, to not extend
  the total wait time beyond what was requested.

Do not use /tmp for linux download, as it might be small (in RAM).

Thomas Haller authored Sep 07, 2021 and Vladimír Beneš committed Sep 07, 2021

[th/prepare_patched_netdevsim-race] fix race with @prepare_patched_netdevsim to wait for device being ready

Vladimír Beneš authored Sep 07, 2021 and Vladimír Beneš committed Sep 07, 2021

and avoid https://bugzilla.redhat.com/show_bug.cgi?id=2001818