This is a helper/shortcut to get_ordered_networks (plural). In nearly
all the autotests we had (roughly) the same block of code:
ordered_network = get_ordered_networks()[0]
self.assertNotEqual(ordered_network, None)
self.assertEqual(ordered_network.name, "someSsid")
Rather than having to do this, we can simplify and just have a single
call to get_ordered_network, which takes the SSID. If the SSID is not
found, we raise an exception. This avoids needing both asserts since
we are guarenteed that the return is valid and the SSID matches.
This also avoids possible issues with multiple networks showing up in
the GetOrderedNetworks call. Eventually test-runner will support running
tests on real wireless hardware, so its possible we could pick up
unexpected networks in the scan.
At some point a stray ';' got added into an autotest in a section
of code that is heavily copy pasted. So in turn nearly all the autotests
have this stray ';' after list_devices (and a few in other places).
This is a temporary fix to address the recent split of
the Device interface. This patch contains a workaround that
re-enables the auto-tests while the test framework is being
reworked to satisfy the need of the new API and should not
be considered as a permanent solution.
The default behavior of NetworkObject.connect() is to wait for the
Connect dbus method to reply before returning back to the test. This
change makes it possible to connect, but not wait for a reply and
continue on with the test (by specifying wait=False). This is
specifically required to test SAE anti-clogging, where the AP needs
to have several simultaneous connections at once for the anti-clogging
logic to trigger. This change also adds Device.wait_for_connected()
which waits for the device interface State variable to be "connected".
The list_devices API has a race condition where sometimes it will
return zero or less than the expected number of devices and fail
the test. A fix is in place for when only a single devices is
expected, but some tests expect more than one device. This changes
wait_to_appear to an integer, and the caller can specify the number
of devices they expect to get back. The default stays as it was,
zero or "return cached devices".
Previously, we had to wait for an arbitrary amount of time after
iwd was started form the python scripts to make sure that the
radio objects are available on the D-bus. This patch allows to
wait inside of list_devices() method and get back a list of the
devices once they are available.
Allow passing a list of passphrases for subsequent agent requests to the
PSKAgent constructor. This also makes existing tests stricter because
a spurious agent request will not receive the same passphrase.
If --gdb is used with test-runner, all the timeouts in the
IWD class must be turned off otherwise the test will fail.
Inside test-runner, a environment variable (IWD_TEST_TIMEOUTS)
is set to either 'on' or 'off'. Then the IWD class (and any
others) can handle the timeouts accordingly. Note that this
does not turn off dbus timeouts, rather it ignores timeout
failures. This does mean that ultimately the test will most
likely fail due to a dbus timeout, but it at least gives you
unlimited debugging time.
We need to reset self._exception after _wait_for_async_op raises an
exception, otherwise _wait_for_async_op will report that exception for
every future operation (this wasn't an issue when an exception always
meant that the test was failing and objects were torn down anyway)
Sometimes iwd will take a while to register its dbus name. The python
class already waits for the name to appear on dbus if iwd is being
launched from python, do this also if iwd was already launched by the
test-runner. My use case was when running iwd under valgrind in which
case it runs slower.
Modify AsyncOpAbstract._wait_for_async_op and
IWD.wait_for_object_condition to call context.iteration() in the
blocking mode instead of calling context.pending() every 0.01s. This
gets rid of busy-waiting and also ensures that the condition is checked
after every single dbus (or other) event. This way a condition that
potentially occurs for less than 0.01s can be reliably waited for.
