Ah, I think this patch might be causing the issue: https://chromium-review.googlesource.com/c/chromiumos/third_party/hostap/+/1201583

From my understanding, the problem is that I currently rely on the fact that the signal levels of the two APs are fairly similar as seen from the DUT, but the client ends up preferring the second one since it's 5GHz. This was basically a hack-y way to get around the fact that we didn't have working attenuators before. The above patch tends to cause the DUT to see a stronger signal from the connected AP, so the DUT becomes more sticky (less likely to roam).

If there are attenuators up and running, we could use those in the autotest and that should fix the issue. @harpreet WDYT?

There are very few (~12) grover (RvR) setups that use programmable attenautors in the lab. Not sure if we want to limit the number of devices that these tests run on.

I see. Is there any other way we can control either the perceived signal on the side of the DUT or the tx power on the side of the AP (we've tried `iw set tx power` but that doesn't do enough)?

I'm not sure there's a good way to force perceived signal strength.

If you're trying to run on non-grover setups, you probably have to imitate one of the methods other tests are already using:

 * tear down 1 of the APs, to *really* force a change
 * send a roam command to the client (e.g., client.request_roam{,_dbus}())

I'm kind of wondering what you're really trying to get at with this test anyway. You're not actually *doing* much of anything -- you're just waiting for the device to roam on its own, with some implicit assumptions about how we treat 2G vs 5G bands. That's not really a recipe for a good test.

If you just want to see "can the client associate to 1 AP, then roam to another?", it seems like one of the above should suffice.

Is there something deeper in the FT feature that you really want to test, though?

Issue 900453 has been merged into this issue.

I've been looking into this issue and it turns out that the problem is that the BCM4345 chip supports driver-based roaming (NL80211_ATTR_ROAM_SUPPORT), and this prevents wpa_supplicant from making roaming decisions.

I'll put in a patch to exclude these devices from the autotest.

any update on this? still seeing these failures on Broadcom devices.

Waiting on reviews for this patch: https://chromium-review.googlesource.com/c/chromiumos/third_party/autotest/+/1376889

any updates? these tests are still failing.

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

commit 4d34d42aebc66b33260f543bbca11e42e846bc39
Author: Matthew Wang <matthewmwang@chromium.org>
Date: Tue Jan 08 16:26:29 2019

network_WiFi_RoamFT: add check for supplicant roaming

Some devices are failing this autotest because they support driver
based roaming. This means that the roaming decision is outside of
software control and shouldn't be tested with this autotest. Add a
check to require that the device does not support driver based
roaming.

BUG= chromium:907656 
TEST=Ran tests on chromeos15-row1-rack8-host2.cros which supports
     driver based roaming and got TestNA. Ran tests on local caroline
     and everything passed.

Change-Id: I305d0dd6d64714d1434ed7eeecb5899a3a5390d4
Reviewed-on: https://chromium-review.googlesource.com/1376889
Commit-Ready: Matthew Wang <matthewmwang@chromium.org>
Tested-by: Matthew Wang <matthewmwang@chromium.org>
Reviewed-by: Brian Norris <briannorris@chromium.org>

[modify] https://crrev.com/4d34d42aebc66b33260f543bbca11e42e846bc39/server/site_tests/network_WiFi_RoamFT/network_WiFi_RoamFT.py
[modify] https://crrev.com/4d34d42aebc66b33260f543bbca11e42e846bc39/server/site_linux_system.py

Should be "fixed."