shill: track the CurrentBSS property reported by wpa_supplicant,
and use it to update WiFiService state.
BUG=chromium-os:22850
TEST=new unit tests, autotests (details below)
Ran the WiFiRoaming suite, and noted the following changes:
- 000ChannelHopBSS regressed. This is due to the fact that we
now call RemoveNetwork when supplicant gives up on connecting
to a network. With this in place, we need other mechansism
to retry the connection. (They will come in later commits.)
- 006BeaconLoss now passes.
- 008Prefer5GHz regressed. This failed because we don't group
Endpoints into Services. I suspect the previous pass was a
fluke.
- 009ConnectOnResume passes, even though it should fail until
we provide retry mechanisms. Logs indicate that supplicant's
AP scan didn't time out as soon as it should have.
Bonus changes:
- Updated some TESTING and HACKING info.
- Added some comments TODOs about timing out connection
attempts. These aren't strictly part of CurrentBSS
tracking, but they fit along the theme of getting our
wpa_supplicant interactions sorted out.
Change-Id: Iba3495cae89ca835523dbf4d9ebfab5da4a8cc2d
Reviewed-on: https://gerrit.chromium.org/gerrit/11822
Tested-by: mukesh agrawal <quiche@chromium.org>
Reviewed-by: Paul Stewart <pstew@chromium.org>
Commit-Ready: mukesh agrawal <quiche@chromium.org>
diff --git a/wifi_endpoint.cc b/wifi_endpoint.cc
index 3791bdc..cd574e8 100644
--- a/wifi_endpoint.cc
+++ b/wifi_endpoint.cc
@@ -30,7 +30,8 @@
properties.find(wpa_supplicant::kBSSPropertyBSSID)->second.
operator std::vector<uint8_t>();
signal_strength_ =
- properties.find(wpa_supplicant::kBSSPropertySignal)->second;
+ properties.find(wpa_supplicant::kBSSPropertySignal)->second.
+ reader().get_int16();
network_mode_ = ParseMode(
properties.find(wpa_supplicant::kBSSPropertyMode)->second);
security_mode_ = ParseSecurity(properties);