Some test case sequences seemed to prevent the station from completing
the first OBSS scan (that scan was aborted) and that resulted in failing
the test case because the AP had not received any report in time. Wait
for scan completion and allow additional scans before timing out to
avoid indicating incorrect AP behavior in cases where the report was not
even received.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
It looks like these test cases can fail with the new "Undefined
secondary channel: drop OBSS scan results" case. Add more checks to
determine if something is wrong with the connection.
In addition, force clearing of the cfg80211 scan cache on the main AP
interface so that a scan result from a previous test case cannot prevent
40 MHz channel bandwidth from being used. This could apparently happen
in the following test case sequence:
ap_ht40_scan_conflict obss_scan
Signed-off-by: Jouni Malinen <j@w1.fi>
ap_ht40_5ghz_disabled_sec fails with this message.
---------------
wlan0: Country code not reset back to 00: is US
wlan0: Country code cleared back to 00
---------------
This patch fixes the issue.
Signed-off-by: Masashi Honma <masashi.honma@gmail.com>
ap_ht40_5ghz_invalid_pair fails with this message.
---------------
wlan0: Country code not reset back to 00: is US
wlan0: Country code cleared back to 00
---------------
This patch fixes the issue.
Signed-off-by: Masashi Honma <masashi.honma@gmail.com>
This is needed to avoid leaving unexpected cfg80211 regulatory country
code in place at the point when a test case terminates.
Signed-off-by: Jouni Malinen <j@w1.fi>
These test cases seemed to have copy-paste errors where
wait_enabled=False was forgotten even though there was no additional
steps checking the AP mode startup results. This did not break the
tests, but could have resulted in slowing them down if the STAs did not
find the AP in the first scan.
Signed-off-by: Jouni Malinen <j@w1.fi>
After successfully passing the 525 tests on a remote setup mark the
tests as remote compatible.
Signed-off-by: Jonathan Afek <jonathanx.afek@intel.com>
The ap_ht tests used to execute shell commands in the tests using the
subprocess python module. Complete the move to using the cmd_execute()
general function for executing shell commands so that this would also
work on remote setups.
Signed-off-by: Jonathan Afek <jonathanx.afek@intel.com>
The ap_ht tests used to execute shell commands in the tests using the
subprocess python module. Start using the cmd_execute() general function
for executing shell commands so that this would also work on remote
setups.
Signed-off-by: Jonathan Afek <jonathanx.afek@intel.com>
The ap_ht tests used to execute iw reg set command using the subprocess
python module. Start using the cmd_execute() general function for
executing shell commands so that this would also work on remote setups.
Signed-off-by: Jonathan Afek <jonathanx.afek@intel.com>
The test cases ap_ht40_5ghz_invalid_pair and ap_ht40_5ghz_disabled_sec
mixed use of apdev[0] and apdev[1] while only needing a single AP. This
works when both the devices are on the same host (e.g., with
mac80211_hwsim), but not when using separate remote hosts. Fix this by
using apdev[0] more consistently in these test cases.
Signed-off-by: Jonathan Afek <jonathanx.afek@intel.com>
Pass apdev param to hostapd.add_bss(). Kill hardcoded phy param and get
phy base on apdev. These are needed to support operation with a remote
test host.
Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com>
Pass the full apdev to the add_ap() function instead of just ifname.
This allows us to handle also remote hosts while we can check
apdev['hostname'], apdev['port'].
This step (1) converts the cases where apdev[#]['ifname'] was used as
the argument to hostapd.add_ap().
Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com>
This test case for enforcing that AP setup fails in case there is need
to fall back to 20 MHz channel due to invalid 40 MHz configuration.
Modify this to allow successful AP startup as long as 40 MHz channel
does not get enabled.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
It was possible for a cached scan entry in cfg80211 from an earlier test
case to show up while verifying that the disabled AP does not show up in
scan results. This could result in invalid test failures, e.g., when
running test cases "ap_require_ht ap_multi_bss_config" multiple times
(depends a bit on timing). Make this less likely to occur by explicitly
clearing the scan cache and by stopping wlan1 from trying to associate
before stopping ap_required_ht* test cases.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
On recent kernels, it seems that something changed (scheduler?)
that makes hwsim send the scan done event so quickly that iw isn't
scheduled back in to listen for it, causing iw to get stuck.
Work around this by using the scan trigger command (it'll be quick
enough so that we don't really need to wait) and the scan trigger
and dump commands where the results are required (and use a small
sleep there instead of waiting for the scan results.)
I'll try to fix this separately in iw later.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This verifies a case where the neighboring BSS is at the other end of
the band and has its PRI channel further away.
Signed-off-by: Jouni Malinen <j@w1.fi>
run-tests.py is running as root, so sudo does not need to be used
anymore from within each test case.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
It looks like this test case is failing every now and then, so add some
more time for the olbc_ht value to get updated before reporting a
failure.
Signed-off-by: Jouni Malinen <j@w1.fi>
Instead of returning "skip" from the test function, raise the new
HwsimSkip exception to indicate a test case was skipped.
Signed-off-by: Jouni Malinen <j@w1.fi>
ap_ht_smps needs relatively recern kernel support, so allow it to be
skipped rather than claimed as failure, in case hostapd startup fails.
Signed-off-by: Jouni Malinen <j@w1.fi>
The previous design did not actually break from the wait loop when the
AP changed back to 40 MHz channel and as such, ended up waiting the full
30 second time. Furthermore, the five second delay time for returning
back to 40 MHz was not sufficiently long to test behavior correctly
since the STA did not have any chances of returning the next coex report
before the AP had returned to 40 MHz. Increase the AP wait time to 15
seconds so that the once per 10 seconds OBSS scan from the STA gets in
before changing back to 40 MHz channel (after the 40 MHz intolerant AP
gets disabled).
Signed-off-by: Jouni Malinen <j@w1.fi>
