Related to this bug, I began looking at test network_WiFi_LowInitialBitrates (hoping it would help validate changes for this bug), and found this whole mechanism to be basically useless for my Eve: 


1. I updated the nl80211_toggle_high_bitrates function to use a larger set of
rates for "high bitrates disabled case", changing the set to be 8 values instead of 5, adding 36Mbps, 48 Mbps and 54 Mbps. 


	if (disabled) {
		wpa_printf(MSG_DEBUG, "nl80211: Disabling high bitrates");
		return nl80211_set_allowed_rates(drv, ifindex,
						 "\x02\x04\x0b\x0c\x16\x24\x30"
						 "\x36", 8,
						 "\x0c\x12\x18", 3,
						 "\x00\x01", 2,
						 "\x00\x01", 2);
	}

I then ran network_WiFi_LowInitialBitrates with eve next to the whirlwind,
and found that the DHCP frames were sent at 1 Mbps for ch6 and 6 Mbps for ch44. 

21:20:17 INFO | autoserv| Frame at 21:20:02.125667 was sent 1.000000 Mbps.
21:20:17 INFO | autoserv| Frame at 21:20:02.143140 was sent 1.000000 Mbps.
21:20:17 INFO | autoserv| Frame at 21:20:02.201556 was sent 1.000000 Mbps.
21:20:17 INFO | autoserv| Frame at 21:20:02.208658 was sent 1.000000 Mbps.
21:20:17 INFO | autoserv| Frame at 21:20:02.450440 was sent 1.000000 Mbps.
21:20:17 INFO | autoserv| Frame at 21:20:02.454231 was sent 1.000000 Mbps.
21:20:17 INFO | autoserv| Frame at 21:20:02.871756 was sent 1.000000 Mbps.
21:20:17 INFO | autoserv| Frame at 21:20:02.875664 was sent 1.000000 Mbps.
21:20:17 INFO | autoserv| Frame at 21:20:02.883858 was sent 1.000000 Mbps.
21:20:17 INFO | autoserv| Frame at 21:20:02.887874 was sent 1.000000 Mbps.
21:20:20 INFO | autoserv| Greenfield flag is ignored for hostap...
21:20:20 INFO | autoserv| Not enforcing pure N mode because Snow does not seem to support it...
21:20:20 INFO | autoserv| Starting hostapd on managed2(phy1) channel=44...
21:20:20 INFO | autoserv| Waiting for hostapd to startup.
21:20:23 INFO | autoserv| Beacon footer file does not exist.  Ignoring.
21:20:23 INFO | autoserv| Starting up local server...
21:20:23 INFO | autoserv| AP configured.
21:20:24 INFO | autoserv| Connecting to LowInitialBitrates_b_bx85l_ch44.
21:20:26 INFO | autoserv| Finished connection attempt to LowInitialBitrates_b_bx85l_ch44 with times: discovery=1.32, association=0.21, configuration=0.00.
21:20:26 INFO | autoserv| Connected successfully to LowInitialBitrates_b_bx85l_ch44, signal level: -18.
21:20:26 INFO | autoserv| Pinging from the client.
21:20:35 INFO | autoserv| Ping successful.
21:20:38 INFO | autoserv| Analyzing packet capture...
21:20:39 INFO | autoserv| Parsing frames
21:20:40 INFO | autoserv| Parsing frames
21:20:40 INFO | autoserv| Frame at 21:20:25.834650 was sent 6.000000 Mbps.
21:20:40 INFO | autoserv| Frame at 21:20:25.840390 was sent 6.000000 Mbps.
21:20:40 INFO | autoserv| Frame at 21:20:25.874761 was sent 6.000000 Mbps.
21:20:40 INFO | autoserv| Frame at 21:20:25.875544 was sent 6.000000 Mbps.
21:20:40 INFO | autoserv| Frame at 21:20:25.892673 was sent 6.000000 Mbps.
21:20:40 INFO | autoserv| Frame at 21:20:25.893602 was sent 6.000000 Mbps.
21:20:40 INFO | autoserv| Frame at 21:20:25.899393 was sent 6.000000 Mbps.
21:20:40 INFO | autoserv| Frame at 21:20:25.900274 was sent 6.000000 Mbps.

