| commit | c272896939abdb97c686df48345c7d6651337736 | [log] [tgz] |
|---|---|---|
| author | Wade Guthrie <wdg@chromium.org> | Wed Jul 10 09:32:16 2013 -0700 |
| committer | chrome-internal-fetch <chrome-internal-fetch@google.com> | Fri Oct 25 23:15:34 2013 +0000 |
| tree | 5f81945d1122ce046a25aab4f89acf306e2a2cbb | |
| parent | a283e4e59a4b4cefaf9fa1fa40e0dc5ae3647d1f [diff] |
shill: Fixes disconnect UMA stat To determine the kernel's disconnect notification behaviour for these UMA stats, I originally reverse-engineered the disconnect netlink messages that we get from the kernel (should have looked at the kernel code which, eventually, I did). I found, erroneously, that all of the disconnect reasons were found in the disassociate message. It turns out that the disconnect reasons are from the disassociate message only for (some!) disconnections instigated by the station. When the AP is the source of the disconnect, the reason is stored in a disconnect message. This code, then, extracts the reason code from whatever message type (disconnect or disassociate) that contains one. The message will still be a little noisy since some station-started disconnections don't provide a disassociate message and I've noticed that some AP-started disconnections seem to send 2 messages. I haven't tracked any of this down. BUG=chromium:215808 TEST=unittest (new) and manual - I test using the AP and description found in chromium:294315. CQ-DEPEND=Icf79aa729b1ed125743686c4536fe1b59183fed2 Change-Id: If648d530c613f485c074acf58ddb0bca4de22084 Reviewed-on: https://chromium-review.googlesource.com/170926 Reviewed-by: Wade Guthrie <wdg@chromium.org> Commit-Queue: Wade Guthrie <wdg@chromium.org> Tested-by: Wade Guthrie <wdg@chromium.org>