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

Issue 774831 link

Starred by 2 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug



Sign in to add a comment

Fix incorrect phy mode in hostapd_config : it leads to misreporting in wifi_perf & other tests

Project Member Reported by kirtika@chromium.org, Oct 15 2017

Issue description

hostapd_config.py in autotests has the below code snippet (see [1]). 
Tracking the git history of this snippet is a bit tricky as the file was moved around. 
I do not understand why we would want to report 11A or 11G when we are really on 11N or 11AC. The returning 11G by default somewhat makes sense given that traditionally hostapd_config inits with a default 11 G config (a CL to change that is at [2]). 

Why is this problematic? It confuses wifi developers and whoever else these test results are sent to (e.g. rf engineers). I sent the results in [3] to someone and they came back with a response that included "Another finding is that the test mode is listed as "mode11a", which seems to be a legacy rate with only 20 MHz support." 


[1] 
if self._is_11n or self.is_11ac:
  # For their own historical reasons, hostapd wants it this way.
  if self._frequency > 5000:
    return self.MODE_11A
  return self.MODE_11G
  raise error.TestFail('Invalid mode.')

[2] https://chromium-review.googlesource.com/#/c/chromiumos/third_party/autotest/+/720102/

[3]
[##] Results from the latest build on Eve 

ch044_mode11A_none_PSon_signal{perf}=-22

ch044_mode11A_none_PSon_tcp_tx_throughput{perf}=168.21+-1.35
ch044_mode11A_none_PSon_tcp_rx_throughput{perf}=248.53+-40.12

ch044_mode11A_none_PSon_udp_tx_errors{perf}=0.00+-0.00
ch044_mode11A_none_PSon_udp_tx_throughput{perf}=210.39+-1.14

ch044_mode11A_none_PSon_udp_rx_errors{perf}=0.00+-0.00
ch044_mode11A_none_PSon_udp_rx_throughput{perf}=230.06+-1.67

ch044_mode11A_none_PSoff_signal{perf}=-22

ch044_mode11A_none_PSoff_tcp_tx_throughput{perf}=180.28+-0.78
ch044_mode11A_none_PSoff_tcp_rx_throughput{perf}=271.33+-32.77

ch044_mode11A_none_PSoff_udp_tx_errors{perf}=0.00+-0.00
ch044_mode11A_none_PSoff_udp_tx_throughput{perf}=210.52+-1.30

ch044_mode11A_none_PSoff_udp_rx_errors{perf}=0.00+-0.00
ch044_mode11A_none_PSoff_udp_rx_throughput{perf}=329.95+-1.61

ch157_mode11A_none_PSon_signal{perf}=-24

ch157_mode11A_none_PSon_tcp_tx_throughput{perf}=168.23+-0.23
ch157_mode11A_none_PSon_tcp_rx_throughput{perf}=256.94+-24.61

ch157_mode11A_none_PSon_udp_tx_errors{perf}=0.00+-0.00
ch157_mode11A_none_PSon_udp_tx_throughput{perf}=210.24+-1.28

ch157_mode11A_none_PSon_udp_rx_errors{perf}=0.00+-0.00
ch157_mode11A_none_PSon_udp_rx_throughput{perf}=225.44+-0.70

ch157_mode11A_none_PSoff_signal{perf}=-24

ch157_mode11A_none_PSoff_tcp_tx_throughput{perf}=179.05+-1.33
ch157_mode11A_none_PSoff_tcp_rx_throughput{perf}=258.94+-30.15

ch157_mode11A_none_PSoff_udp_tx_errors{perf}=0.00+-0.00
ch157_mode11A_none_PSoff_udp_tx_throughput{perf}=209.67+-2.33

ch157_mode11A_none_PSoff_udp_rx_errors{perf}=0.00+-0.00
ch157_mode11A_none_PSoff_udp_rx_throughput{perf}=323.56+-0.85
 

Comment 1 by ovanieva@google.com, Jan 19 2018

Labels: Build-Toolchain
Components: OS>Systems>Network
Labels: -Build-Toolchain -M-63
Owner: briannorris@chromium.org
Status: Assigned (was: Available)
I'm fixing the labeling here, so at least perf results won't get aliased between 11A and 11AC:

https://chromium-review.googlesource.com/c/chromiumos/third_party/autotest/+/1013261

This doesn't fix the problems with configuring the packet capture mode (ht_packet_capture_mode) -- so beware any tests that think they're configuring a packet capture for VHT80 rates. For example, I see that depending on the circumstances [1], network_WiFi_SimpleConnect.wifi_check5VHT80 might try to configure the capture device for non-VHT rates, like this:

04/12 19:59:13.297 DEBUG|          ssh_host:0301| Running (ssh) '/usr/local/sbin/iw dev monitor0 set freq 5180' from '_call_run_once|run_once|start_capture|configure_raw_monitor|run|run_very_slowly'

https://pantheon.corp.google.com/storage/browser/chromeos-autotest-results/191594077-chromeos-test/chromeos15-row1-rack1-host2/network_WiFi_SimpleConnect.wifi_check5VHT80

I see the resulting pcap doesn't actually capture the data packets properly -- it mostly just captures the management frames.

This isn't immediately critical, but it would be a problem if we start relying on the packet capture file for tests in this mode.

I'll take this for now.

[1] See this code, which may or may not try to reconfigure the wiphy frequency band:

https://chromium.googlesource.com/chromiumos/third_party/autotest/+/49083c3c5a8a34595222c2009881b175b03422b8/server/site_linux_system.py#320

        # If this is the only interface on this phy, we ought to configure
        # the phy with a channel and ht_type.  Otherwise, inherit the settings
        # of the phy as they stand.
Project Member

Comment 4 by bugdroid1@chromium.org, Apr 17 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/autotest/+/860ad5164a6e1e11f4ec99a1c05ae7e021384d00

commit 860ad5164a6e1e11f4ec99a1c05ae7e021384d00
Author: Brian Norris <briannorris@chromium.org>
Date: Tue Apr 17 22:53:11 2018

network_WiFi_Perf: log VHT80 correctly in keyval results

Wifi perf results generate keys by using the hostap config's
printable_mode() method. This method didn't handle VHT80 correctly and
instead interpreted it as 11A. Add special handling for VHT.

I don't currently plumb the corresponding packet_capturer parameters,
because (a) our current 'iw' doesn't have a clear way of configuring
this (or at least, I was too lazy for this at the moment) and (b) we
should probably plumb packet capture modes (i.e., 'iw dev XXX set freq
...') differently than "printable mode" anyway.

Note that this means we probably aren't capturing
network_WiFi_SimpleConnect.wifi_check5VHT80 correctly. Fortunately,
that's the only other test that uses VHT rates, and it doesn't actually
utilize those captures for anything.

BUG=chromium:827829, chromium:774831
TEST=network_WiFi_Perf.vht80 (and others); check that the results/keyval
     file contains results like:
     ch044_modeVHT80_none_PSon_tcp_tx_throughput{perf}=191.98+-0.56
     instead of:
     ch044_mode11A_none_PSon_tcp_tx_throughput{perf}=193.73+-5.60

Change-Id: I038eeeb1a54998324458ffe9609b6ea06d4766f2
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1013261

[modify] https://crrev.com/860ad5164a6e1e11f4ec99a1c05ae7e021384d00/server/cros/network/hostap_config.py

Sign in to add a comment