Per our review of recent Wifi issues, there are several sorts of bugs that could be caught by running variations of a "stress" test, for long periods of time, and checking for major issues.

Potential stressors:

* periodic disconnect/reconnect attempts
* data traffic (e.g., iperf, netperf) -- either TCP or UDP; sometimes, flooding the interface beyond its capacity has been useful
* suspend/resume

---

Existing stress tests:

AIUI, we have tests that cover 1 (or maybe 2) of the above stressors, but we're not very good at doing the combination. e.g., the wifi_perf suite tests data traffic performance. network_WiFi_SuspendStress covers suspend/resume + reconnect.

---

Sample background:

Some of the following reproduced primarily in combination with specific APs, but some are rather generic.

https://b.corp.google.com/issues/35583150 : DUT see problems with various APs with what amounts to 'iperf -s' + 'while true; do iw mlan0 disconnect; sleep 10; done' in parallel

https://b.corp.google.com/issues/35582684#comment9 : iperf UDP flooding link + 'while true; do iw mlan0 disconnect; sleep 10; done'

Probably more (feel free to add more background).

---

Monitoring:

We should test for some (but maybe not all) of these:

* failures to reassociate (within some threshold; transient failure is OK)
* crashes
* firmware crashes (this could be covered by one of the previous 2, although FW crashes sometimes become "recoverable" when drivers know how to automatically reset/reload their firmware)
* performance? should we monitor major changes?
* excessive packet drops? this will be tough in combination with disconnect/reconnect and/or suspend/resume, but we could coordinate this still (reconnect, wait for the link to stabilize, then start measuring drops (e.g., just a ping test?))

---

There should be something in one of our regular suites (e.g., wifi_matfunc) that covers some portion of this. I see that some aspects of this are covered in network_WiFi_Chaos* tests, but it's not clear to me how often this gets run nor whether I can currently browse any actual results from this.

---

Potential approach:

1. Address anything we can with Chaos; educate the team on what currently runs (or doesn't) and improve this so it's a useful form of developer feedback. Consider adding new devices.

2. Develop (or port from network_WiFi_Chaos*) tests to run on a testbed AP (e.g., in wificell, or on dev's desks, as would run in wifi_matfunc)

Depending on the scope of #1, that may not be a requirement for this bug, except insofar as it can help inform #2.