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.
