It looks like the attempt to read the process id from a PID file can
return empty data. This resulted in kill_pid() failing to kill the
process and all the following FST test cases using the extra interface
failing. While the PID file is really supposed to have a valid PID value
when we get this far, it is better to try multiple times to avoid
failing large number of test cases.
The current os_daemonize() implementation ends up calling daemon() first
and then writing the PID file from the remaining process that is running
in the background. This leaves a short race condition where an external
process that started hostapd/wpa_supplicant could end up trying to read
the PID file before it has been written.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
It looks like it is possible for the separate started wpa_supplicant
process to remain running after a test case like fst_sta_config_default.
This would result in failures to run any following test case that uses
the wlan5 interface. Try to kill the process more thoroughly by waiting
for the PID file to show up and write more details into the logs to make
it easier to debug issues in this area.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Try to use the special build for --codecov purposes, if present, instead
of hardcoding the hostapd/wpa_supplicant binary to the default location.
This is needed to collect code coverage correctly.
Signed-off-by: Jouni Malinen <j@w1.fi>
