Found the upstream changes that remove support for setting the fragmentation threshold from drivers/net/wireless-4.2/ath/ath10k/mac.c:

https://chromium-review.googlesource.com/c/333464
https://chromium-review.googlesource.com/c/333465

Those changes claim that setting the fragmentation threshold is futile, and no known firmware supports the parameter.

I tested with those changes reverted, and then saw fragmented packets transmitted by the router, and the same failure as described in bug 597473.

Beautiful. So, I guess we should just disable this test for APs like Whirlwind? Can we figure this out dynamically [1]? It looks to me like nl80211 will actually just silently reject a wiphy configuration if the cfg80211 implementation (or in this case, the driver implementation called by mac80211) fails to "set" it.

[1] For a well-behaved driver. Obviously, the current whirlwind testbed builds are broken, as they *think* they can set the fragmentation threshold, but they can't do it right.

So far I haven't noticed any error returned that I could use to trigger an "NA" test result, but I guess we could just do that statically for a whirlwind?

One thing I'm still confused by: has this test ever succeeded with a whirlwind in the past?

> So far I haven't noticed any error returned that I could use to trigger an "NA" test result

On the currently-deployed image, it seems like there's nothing we could do. But with the latest -4.2, it seems like we could double-check the fragmentation threshold reported by the wiphy (e.g., 'iw phy') after setting it. It's still weird that AFAICT, nl80211 won't return any errors here.

> I guess we could just do that statically for a whirlwind?

Yeah, if we agree on disabling, then we should probably try something like that for now.

> One thing I'm still confused by: has this test ever succeeded with a whirlwind in the past?

I don't really know. I was going to respond on bug 597473 about that. But I'm suspecting "no". I think bug 504532 was originally a blocker for triaging wifi_matfunc errors on whirlwind ("fails consistently on whirlwind"), and it was eventually kinda hand-waved away.

Looks like this test has never been possible on a whirlwind, and won't be without a firmware change. I'll add a check using "iw phy" so that the new wireless-4.2 build will return an NA result, instead of FAIL.

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

commit d94992cf1f8a37f38b99389d3ec1745f4f24ccf2
Author: Brian Norris <briannorris@chromium.org>
Date: Wed Aug 23 02:05:12 2017

network_WiFi_RxFrag: whirlwind APs don't support fragmentation

As noted in, e.g., crosreview.com/333465, no ath10k firmware is known to
support configuring the fragmentation threshold correctly. It's extra
confusing that a packet capture run on the whirlwind will *tell* you
that it has the correct fragmentation fields, but the frames get
corrupted on their way out to the air.

We will hopefully get a better fix for this in  crbug.com/753177 , when we
can upgrade whirlwind images in the lab and autodetect support for this
feature.

BUG=chromium:597473,  chromium:753177 
TEST=network_WiFi_RxFrag on whirlwind reports TestNA

Change-Id: I0cc5278c7e42ae64fbb941d9e0d5fdaef88d31ef
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/624733
Reviewed-by: Edward Hill <ecgh@chromium.org>

[modify] https://crrev.com/d94992cf1f8a37f38b99389d3ec1745f4f24ccf2/server/site_tests/network_WiFi_RxFrag/network_WiFi_RxFrag.py

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

commit 7d41122ee9eaf8d598a10a9bb8638e3c7a81142e
Author: Edward Hill <ecgh@chromium.org>
Date: Fri Oct 06 04:24:38 2017

site_linux_router: Check router fragmentation threshold after setting it.

ath10k firmware (on whirlwind routers) doesn't support setting
fragmentation threshold so check and return TestNAError if the
setting was ignored.

BUG= chromium:753177 
TEST=network_WiFi_RxFrag (on panther, stumpy, whirlwind)

Change-Id: I71494c7382e225fed5b5bf339fb7e93cd1f86705
Reviewed-on: https://chromium-review.googlesource.com/696133
Commit-Ready: Edward Hill <ecgh@chromium.org>
Tested-by: Edward Hill <ecgh@chromium.org>
Reviewed-by: Brian Norris <briannorris@chromium.org>

[modify] https://crrev.com/7d41122ee9eaf8d598a10a9bb8638e3c7a81142e/client/common_lib/cros/network/iw_runner_unittest.py
[modify] https://crrev.com/7d41122ee9eaf8d598a10a9bb8638e3c7a81142e/server/cros/network/hostap_config.py
[modify] https://crrev.com/7d41122ee9eaf8d598a10a9bb8638e3c7a81142e/server/site_linux_router.py
[modify] https://crrev.com/7d41122ee9eaf8d598a10a9bb8638e3c7a81142e/client/common_lib/cros/network/iw_runner.py
[modify] https://crrev.com/7d41122ee9eaf8d598a10a9bb8638e3c7a81142e/server/site_tests/network_WiFi_RxFrag/network_WiFi_RxFrag.py