[wifi_matfunc] Test "network_WiFi_Prefer5Ghz" fails with the following error "Wanted iw link property freq value 5240, but got 2412 instead." |
||||||||||||||||||
Issue descriptionhttps://wmatrix.googleplex.com/failures/unfiltered?suites=wifi_matfunc&tests=network_WiFi_Prefer5Ghz&days_back=30&releases=53&hide_missing=True https://wmatrix.googleplex.com/failures/unfiltered?suites=wifi_matfunc&tests=network_WiFi_Prefer5Ghz&days_back=30&releases=54&hide_missing=True Sample failure: 07/15 00:37:28.414 WARNI| test:0606| Autotest caught exception when running test: Traceback (most recent call last): File "/usr/local/autotest/client/common_lib/test.py", line 600, in _exec _call_test_function(self.execute, *p_args, **p_dargs) File "/usr/local/autotest/client/common_lib/test.py", line 804, in _call_test_function return func(*args, **dargs) File "/usr/local/autotest/client/common_lib/test.py", line 461, in execute dargs) File "/usr/local/autotest/client/common_lib/test.py", line 347, in _call_run_once_with_retry postprocess_profiled_run, args, dargs) File "/usr/local/autotest/client/common_lib/test.py", line 376, in _call_run_once self.run_once(*args, **dargs) File "/usr/local/autotest/server/site_tests/network_WiFi_Prefer5Ghz/network_WiFi_Prefer5Ghz.py", line 34, in run_once str(ap_config1.frequency)) File "/usr/local/autotest/server/cros/network/wifi_client.py", line 548, in check_iw_link_value actual_value)) TestFail: Wanted iw link property freq value 5240, but got 2412 instead. Sample logs @ https://pantheon.corp.google.com/storage/browser/chromeos-autotest-results/69503695-chromeos-test/android1758-row4-rack5-host1/debug/
,
Jul 20 2016
,
Aug 30 2016
,
Nov 8 2016
My environment has a router/AP combo with dual radio (2 GHz and 5 GHz), and a secondary AP (simple bridge config) with dual radio (2 GHz and 5 GHz). I use one SSID for 2 GHz and a different SSID for 5 GHz. When samus only has 5 GHz SSID saved, it is very unstable. My router/AP logs show samus attempting to connect to multiple APs simultaneously (or at least not properly sending a disassoc to the first AP before attempting to join the second AP), requesting DHCP renewals too frequently (sometimes every few seconds even though the least time is 3d), and declining DHCP offers. The logs and more detail are in this Google Sheets doc: https://docs.google.com/spreadsheets/d/1GZZw9L7wGwbEOGXK76VLr21d1P867XuFfQpRCEYgQ7o/edit#gid=986660636 This behavior does not occur on the 2 GHz network. I am happy to provide my MikroTik configs and/or perform any sort of debug, logging, or other troubleshooting as necessary.
,
Nov 8 2016
Per discussion with kirtika@, attached please find the config scripts used in my network. rb1_config.rsc.txt is for a MikroTik NetMetal 5 w/ an add-in 2 GHz card (router and main AP): https://routerboard.com/RB922UAGS-5HPacT-NM add-in card: https://routerboard.com/R11e-2HPnD rb2_config.rsc.txt is for a MikroTik Routerboard "hAP ac" (RB962) (secondary AP): https://routerboard.com/RB962UiGS-5HacT2HnT I have 2x more hAP ac models available for testing, and also run MikroTik RouterOS in a VM mainly for syslog and network monitoring.
,
Nov 21 2016
I'm back from traveling and ready for a debug build whenever you are. :-)
,
Jan 23 2017
This continues to fail on Cyan R57-9199.0.0
,
Mar 13 2017
,
Apr 4 2017
After running 2.4 / 5 ghz with wifi_perf 11a (channel 44) and 11b (6) , i have attached the link & fw-stats logs . Banon : Earlier giving bad reception , after orientation change in cell with wifi_perf 2.4/5 in link monitor gives -38/42db , fw-stats shows no major drop apart from minor crc error Samsus : -70db / -80db , in wifi perf2.4/5 , logs are attached , i would like to highlight the phy plcp_err which seems very high as % for both, very poor Link_Quality:32/70
,
Apr 4 2017
From the CL review link: "As discussed offline, we are going to try the following: 1. run the test against the flaky dut/cell 25 times with the cell closed and open 2. change the orientation of the flaky dut and re-run the test 25 times 3. place a different, known good (non-flaky), dut in the same cell and run the test 25 times" Debayan mentioned that that the signal levels are really low for this test. Can we grab some iwlwifi firmware stats during a failing test like so: watch -n0.5 "cat /sys/kernel/debug/iwlwifi/<pci-id>/iwlmvm/fw_rx_stats | tee -a /var/log/fw_rx_stats-log.txt" The /sys/kernel/debug/iwlwifi/<pci-id>/<iwlmvm or trans>/* files are full of interesting firmware information, feel free to include anything that seems relevant to this test. Am curious about why the signal levels are so low even after opening the door (with the door closed, one could say "multipath" and hand-wave it away). The fw_rx_stats file will provide a clue. If possible, can we do this in Chaos lab or some other quiet environment?
,
Apr 5 2017
chromeos9-row4-rack2-host1 : sentry https://wmatrix.googleplex.com/failures/wifi_matfunc?platforms=sentry&tests=network_WiFi_Prefer5Ghz&days_back=30&builds=R58-9334.28.0&releases=58&hide_missing=True It seems the multipath effect causes this.. with Ramsey door open the DUT connects to 5Ghz
,
Apr 11 2017
,
Aug 1
,
Oct 20
Cleanup/debug-logging CLs here: https://chromium-review.googlesource.com/q/topic:%22scan-and-5GHz-improv%22+(status:open%20OR%20status:merged)
,
Oct 20
,
Oct 23
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/autotest/+/0718774d302cab722d374f803294ab105d8e4c87 commit 0718774d302cab722d374f803294ab105d8e4c87 Author: Kirtika Ruchandani <kirtika@google.com> Date: Tue Oct 23 00:38:06 2018 wifi_client: Improve wait_for_bss reporting The current failure message isn't very helpful. Specify which SSID we were looking for, how many we found and how many we expected. BUG=chromium:628791 TEST=Ran network_WiFi_Prefer5Ghz locally and hit a failure with: "FAIL: Failed to discover all BSSes. Found 0, wanted 2 with SSID Prefer5Ghz_a_mf4vw_" Change-Id: Iee02a3bc8933443f33b103f5c6ee88dff11219ef Signed-off-by: Kirtika Ruchandani <kirtika@google.com> Reviewed-on: https://chromium-review.googlesource.com/1292287 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Grant Grundler <grundler@chromium.org> [modify] https://crrev.com/0718774d302cab722d374f803294ab105d8e4c87/server/cros/network/wifi_client.py
,
Oct 23
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/autotest/+/d4b598261acd42ac9780ca7b6937177dd9f45f1a commit d4b598261acd42ac9780ca7b6937177dd9f45f1a Author: Kirtika Ruchandani <kirtika@google.com> Date: Tue Oct 23 00:38:06 2018 wifi_client: Don't randomly scan with iw Scanning with iw will conflict with shill/wpa_supplicant initiated scans. Use the wifi_client helper functions to make shill let go of the wifi interface before you scan, and then restore the wifi interface with shill after you're done. BUG=chromium:628791 TEST=Ran network_WiFi_Prefer5GHz locally. Change-Id: I4517f2c2227bcf303c9412c6867692d062dc3524 Signed-off-by: Kirtika Ruchandani <kirtika@google.com> Reviewed-on: https://chromium-review.googlesource.com/1292791 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Grant Grundler <grundler@chromium.org> [modify] https://crrev.com/d4b598261acd42ac9780ca7b6937177dd9f45f1a/server/cros/network/wifi_client.py
,
Oct 23
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/autotest/+/cbb89e9a200f272aff8d11fcfab1986ed1985b4b commit cbb89e9a200f272aff8d11fcfab1986ed1985b4b Author: Kirtika Ruchandani <kirtika@google.com> Date: Tue Oct 23 00:38:11 2018 autotest: wifi: Remove WiFiInterfaceClaimContext This wrapper can be easily replaced with a try-catch-finally block. BUG=chromium:628791 TEST=Ran network_WiFi_ChannelScanDwellTime, its only consumer. Change-Id: Ieec7a6cb6a6c1840c03f0647858291988ae3023a Signed-off-by: Kirtika Ruchandani <kirtika@google.com> Reviewed-on: https://chromium-review.googlesource.com/1292792 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Brian Norris <briannorris@chromium.org> [delete] https://crrev.com/98f0f51466147b8aa7490afaf141211aa81171e5/server/cros/network/wifi_interface_claim_context.py [modify] https://crrev.com/cbb89e9a200f272aff8d11fcfab1986ed1985b4b/server/site_tests/network_WiFi_ChannelScanDwellTime/network_WiFi_ChannelScanDwellTime.py
,
Nov 1
,
Nov 2
,
Nov 2
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/autotest/+/4d0797da6084622fbbd4143a7902a62e8e654783 commit 4d0797da6084622fbbd4143a7902a62e8e654783 Author: Kirtika Ruchandani <kirtika@google.com> Date: Fri Nov 02 21:50:43 2018 network_WiFi_Prefer5GHz: Log each BSS's signal strength BUG=chromium:628791 TEST=(1) Ran network_WiFi_Prefer5GHz locally. Test passes and logs the below: 16:59:02 INFO | autoserv| Freq: 2412 Signal: -54 16:59:02 INFO | autoserv| Freq: 5180 Signal: -41 (2) Ran 10 times on chromeos15-row1-rack2-host1, a coral DUT that frequently fails this test, could not reproduce the failure case though. (3) Ran locally with tx power lowered for 5 GHz interface, and checked the failure case. Change-Id: I9454d4f370e7ff20022aa907139f608af3ea96bb Signed-off-by: Kirtika Ruchandani <kirtika@google.com> Reviewed-on: https://chromium-review.googlesource.com/1292796 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Brian Norris <briannorris@chromium.org> [modify] https://crrev.com/4d0797da6084622fbbd4143a7902a62e8e654783/server/site_tests/network_WiFi_Prefer5Ghz/network_WiFi_Prefer5Ghz.py |
||||||||||||||||||
►
Sign in to add a comment |
||||||||||||||||||
Comment 1 by sheriffbot@chromium.org
, Jul 16 2016