Kernel v4.10 and later no longer export GENL_ID_GENERATE (which was
defined as 0). iwd was using this symbol to check for unmodified local
values rather than to ask for a dynamically generated netlink ID anyway,
so it makes sense to use the value 0 directly. This will work with
kernels before and after the GENL_ID_GENERATE change.
Most likely here we want to compare the variable
not doing an assignment.
unit/test-ie.c:227:2: error: suggest parentheses around
assignment used as truth value [-Werror=parentheses]
assert(expected_len = final_len);
^~~~~~
Use netdev_reassociate if FT is not available. device_select_akm_suite
is only moved up in the file and the reused code from device_connect is
moved to a separate function.
netdev_reassociate transitions to another BSS without FT. Similar to
netdev_connect but uses reassociation instead of association and
requires and an existing connection.
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.
Make the HostapdCLI class non-static so that each objects corresponds
to a hostapd instance on one network interface (this is independent of
whether the AP instances use one or separate hostapd processes)
Communicate the final wiphy and interface configuration data after the
hostapd and iwd processes are started, to the test scripts as an
environment variable TEST_WIPHY_LIST. This way the test scripts can
know which interfaces are used by hostapd instances, which hostapd
config they're using, and which are used by iwd. The typical value will
be
rad0=wln0=hostapd,ctrl_interface=/var/run/hostapd,config=ssidOpen.conf
rad1=wln1=iwd
Handle NewLink events to detect interface mac address changes. In my
current testing I don't see nl80211 events on address change so it's
best to react to both types of events.
Pass an additional parameter to the scan results notify functions to
tell them whether the scan was successful. If it wasn't don't bother
passing an empty bss_list queue, pass NULL as bss_list. This way the
callbacks can tell whether the scan indicates there are no BSSes in
range or simply was aborted and the old scan results should be kept.
