linux-kernel - How does the rate adaptive mask work on Realtek WiFi driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 10 May 2021 16:35:35 +0800
From:   邱名碩 <ccchiu77@...il.com>
To:     Pkshih <pkshih@...ltek.com>, Andy Huang <tehuang@...ltek.com>,
        Larry.Finger@...inger.net, kuba@...nel.org, kvalo@...eaurora.org,
        Reto Schneider <reto.schneider@...qvarnagroup.com>,
        linux-wireless@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: How does the rate adaptive mask work on Realtek WiFi driver

Hi guys,
    I had a problem while verifying the ampdu tx throughput with the
rtl8xxxu driver on RTL8188CUS module. The throughput number is
relatively good, 39~42Mbps  TCP on 2.4GHz channel. However, the
retransmission rate is high, it's 15% ~ 21% with rtl8xxxu driver and
It's almost the same result with the rtl8192cu driver. I can get
averagely 7~10% retransmission rate in the same test bed with Realtek
vendor driver.

    From the air capture, I can see the rtl8xxxu driver keep sending
the aggregated frames in MCS7 and doesn't even fall back to lower MCS
index in the subsequent retries. I can only see very few retried
packets been sent with MCS0 or 6Mbps grate. On the vendor driver, I'll
see the retried ampdu packets with MCS4 after 3 retries w/o ack from
the receiver.

    From the rate mask command issued by the h2c command, I force both
the rtl8xxxu driver and vendor driver to use the same ratemask 0xfffff
(MCS 0-7 and b/g rate included) and leave the arg0 as-is (mostly 0xa0)
and I expect both drivers can do the rate adaptive thing in the same
way, but it seems to make no difference. The rtl8xxxu driver still
sends the packets with highest MCS.

    Can anyone tell me what should I expect the rate adaptive to work
with the rate mask 0xfffff and 0xf0000? Does the 0xf0000 means that it
will pick up a tx rate only between nrate MCS4 to MCS7? I need a base
line so that I can judge it's simply a rate mask problem or maybe the
h2c command is not written correctly. Please kindly suggest what I
should do next. Thanks

The rtl8188cus vendor driver I tested is here (It can be compiled with
kernel 5.12+)
https://github.com/mschiu77/rtl8188cus_vendor/

Chris