| b8812f4046b5eb0fb9624b007be21ac674767633 |
|
22-Apr-2016 |
Bindu Mahadev <bmahadev@google.com> |
[autotest]Support for packet capturing using a second AP.
Currently the wifi test context manager only deals with a single
router that also acts as the packet capturer. With the new-style
wifi cells with whirwlind, packet capturer is a separate entity.
Added a new member to the context manger 'pcap_host'. 'pcap_host'
plays the role of exclusive packet capturing on a dedicated AP.
The wifi_test_context_manger sets the capture host to the second AP
if preset or it defaults to the router. It is transparent to the
test, which of the APs is being used for packet capturing.
While here, also changed the commmand line option to enable packet
capturing while abstracting away the details of router vs. dedicated AP.
CMDLINE_PACKET_CAPTURES = 'packet_capture'
BUG=chromium:601238
TEST=Simple connect/matfunc
Change-Id: I58f76ea5e99e700b29c87359fc18345c5db435e8
Reviewed-on: https://chromium-review.googlesource.com/340270
Commit-Ready: Bindu Mahadev <bmahadev@chromium.org>
Commit-Ready: Kris Rambish <krisr@chromium.org>
Tested-by: Bindu Mahadev <bmahadev@chromium.org>
Reviewed-by: Bindu Mahadev <bmahadev@chromium.org>
Reviewed-by: Kris Rambish <krisr@chromium.org>
/external/autotest/server/site_tests/network_WiFi_RegDomain/network_WiFi_RegDomain.py
|
| e5d6f93b2dd5a6726e4411d9450361977a0516b8 |
|
24-Sep-2015 |
mukesh agrawal <quiche@chromium.org> |
autotest: WiFi_RegDomain: don't use CaptureResult.pcap_path
We want to remove the |pcap_path| field from CaptureResult, so
network_WiFi_RegDomain needs to stop using |pcap_path|.
As it turns out, the way that RegDomain was using pcap_path
was rather unnecessary. In fact, stop_capture() will copy
the file over for us automatically.
A small side-effect of this change is that the pcap for the
scan phase will no longer be in the debug/ subdirectory.
However, that's a good thing. Instead of being in debug/,
the scan phase's pcap file will be in the same directory
as the pcap files for the other phases.
BUG=chromium:535362
TEST=network_WiFi_RegDomain (bcm435x, ca.hybird, ch 52+164)
Change-Id: I5674325501e8fa39da94aa9487a371a34716c306
Reviewed-on: https://chromium-review.googlesource.com/302221
Commit-Ready: mukesh agrawal <quiche@chromium.org>
Tested-by: mukesh agrawal <quiche@chromium.org>
Reviewed-by: Paul Stewart <pstew@chromium.org>
/external/autotest/server/site_tests/network_WiFi_RegDomain/network_WiFi_RegDomain.py
|
| 7fd4d0978ffd79db21e9c21e236a1a8b8c3594a4 |
|
29-Jun-2015 |
mukesh agrawal <quiche@chromium.org> |
autotest (wifi): reduce flake in RegDomain test
The network_WiFi_RegDomain test reboots the router, to ensure that
there's no stray processes running from a previous test.
Unfortunately, rebooting the router doesn't exactly get the router
back into the expected state. In particular, in the normal case,
LinuxSystem.__init__() normally removes any existing WiFi DEVs
on the system. But rebooting the system restores those DEVs. These
DEVs confuse network_WiFi_RegDomain, which assumes that it is
safe to create and configure a monitor DEV, on any PHY of its
choice.
To solve this problem, this CL moves the reboot implementation
from network_WiFi_RegDomain, into LinuxRouter and LinuxSystem.
In these classes, the reboot() method takes responsibility for
ensuring the {router,system} is in a good state after the reboot.
To meet this responsibility, we split the bulk of {LinuxRouter,
LinuxSystem} initialization code into a __setup() method. This
new method is called both, by __init__(), and by reboot(). We
use a double-underscore method, to ensure that calls from
LinuxSystem invoke LinuxSystem's setup code, rather than the
setup code for LinuxRouter.
BUG=chromium:500016
TEST=network_WiFi_RegDomain
Change-Id: I571b6bf0dff413155246765db90a145faf989255
Reviewed-on: https://chromium-review.googlesource.com/282582
Tested-by: mukesh agrawal <quiche@chromium.org>
Trybot-Ready: mukesh agrawal <quiche@chromium.org>
Reviewed-by: Christopher Wiley <wiley@chromium.org>
Commit-Queue: mukesh agrawal <quiche@chromium.org>
/external/autotest/server/site_tests/network_WiFi_RegDomain/network_WiFi_RegDomain.py
|
| 359ec50885ed80bf51c481622f2062db2a7b89b0 |
|
07-May-2015 |
mukesh agrawal <quiche@chromium.org> |
network_WiFi_RegDomain: test connection to hidden networks
Add testing of hidden networks to network_WiFi_RegDomain.
In particular, check that connecting to a hidden network
succeeds or fails just as connecting to a visible network
does.
The reason for testing hidden networks specifically is that
they exercise an additional code path in wireless core
regulatory code.
Namely: in a passive-scanning situation, we will initially
be unable to probe for a hidden network. But once we've seen
beacons from an AP (including beacons with the broadcast SSID,
from an AP running a hidden SSID), we remove the passive
scanning restriction. [1]
Note: given the above, we could limit the hidden SSID testing
to just those cases where a channel is configured for passive
scanning. For now, though, we optimize for similicity, rather
than run time.
While there: add a |description| argument to
WiFiTestContextManager.assert_connect_wifi(), so that we
can disambiguate similar connections in log files.
[1] https://wireless.wiki.kernel.org/en/developers/regulatory/processing_rules
BUG=chromium:485204
TEST=network_WiFi_RegDomain (on candy)
Change-Id: Ib56ca34b087aa91d23e4470cb63d68b897b559ab
Reviewed-on: https://chromium-review.googlesource.com/269972
Trybot-Ready: mukesh agrawal <quiche@chromium.org>
Tested-by: mukesh agrawal <quiche@chromium.org>
Reviewed-by: Zeping Qiu <zqiu@chromium.org>
Commit-Queue: mukesh agrawal <quiche@chromium.org>
/external/autotest/server/site_tests/network_WiFi_RegDomain/network_WiFi_RegDomain.py
|
| c34b59565075604d6815fc2f8a8dc20c93c4bd02 |
|
01-May-2015 |
mukesh agrawal <quiche@chromium.org> |
network_WiFi_RegDomain: add support for intel wp2
Add expectations for regulatory behavior with the intel wp2
part. The new expectations reflect the behavior observed with
the candy board.
While there: improve diagnostics for phy config checking. In
particular, output all mismatched phy configs in one go. This
makes it easier to add expectations for a new WiFi chip.
BUG=chromium:477732
TEST=network_WiFi_RegDomain
Change-Id: Ib24c0b7f4fa7574a8b5938e52513d64b3d371cbc
Reviewed-on: https://chromium-review.googlesource.com/268855
Trybot-Ready: mukesh agrawal <quiche@chromium.org>
Tested-by: mukesh agrawal <quiche@chromium.org>
Reviewed-by: Zeping Qiu <zqiu@chromium.org>
Commit-Queue: mukesh agrawal <quiche@chromium.org>
/external/autotest/server/site_tests/network_WiFi_RegDomain/network_WiFi_RegDomain.py
|
| d5433e542c31b511b6e95138e150d3df90090379 |
|
28-Apr-2015 |
mukesh agrawal <quiche@chromium.org> |
autotest (wifi): get network_WiFi_RegDomain running on ath9k
Add support for running network_WiFi_RegDomain on ath9k, and
add expectations based on observed behavior on a peppy.
While there:
- add auto-detect logic, to determine which wifi chip our
test is running against
- add some more expectations for bcm4354/4356
- add verification that the DUT has accepted the country
code we attempted to configure
- add verification that the PHYs are configured as we expect
- add testing of scan behavior
- reboot AP at start of test, to ensure that the AP isn't
sending any frames (e.g. beacons) that might affect the
DUT's regulatory behavior.
BUG=chromium:477731
TEST=network_WiFi_RegDomain (on ath9k, PASSED 10/10)
TEST=network_WiFi_RegDomain (on bcm4354, PASSED 9/10)
CQ-DEPEND=CL:267340
Change-Id: Id0cc6ce627b05e6b8a9cd281e8aebd7615144cc7
Reviewed-on: https://chromium-review.googlesource.com/267577
Reviewed-by: Paul Stewart <pstew@chromium.org>
Tested-by: mukesh agrawal <quiche@chromium.org>
Commit-Queue: mukesh agrawal <quiche@chromium.org>
/external/autotest/server/site_tests/network_WiFi_RegDomain/network_WiFi_RegDomain.py
|
| d8d4923a6aaf87445bdff3ad658809bd5a4e87c9 |
|
10-Apr-2015 |
mukesh agrawal <quiche@chromium.org> |
autotest (wifi): add regulatory domain test
Different devices vary in how they they handle regulatory
configuration. To help keep on top of that, add a new test.
This test verifies that the system can use VPD data to
inform the WiFi device about which country's regulatory rules
may apply.
BUG=chromium:470145
TEST=network_WiFi_RegDomain
Change-Id: Ia1fa14197e091c0cde97989845656ab4011f5359
Reviewed-on: https://chromium-review.googlesource.com/265764
Reviewed-by: mukesh agrawal <quiche@chromium.org>
Commit-Queue: mukesh agrawal <quiche@chromium.org>
Tested-by: mukesh agrawal <quiche@chromium.org>
/external/autotest/server/site_tests/network_WiFi_RegDomain/network_WiFi_RegDomain.py
|