Kernel command line arguments were not being parsed properly, $PATH in
particular was completely screwed up and causing commands in user's
$PATH to fail
In mac80211_hwsim each radio is assigned two addresses, the second (addr
1) being used over nl80211. In SendFrame we'd hardcode the mapping of
address 0 to address 1 even though we track all the addresses in radio_info,
so instead use that data to find the radio that has given address 0. Also
if no address 0 matches what was supplied over DBus try to find a matching
address 1.
There are ways userspace can request different addresses when managing
mac80211_hwsim radios and the hardcoded mapping would become wrong.
There's a new "-Werror=format-overflow" warning in gcc 8 that detects
potential overflow or truncation with sprintf/snprintf, so the
test-runner build fails with gcc 8. Using l_strdup_printf allows the
build to succeed, and moves a few large buffers from the stack to the
heap.
If the hw.conf option 'start_iwd' is false, then iwd is started
inside the python test, which means it will not know if the
--valgrind option was passed to test runner. If this is the case
an environment variable is set so the python test knows the
option is being used.
Without this subsequent tests may be affected by hwsim not being
restarted.
Additionally in 4.13 the kernel will not use the registered hwsim
wmedium for wiphys created after the HWSIM_CMD_REGISTER call and
there's no way to re-register it without disconnecting from netlink
which is a bit of work. It's a one line fix in 4.13, I've not yet
checked if this has changed in current git.
When running multiple BSSes in one ESS this solves the communication
between them (called RRB) for purposes like preauthentication,
FT key pull and push and FT-over-DS without complicated bridges. At the
same time we're unlikely to have a scenario where we need the
communication to fail so there's no need for this to be configurable.
The supporting code for multiple hostapd processes is left in place so
that configure_hostapd_instances can decide how many processes to run
based on hw.conf and policies. start_hostapd now uses "-i wln0,..."
which is no longer documented in hostapd manual page or usage() but
still supported in current git and required if interface names are not
provided in the config files (possibly unless -b is used which is also
undocumented.)
There was an unnecessary l_strsplit call when parsing the verbose
options for test-runner. The verbose options get parsed inside
qemu already, so this call was removed.
Can now pass -V, --valgrind to test-runner to run valgrind on
iwd during autotests. Note: the verbose option for iwd must
also be passed in order to see output (-v iwd).
Added a new method SendFrame() under the radios .Interface
interface. This method takes two byte arrays as parameters,
first is the station address to send the frame to, and the
second is the raw frame data.
The following verbose options can be used:
"unit" - see output from unit tests
"kernel" - see hwsim kernel prints
"pytests" - see prints from python autotests
The existing verbose option would turn on debug logging for most
processes in the test-runner framework. This change makes the verbose
option more granular. The --verbose or -v option should now be
followed by a comma separated list of the test-runner processes you
want to see debug logging from. Currently iwd, hwsim, ofonod, and
hostapd are valid options to pass to the verbose flag e.g.
-v iwd,hwsim,ofonod,hostapd
Or any single/combination of the above applications.
A new option 'sim_keys' can be put in the SETUP group. If
sim_keys=ofono, then test-runner will attempt to start ofono
and phonesim to be used with EAP-SIM/AKA. If ofono OR phonesim
are not found the test will be skipped.
Any other value of 'sim_keys' should be a 'keys' file
e.g. /tmp/sim_keys.conf which should contain hardcoded
SIM/AKA key values.
Replace is_multicast_addr with util_is_broadcast_address usage.
is_multicast_addr seems to have been wrong, first because we're not
interested in just any multicast address (defined to be same as "group
address"), but rather specifically the broadcast address, as we don't
know of any specific address groups other than broadcast. And also
wrong because the "Individual/Group bit" is the LSB of byte 0, not the
MSB of byte 0 apparently.
Derive a floating-point interval value from integers using math rather
than integer->string->float conversion. The string technique triggered a
-Wformat-overflow warning.
Use the same machine type regardless of has_virt: q35 with accelerators
list set to kvm:tcg, this will use KVM if available and fall back to TCG
if not available so there's no point checking has_virt. We can't
reliably know if KVM is usable anyway: even if the CPU has the
virtualization extensions, the support might not be enabled in the QEMU
build or there may be no kernel module or we may be calling a different
qemu executable than the one supporting KVM.
Set CPU type to "host" if KVM available and "max" otherwise because
"host" is not supported without KVM. We actually want to emulate the
host CPU as closely as possible so that host executables can run even if
optimized for the specific CPU. "max" seems to be the new way (since
Feb only) to request "host" cpu without KVM. It seems that the idea is
for "max" to become same as "host" if KVM is enabled so at some point we
will want to switch to using "max" in both cases.
The "level=9" flag seems to have been an error, there's no CPU with
cpuid max level of 9 and I can't see the purpose of setting the cpuid
level other than the host cpu's level.
-enable-kvm is redundant with accel=kvm:tcg in current qemu.
Again I'm not able to test this patch on a cpu that would be affected
by it but I hope this fixes some situations which are currently broken
anyway.
Update check_virtualization to check for the SVM on x86, KVM supports
both VMX and SVM. Fix the clobber list of the VMX check: memory is not
clobbered while ebx and edx are (ecx is already marked as output).
I'm not able to test this patch on a cpu that would be affected by it
but I don't think test-runner has been tested on those cpus yet.
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.
The phy creation logic was a bit complex, using a hashmap to map between
phy names in the config file (e.g. rad0, rad2, etc) and interface names
created for that phy.
We take advantage of the fact that hwsim can create a radio with a given
name to simply assign the radio name from the autotest config file
directly. Then we name any interfaces created in order of phy creation.
A few extra sanity checks are also added.
Actually run hwsim in the daemon mode to work as the wireless medium now
that hwsim supports it. The current test-runner code, which assumed a
different command line syntax, wasn't functional but it didn't affect
test-runner in any way.
Don't require the full length of a Management MPDU as a condition to
forward the frame, only require data up to the three addresses we need
to know where to forward the frame.
This check was failing with some frames during a deauthentication. We
could possibly forward shorter frames too if needed (send to all
possible recipients.)
Don't handle the hwsim netlink events we use to track radios and
interfaces if we're not in daemon mode. This quiets dbus errors when
using hwsim through the command line.
The name attribute in the NEW RADIO command needs at least 4 bytes for
the attribute header (struct nlattr), all the characters of the name
string and a NUL byte, and up to 3 bytes of alignment padding.
Otherwise, depending on the name length and whether the NO_VIF attribute
was the last, that attribute could end up being dropped and we were
ending up with too many interfaces inside test-runner.
Implement a hwsim wireless medium inside hwsim.c. This doesn't do
anything to the frames it moves around yet, only tries to implement
the same logic that the kernel medium contains.
In daemon mode start a basic passive DBus interface to expose the
information on radios attached to mac80211_hwsim. In this version
interfaces have objects of their own. It might be simpler to only
show them as an array property on the radio object (array of pairs of
string, one string for address, one for name).
Read wiphy addresses from sysfs and perform the wiphy name to wiphy idx
mapping using sysfs. Do this directly on a new radio notification and
stop using new wiphy notifications except for updating the radio names.
Having the wiphy index available synchronously when parsing a new radio
event we store the wiphy index in the radio_info_rec struct directly and
drop struct wiphy_info_rec as there was a 1:1 mapping. With this, and
knowing that all radio_info data is available when new interface
notifications are received, the tracking is simplified because dbus
objects can be created and destroyed within the notification handlers.
We also now store both the wiphy hardware address data and separately
the interface MAC addresses and can use them more appropriately in the
medium implementation.
The kernel expects the radio name attribute to include the string's zero
byte. Things may still work without this if there is padding after the
attribute.
This has been now patched and the zero byte will be optional when that
patch makes its way through different trees.
Add a daemon mode that is entered when no action was specified on the
command line. In this mode hwsim tracks information on radios through
the netlink events. The interface to make use of the information is
added in the next patch.
killall doesn't wait for the iwd process to clean up, so using it is not
enough when cleaning up between tests.
Using killall -w also doesn't work since iwd is launched by the script.
By the time killall is invoked, the script process is also cleaned up.
So when iwd is killed via killall, nobody is there to reap the zombie
process (test-runner is running as init, but doesn't do this)
The easiest solution is to make the test script itself clean up any iwd
processes it launches. This is what has been implemented in the
previous patch.
Some unit tests expect to be running from the top level iwd tree
directory to load certificates and such. Make sure that test-runner
chdirs to the appropriate directory prior to running the unit tests.