The original author of this test warned about this - we do not control what
rates the AP and DUT may negotiate - in this case, 6 Mbps isn't even in the supported list of rates? 


2. Next, I made the whole "toggle b/w high and low bitrates" a no-op,
commenting out nl80211_toggle_high_bitrates. Still saw 1Mbps and 6 Mbps
rates for DHCP on ch6 and ch44 respectively, while running network_WiFi_LowInitialBitrates. 

static int nl80211_toggle_high_bitrates(struct wpa_driver_nl80211_data *drv,
					int ifindex, int disabled)
{
	/*
	 * Allow only legacy bitrates less than 12 Mbps and the two slowest MCS
	 * rates for outgoing traffic.
	 */
	// if (disabled) {
	// 	wpa_printf(MSG_DEBUG, "nl80211: Disabling high bitrates");
	// 	return nl80211_set_allowed_rates(drv, ifindex,
	// 					 "\x16\x24\x30"
	// 					 "\x36", 4,
	// 					 "\x0c\x12\x18", 3,
	// 					 "\x00\x01", 2,
	// 					 "\x00\x01", 2);
	// }

	// wpa_printf(MSG_DEBUG, "nl80211: Enabling high bitrates");
	// return nl80211_set_allowed_rates(drv, ifindex, NULL, 0, NULL, 0,
	//				 NULL, 0, NULL, 0);
	return 0;
}


3. Looking at stainless/, the only failures for this test are on veyron family
(brcm chip?), where DHCP packets are being exchanged at 54 Mbps or one of the MCS rates 

https://stainless.corp.google.com/search?exclude_retried=true&first_date=2018-09-16&master_builder_name=&builder_name_number=&shard=&exclude_acts=true&builder_name=&master_builder_name_number=&owner=&retry=&exclude_cts=true&exclude_non_production=false&hostname=&board=&test=%5Enetwork%5C_WiFi%5C_LowInitialBitrates%24&suite=&build=%5ER71%5C-11073%5C.0%5C.0%24&status=FAIL&status=ERROR&status=ABORT&reason=&waterfall=&exclude_not_run=false&last_date=2018-09-22&exclude_non_release=true&exclude_au=true&model=&view=list&board_model=%5Eenguarde%5C%2Fenguarde%24
https://stainless.corp.google.com/search?exclude_retried=true&first_date=2018-09-16&master_builder_name=&builder_name_number=&shard=&exclude_acts=true&builder_name=&master_builder_name_number=&owner=&retry=&exclude_cts=true&exclude_non_production=false&hostname=&board=&test=%5Enetwork%5C_WiFi%5C_LowInitialBitrates%24&suite=&build=%5ER71%5C-11078%5C.0%5C.0%24&status=FAIL&status=ERROR&status=ABORT&reason=&waterfall=&exclude_not_run=false&last_date=2018-09-22&exclude_non_release=true&exclude_au=true&model=&view=list&board_model=%5Enyan_kitty%5C%2Fnyan_kitty%24
https://stainless.corp.google.com/search?exclude_retried=true&first_date=2018-09-16&master_builder_name=&builder_name_number=&shard=&exclude_acts=true&builder_name=&master_builder_name_number=&owner=&retry=&exclude_cts=true&exclude_non_production=false&hostname=&board=&test=%5Enetwork%5C_WiFi%5C_LowInitialBitrates%24&suite=&build=%5ER71%5C-11082%5C.0%5C.0%24&status=FAIL&status=ERROR&status=ABORT&reason=&waterfall=&exclude_not_run=false&last_date=2018-09-22&exclude_non_release=true&exclude_au=true&model=&view=list&board_model=%5Edaisy_skate%5C%2Fdaisy_skate%24

The Intel chip failures (enguarde/clapper) are unrelated issues ("No such procees"). 
Sample failure string on veyron family: "Frame at 11:59:23.221088 was sent at 54.000000 Mbps."

This issue has an owner, a component and a priority, but is still listed as untriaged or unconfirmed. By definition, this bug is triaged. Changing status to "assigned". Please reach out to me if you disagree with how I've done this.