> zmarcus@ found a kefka in pool:wificell that was showing SISO rates in `iw wlan0 station dump` on both AP (managed0) and DUT (wlan0) sides while running VHT80 perf tests. 

Would probably be good to get something like this into our test framework someday, if we don't already have a bug open for that...

> Augment network_WiFi_VerifyRouter to add a check for good MIMO rates and similar signal on both antenna.

SGTM, although I'm not sure exactly when that test is run, and for which type of cells. It's not in a suite, so presumably technicians are using this manually.

To Brian's question, this test is run by lab techs on every new setup as well as when changes are made to the existing setup.

Would techs run it on the grover cells? Would it be bad to check for signal levels if we don't also program the attenuator ourselves?

Yes they will. The attenuator reset to 0db attenuation by default when a test is kicked off so checking for signal levels should not be an issue on grover setups.

See this for another reason to do $subject. We're "passing" on some radios that are clearly not good enough:

https://bugs.chromium.org/p/chromium/issues/detail?id=870042#c2

There are some related thoughts here:

https://chromium-review.googlesource.com/c/chromiumos/third_party/autotest/+/1162968/2

and here:

https://www.mail-archive.com/ath10k@lists.infradead.org/msg08946.html
Re: ath10k: antenna bitmask support?

ath10k doesn't necessarily support arbitrary antenna bitmask configurations [1], so our existing approach of turning on various combinations of 1 or 2 antennas isn't necessarily going to work. An alternative possibility is to just watch the per-antenna RSSI stats on both the client and AP.

Note that some drivers don't support per-chain RSSI; for ath10k (on Gale and Whirlwind), we'd need to backport stuff like this:

commit 8241253d03fe9098e98315a4d66027ae31ab65c5
Author: Norik Dzhandzhapanyan <nor...@gmail.com>
Date:   Mon Jun 12 18:03:34 2017 +0300

    ath10k: add per chain RSSI reporting


[1] There are some claims of deficiencies in the ath10k firmware rate control algorithms, even if things appear to work. And at the moment, Gale crashes if you use an unsupported config. This may or may not be a bug that we can get fixed.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/autotest/+/56964636c685c06b68d85fe91b731d5b6bcaa108

commit 56964636c685c06b68d85fe91b731d5b6bcaa108
Author: Brian Norris <briannorris@chromium.org>
Date: Thu Aug 23 14:37:13 2018

[autotest] network_WiFi_VerifyRouter: reject low signal strength

Add an additional sanity check, so we can detect miswired conductive
Wifi cells.

BUG=chromium:845755
TEST=network_WiFi_VerifyRouter, on whirlwind and stumpy machines in the
     lab

Change-Id: I3099a0527c77037a5354509b8a9122986f2a8b9b
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1184162
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Harpreet Grewal <harpreet@chromium.org>
Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org>

[modify] https://crrev.com/56964636c685c06b68d85fe91b731d5b6bcaa108/server/site_tests/network_WiFi_VerifyRouter/network_WiFi_VerifyRouter.py

Another note, since I was investigating this elsewhere: the new per-antenna signal strength stuff [1] is only supported on a few drivers. It was added to ath10k in v4.13, and it was only recently implemented on brcmfmac. It's still not supported for mwifiex. It was added for iwlwifi in v3.12:

226eb8cd22b6 iwlwifi: mvm: report per-chain signal to mac80211

[1] NL80211_STA_INFO_CHAIN_SIGNAL_AVG / @NL80211_STA_INFO_CHAIN_SIGNAL