New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 591094 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Mar 2016
Cc:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug

Blocking:
issue 708246



Sign in to add a comment

wpa_supplicant v2.5: network_WiFi_RateControl MCS Index set to 1

Project Member Reported by grundler@chromium.org, Mar 1 2016

Issue description

Mukesh looked at the matfunc test results I generated and had this comment:
---------------------
The RateControl test has been an issue on daisy, because the Marvell chip doesn't get up to MCS 15 in the shield boxes. Marvell claims that this is an artifact of the shielded environment, and that they do use MCS 15 in real-world environments. We've never pressed them too hard on that point.

However, the failure mode that you observed is quite different from the normal failure mode. Compare:

  (normal failure) Failed to use best possible MCS index 15 in a clean RF environment: {10: 1, 11: 1700, 12: 4}
  (reported failure) Failed to use best possible MCS index 15 in a clean RF environment: {1: 379}

Using MCS 11 instead of MCS 15 means 120 Mbps max vs. 300 Mbps (both at PHY layer). That isn't great, but still faster than most home Internet connections. On the other hand, MCS 1 is max 15 Mbps.

So this failure is worth looking into.
---------------

Previous example failure of network_WiFi_RateControl:

    https://wmatrix.googleplex.com/failures/wifi_matfunc?platforms=daisy&tests=network_WiFi_RateControl&days_back=30
 
Cc: wnhuang@chromium.org ejcaruso@chromium.org jleong@chromium.org
Grant, could you attach the test logs here and I can loop in Marvell folks to help take a look also.
Julan has tracked this down. tl;dr change wpa_supplicant ebuild to disable CONFIG_LIBNL20 which doesn't like how we use it in failing case.


Here is a summary of the conversation (over email):

Tue, Mar 8, 2016 at 2:44 PM, Julan wrote:
   I looked into the logs and see below errors. It appears that shill has trouble enabling high bitrates after association. Again this is with all mesh related patches removed.
...
2016-03-08T21:29:53.918411+00:00 ERR shill[1182]: [ERROR:dbus_method_invoker.h(111)] CallMethodAndBlockWithTimeout(...): Domain=dbus, Code=fi.w1.wpa_supplicant1.UnknownError, Message=Failed to enable high rates.
...

Tue, Mar 8, 2016 at 2:54 PM Christopher Wiley wrote:
There was a bug originally about sending certain nl80211 messages that were empty to the kernel.  I think it went something like "set the mask of disabled rates to empty" but libnl or the kernel was super unhappy about an empty list.

Tue, Mar 8, 2016 at 3:03 PM Julan Hsu wrote:
OK I noticed we are using different libnl config option in the 2.5 ebuild. I can quickly try this.

Tue, Mar 8, 2016 at 3:47 PM Julan Hsu wrote:
Good news. After removing CONFIG_LIBNL20 I can see higher MCS indexes over the air.

Many thanks for the insights. When disabling high bitrates we are sending non-empty list and it went through. When enabling high bitrates we are sending empty list which makes libnl not happy and thus the failure. It all makes good sense now.

I will submit a CL to follow up.
---------------
Project Member

Comment 3 by bugdroid1@chromium.org, Mar 11 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/226425710ee8f5b677452685d2926c0f637837e5

commit 226425710ee8f5b677452685d2926c0f637837e5
Author: Julan Hsu <julanhsu@google.com>
Date: Tue Mar 08 23:57:39 2016

wpa_supplicant: do not use newer versions of libnl

libnl 2.0 does not like zero-length nl messages, causing
failures in places like nl80211_toggle_high_bitrates().
Remove the LIBNL config option to match that of exisiting
wpa_supplicant 2.3 configs.

BUG= chromium:591094 
TEST=ChromeOS clients (ie ChromeBooks):
        http://cautotest/ (and lock a $HOSTNAME from wifi_pool)
        crosflash -b $BOARD $HOSTNAME.cros
        # verify system reboots and has correct /etc/lsb-release
        ssh root@$HOSTNAME.cros
        test_that -b $BOARD $HOSTNAME.cros suite:wifi_matfunc
        # check /tmp/test_that* results have no new regressions

     ChromeOS "hosts" (ie AP Onhub)
        ../platform/ap-daemons/autotest/tools/run_lab_test.py \
                --board=whirlwind --build=$BUILD \
                suite:jetstream_sanity

pre-cq-configs: mixed-wificell-pre-cq
suite:wifi_release

Change-Id: Ib788900572a157826a5e50d4ea009815c17ecdd4
Reviewed-on: https://chromium-review.googlesource.com/331761
Commit-Ready: Grant Grundler <grundler@chromium.org>
Tested-by: Grant Grundler <grundler@chromium.org>
Reviewed-by: Grant Grundler <grundler@chromium.org>

[modify] https://crrev.com/226425710ee8f5b677452685d2926c0f637837e5/net-wireless/wpa_supplicant/wpa_supplicant-9999.ebuild

Status: Fixed (was: Started)
Blocking: 708246

Sign in to add a comment