If telnetd is installed and --telnet <port> is passed on the
vm-run.sh command line, start a telnet server (directly connected
to bash, no login) inside the VM(s) to be able to look into them
when something is wrong. Use a user network in qemu with a single
host forward from the specified port for this, listening only on
'localhost'.
Please note that this provides unauthenticated access to the guest
system from anything that can open a TCP connection on the host system.
The guess system does have access to reading all files on the host that
the user account running kvm has access to (and even write access if the
default ROTAG ,readonly parameter is cleared). In other words, this
option should not be used on any multiuser systems where kvm is run
under user accounts that are not dedicated for testing purposes (i.e.,
do not have access to any files that should not be readable to
everyone).
This needs CONFIG_VIRTIO_NET=y in the guest kernel.
For parallel-vm.py, the --telnet argument specifies the base port
and each VM index (0, 1, ...) is added to it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Recently, qemu/seabios grew an annoying console/terminal reset,
which also causes my terminal to be left in a state where long
lines don't work well and less gets confused because of this.
Suppress this by suppressing all output from qemu before a new
magic string printed from inside.sh.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The hwsim's start.sh script spawns hostapd process using "sudo".
Since sudo forks a child process, $! holds the pid of sudo itself.
Fix that by storing the PID of the child process instead.
Since in VM "sudo" is replaced with a dummy script, pass an additional
argument to run-all.sh and start.sh scripts to indicate that they are
running inside a VM.
This is needed to fix ap_config_reload and ap_config_reload_file test
cases on some platforms where sudo is apparently not relaying the
signals properly.
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
We capture the dmesg that contains everything, but if a test
causes a kernel crash we will miss all logging at higher levels
like debug. Change the printk level to catch all of that too.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This reverts commit be9fe3d8af. While I
did manage to complete multiple test runs without failures, it looks
like this change increases full test run duration by about 30 seconds
when using seven VMs. The most visible reason for that seems to be in
"breaking" active scanning quite frequently with the Probe Response
frame coming out about 40 ms (or more) after the Probe Request frame
which is long enough for the station to already have left the channel.
Since this logging change is not critical, it is simplest to revert it
for now rather than make changes to huge number of test cases to allow
more scan attempts to be performed before timing out.
Signed-off-by: Jouni Malinen <j@w1.fi>
When running tests, make printk put all messages, including debug
messages, onto the serial console to go into the console file.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The script is currently limited by the maximum kernel command line
length and if that's exceeded the kernel panics at boot. Fix this by
writing the arguments to a file and reading it in the VM.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This allows automated testing of the wpa_supplicant D-Bus interface. The
instance controlling wlan0 registers with D-Bus if dbus-daemon was
started successfully. This is only used in VM testing, i.e., not when
run-tests.sh is used on the host system with D-Bus running for normal
system purposes.
Signed-off-by: Jouni Malinen <j@w1.fi>
This allows all VMs to be used at the end of a test sequence by
assigning test cases to VMs based on which VM is available for a new
test case rather than splitting the full task at the beginning and
potentially getting stuck with the last VM running long test cases for
significantly longer than another VM that gets shorter duration tests
assigned to it.
Signed-off-by: Jouni Malinen <j@w1.fi>
To test the code under the influence of time jumps, add the option
(--timewarp) to the VM tests to reset the clock all the time, which
makes the wall clock time jump speed up 20x, causing gettimeofday()
to be unreliable for timeout calculations.
Signed-hostap: Johannes Berg <johannes.berg@intel.com>
In order to handle regulatory domain requests, crda needs to be
installed on the host, but we also need to install a uevent helper in
the VM so that it gets executed (since we don't run udev).
Signed-hostap: Johannes Berg <johannes.berg@intel.com>
If there's code coverage analysis data, copy it out of the VM
to be able to analyse it later. Also add a description to the
README file about how to use it.
Signed-hostap: Johannes Berg <johannes.berg@intel.com>
In some cases, e.g., with the VM tests if the VM crashes, it
can be useful to know which tests should have run but didn't
(or didn't finish). In order to catch these more easily, add
an option to prefill the database with all tests at the very
beginning of the testing (in a new NOTRUN state) and use the
option in the VM tests.
Signed-hostap: Johannes Berg <johannes.berg@intel.com>
Create a results.db in the output directory when running
the tests in a VM. To make that easier, create the tables
in the python script if they don't exist.
Signed-hostap: Johannes Berg <johannes.berg@intel.com>
Instead of running on the host, it can be useful to run in a
VM, particularly to test kernel rather than userspace changes,
so add a few scripts that allow doing so easily.
The basic idea is that the VM kernel is the same architecture
as the host kernel, so the host's root filesystem can be used
(in read-only mode) to run everything. Only a log filesystem
is mounted read-write and will get all the test output.
The kernel console output is collected to a special 'console'
file in the logs directory and kernel crashes are detected.
Signed-hostap: Johannes Berg <johannes.berg@intel.com>
