Since we don't catch all hwsim attribute types in unicast_handler
you see tons of "Unknown attribute type: X" prints. Since this is
not an error, we should only print if the attribute does not exist
in the attribute list.
CONFIG_DRIVER_NL80211 isn't an option for the kernel. Maybe it was
mistakenly added based on the hostap configuration instructions in
doc/test-runner.txt
If the intent was to add CONFIG_CFG80211 and CONFIG_MAC80211, they're
already in the relevant kernel defconfigs.
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.
