Beacon requests can specify a scan duration, and set a flag which makes
this duration mandatory. The kernel supports both these values for scan
requests so we no longer need to reject requests which contain these.
Drivers which do not support EXT_FEATURE_SET_SCAN_DWELL will ignore the
duration value, but if duration mandatory is set we must reject the
request.
The kernel allows a scan duration and duration mandatory flag to be
set in scan requests. RRM requests can contain these values so they
have been added to scan_parameters.
Scanning with drivers which do not support EXT_FEATURE_SET_SCAN_DWELL
will not include these values in scan requests.
This test made it past the initial refactor to use HostapdCLI with the
'config' parameter. This avoids the need to iterate the hostapd map in
the actual test.
These two processes are executed per-test so they can be passed the
test name and have the logs stored only in tests that actually need
them rather than at the top level.
If a scan is requested during the middle of a connection we should
return busy instead of attempting the scan. The kernel ends up coming
back with not supported in this case, which is misleading and
difficult to debug.
The module framework was changed to call the module exit functions in
the reverse order as the init functions. This uncovered/caused known
networks to try and free the network_info structures after hotspot had
already freed them. Since known networks clean up the network_info's
anyways, we don't actually need hotspot to do any cleanup.
After changing the valgrind log to --log-fd, it appears that
the log file just gets appended, where before it was overwritten.
This makes test print out all previous tests valgrind results.
Now after printing out the valgrind info we can erase the file
for the next test.
This was a mistake in the original implementation. Since test-runner
is always run from the tools directory using --log with no directory
specified would result in many log files being put into the iwd tree.
Instead we can make --log take a required argument so its more
obvious where all the logs are going to go.
Apparently the intention was for the dependent module's name to appear
in the variable name resulting from using IWD_MODULE_DEPENDS, so the
dependencies all have unique names (apparently not critical).
Despite that PEAPv0 spec indicates that TLS tunnel needs to be torn
down after the transmission of a secure Result response, some servers
treat this TLS close alert as a failure. This patch changes the above
behavior to explicitly torn the tunnel only in the case of
authentication failure and leave it open after the success.
The previous refactoring somehow changed the 'Settings' section name
into 'General'
Fixes: ac53239109 ("doc: Split network configuration description into separate manpage")
In non-interactive mode request the managed object right away and do
not wait for the service to appear. This way client can fail right
away instead of endlessly waiting in non-interactive mode.
This test merely verifies hostapd receieved our measurement reports
and verified they were valid. Hostapd does not verify the actual
beacon report body. Really, the only way to test this is on an
actual network which makes these requests.
This module takes care of radio measurements which an AP can request.
There are many types of requests, and for now only beacon requests
are supported.
IWD will filter certain types of beacon requests that are NOT
supported:
- AP channel reports. Only single channel requests will be supported
- Autonomous measurements. Only direct requests will be supported.
IWD will not accept requets to trigger reports under certain
conditions (SNR/RSSI thresholds, etc.)
- Timed measurements. Only immediate measurements will be performed.
The accuracy for timed measurements cannot be reliably guaranteed
due to kernel scheduling/queues.
- Full reporting detail. The AP can request the STA return the full
set of IEs in a beacon. IWD does not currently save all IEs, plus
there is quite a bit of complexity involved as certain IEs get
truncated, and there are other length limitations.
There are other limitations not specific to beacon requests:
- IWD will support single measurement requests per report. Multiple
measurement request IEs can be included, but the reports will be
sent out separately.
- IWD will limit the number of requests it responds to in a given
amount of time. As it stands now this is hard coded to 2 requests
per second maximum. This will prevent DoS attacks.
- IWD will not accept any measurement requests from APs it is not
connected to, and will not accept any requests until connected.
localtime indexes month starting at zero so adding 1 gives us a folder
name with the correct month.
The year is also set as 'years since 1900', so we need to add 1900 to
the year to get the actual year.
Historically if you wanted to see output from a python test you needed
to specify -v pytests. This was also the case if IWD was started from
python.
Nearly every time I run test-runner I would specify "-v iwd,pytests"
only to get the IWD output on these specific tests.
Instead we can special case 'python3' (previously 'pytests') inside
execute_program so that turning on verbosity for 'iwd' also turns it
on for the python tests.
After the logging changes verbose IWD with valgrind did not show any IWD
output. This commit fixes this by checking the verbosity against log_name
rather than argv[0] since log_name has a special case for valgrind/iwd.
The valgrind logic in start_iwd was refactored to only use the --log-fd
option rather than using --log-file in addition to --log-fd.
For Radio Resource Management (RRM) we will need access to the currently
connected BSS as well as the last scan results in order to do certain
kinds of requested measurements.
Hostapd has a feature where you can connect to its control socket and
receive events it generates. Currently we only send commands via this
socket.
First we open the socket (/var/run/hostapd/<iface>) and send the
ATTACH command. This tells hostapd we are ready and after this any
events will be sent over this socket.
A new API, wait_for_event, was added which takes an event string and
waits for some timeout. The glib event loop has been integrated into
this, though its not technically async since we are selecting over a
socket which blocks. To mitigate this a small timeout was chosen for
each select call and then wrapped in a while loop which waits for the
full timeout.
All the processes verbose output is just written to stdout, and very
hard to parse after the test runs. Having test-runner write the
processes output to separate log files is much nicer to view after
the test runs.
A read/write file system is created which is separate and isolated
from the current FS mount (which mounts the whole host file system).
Doing this requires the user to create a folder somewhere to be used
as the mount point. This folder is where all the log files will end
up after test-runner runs.
Since test-runner must be run as root, care was taken to keep the
log files owned by the user which runs test-runner. The UID/GID
are passed to the VM, and any log files created are chown'ed back
to the user who ran test-runner.
execute_program was refactored, and both verbose and log arguments
were removed. The verbose argument was not really required since
we can do check_verbosity(argv[0]) internally. The 'log' flag was
only used along with --shell, and now the user can simply use
--log instead of dumping /tmp/iwd.log.
You can use this feature by specifying --log[=path] to test-runner.
If no path is provided the current directory will be used. Using
the --log flag will result in all processes being run with the
--verbose flag.
A new folder will be created under the --log path. The folder will
be of the name "run-<year>-<month>-<dat>-<PID>". Under this folder
you will find any global process logs. These are processes that
are only run once for ALL tests (hwsim, ifconfig, dbus etc.). There
will also be folders for specific tests that were run. Inside these
test folders will be logs of processes that are run per-test (iwd,
hostapd, python etc.).
