Output txpower extremely low

[leogx9r]

Currently, using this particular driver, the transmission power used is extremely low.

The kernel's default driver (when no regulatory domain is set), uses a default of 20 dBm (~100 mW) output txpower as reported by iwconfig.

This driver however, only transmits at an extremely low 12 dBm (~16 mW) and it cannot be modified at all even using iwconfig <dev> txpower 20dBm.

(Quick note, this card also supports overclocking beyond 20 dBm if modifying the regulatory database. Maximum I've managed to get it -- with a heatsink -- is 30 dBm or 1 W).

This low power seems to be due to the regulatory database not actually being used since modifying any REG_RULE in os_dep/linux/wifi_regd.c has no effect on the output. This decreases the overall connection quality for me in contrast to the kernel's driver.

For contrast, here's the result of a modified REG_RULE to set a default of 30 dBm output.

# iwconfig wlp4s70

wlp4s0    IEEE 802.11  ESSID:"<snip>"  
          Mode:Managed  Frequency:2.4XX GHz  Access Point: <snip>
          Bit Rate=144.4 Mb/s   Tx-Power=30 dBm   
          Retry short limit:7   RTS thr=2347 B   Fragment thr:off
          Power Management:off
          Link Quality=70/70  Signal level=-24 dBm  
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:

This may be related to why this driver performs worse in upstream tasks rather than downstream tasks.

Note: This was done on the PCIe version on a desktop so I'm able to safely increase the output by adding a moderately sized heatsink to the card.

[yavincl]

What device model are you using? I am interested in this issue, as I have a 8192ee PCI card I want to overpower.

I cannot get #iwconfig to output the transmit power, however. What I can do, is confirm that iw phy shows the maximum allowed power to be 20dBm even on a 30dBm max regulatory domain setting (BO or GY), and my device's manual (TL WN881ND) says this device only goes up to 20dBm.

[leogx9r]

Note: I'm currently using the default kernel driver that I've modified to increase the txpower via modifying the REG_RULE indicated above since thus bypassing the software limit of 20 dBm. I don't use regulatory rules -- it's unset for me. Currently running kernel 5.4.3. Tested as far back as 4.17.

The model name for Amazon: TP-Link TL-WN881ND N300 so it does seem like I have the same version as you do.

# lspci
07:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8192EE PCIe Wireless Network Adapter

Capabilities: (Note the 30 dBm output rate per channel)

# iwconfig --version     
iwconfig  Wireless-Tools version 30

# iw --version
iw version 5.4

# iw phy1 info
Wiphy phy1
    max # scan SSIDs: <snip>
    max scan IEs length: 2257 bytes
    max # sched scan SSIDs: 0
    max # match sets: 0
    max # scan plans: 1
    max scan plan interval: -1
    max scan plan iterations: 0
    RTS threshold: 2347
    Retry short limit: 7
    Retry long limit: 4
    Coverage class: 0 (up to 0m)
    Device supports RSN-IBSS.
    Supported Ciphers:
        * WEP40 (00-0f-ac:1)
        * WEP104 (00-0f-ac:5)
        * TKIP (00-0f-ac:2)
        * CCMP-128 (00-0f-ac:4)
        * CCMP-256 (00-0f-ac:10)
        * GCMP-128 (00-0f-ac:8)
        * GCMP-256 (00-0f-ac:9)
        * CMAC (00-0f-ac:6)
        * CMAC-256 (00-0f-ac:13)
        * GMAC-128 (00-0f-ac:11)
        * GMAC-256 (00-0f-ac:12)
    Available Antennas: TX 0 RX 0
    Supported interface modes:
         * IBSS
         * managed
         * AP
         * AP/VLAN
         * monitor
         * mesh point
         * P2P-client
         * P2P-GO
    Band 1:
        Capabilities: 0x186e
            HT20/HT40
            SM Power Save disabled
            RX HT20 SGI
            RX HT40 SGI
            No RX STBC
            Max AMSDU length: 7935 bytes
            DSSS/CCK HT40
        Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
        Minimum RX AMPDU time spacing: 16 usec (0x07)
        HT Max RX data rate: 300 Mbps
        HT TX/RX MCS rate indexes supported: 0-15, 32
        Bitrates (non-HT):
            * 1.0 Mbps
            * 2.0 Mbps
            * 5.5 Mbps
            * 11.0 Mbps
            * 6.0 Mbps
            * 9.0 Mbps
            * 12.0 Mbps
            * 18.0 Mbps
            * 24.0 Mbps
            * 36.0 Mbps
            * 48.0 Mbps
            * 54.0 Mbps
        Frequencies:
            * 2412 MHz [1] (30.0 dBm)
            * 2417 MHz [2] (30.0 dBm)
            * 2422 MHz [3] (30.0 dBm)
            * 2427 MHz [4] (30.0 dBm)
            * 2432 MHz [5] (30.0 dBm)
            * 2437 MHz [6] (30.0 dBm)
            * 2442 MHz [7] (30.0 dBm)
            * 2447 MHz [8] (30.0 dBm)
            * 2452 MHz [9] (30.0 dBm)
            * 2457 MHz [10] (30.0 dBm)
            * 2462 MHz [11] (30.0 dBm)
            * 2467 MHz [12] (30.0 dBm)
            * 2472 MHz [13] (30.0 dBm)
            * 2484 MHz [14] (disabled)
    Supported commands:
         * new_interface
         * set_interface
         * new_key
         * start_ap
         * new_station
         * new_mpath
         * set_mesh_config
         * set_bss
         * authenticate
         * associate
         * deauthenticate
         * disassociate
         * join_ibss
         * join_mesh
         * remain_on_channel
         * set_tx_bitrate_mask
         * frame
         * frame_wait_cancel
         * set_wiphy_netns
         * set_channel
         * set_wds_peer
         * probe_client
         * set_noack_map
         * register_beacons
         * start_p2p_device
         * set_mcast_rate
         * connect
         * disconnect
         * set_qos_map
         * set_multicast_to_unicast
    Supported TX frame types:
         * IBSS: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
         * managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
         * AP: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
         * AP/VLAN: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
         * mesh point: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
         * P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
         * P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
         * P2P-device: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
    Supported RX frame types:
         * IBSS: 0x40 0xb0 0xc0 0xd0
         * managed: 0x40 0xd0
         * AP: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
         * AP/VLAN: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
         * mesh point: 0xb0 0xc0 0xd0
         * P2P-client: 0x40 0xd0
         * P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
         * P2P-device: 0x40 0xd0
    software interface modes (can always be added):
         * AP/VLAN
         * monitor
    interface combinations are not supported
    HT Capability overrides:
         * MCS: ff ff ff ff ff ff ff ff ff ff
         * maximum A-MSDU length
         * supported channel width
         * short GI for 40 MHz
         * max A-MPDU length exponent
         * min MPDU start spacing
    Device supports TX status socket option.
    Device supports HT-IBSS.
    Device supports SAE with AUTHENTICATE command
    Device supports low priority scan.
    Device supports scan flush.
    Device supports AP scan.
    Device supports per-vif TX power setting
    Driver supports full state transitions for AP/GO clients
    Driver supports a userspace MPM
    Device supports configuring vdev MAC-addr on create.
    Supported extended features:
        * [ RRM ]: RRM
        * [ FILS_STA ]: STA FILS (Fast Initial Link Setup)
        * [ CONTROL_PORT_OVER_NL80211 ]: control port over nl80211

N.B. The highest I've even gone with active cooling is 36 dBm or 4 W but I generally keep it at 30 dBm for peace of mind since that's too heat for me.

Here's the patch I used to increase the limit. Again, do NOT use this without active cooling. The model TP-Link TL-WN881ND N300 has no heatsink at all on the chip. You will almost immediately fry it.

diff --git a/drivers/net/wireless/realtek/rtlwifi/regd.c b/drivers/net/wireless/realtek/rtlwifi/regd.c
index 6ccb5b93a595..63ff0a42bbe2 100644
--- a/drivers/net/wireless/realtek/rtlwifi/regd.c
+++ b/drivers/net/wireless/realtek/rtlwifi/regd.c
@@ -26,30 +26,30 @@ static struct country_code_to_enum_rd all_countries[] = {
  *scan on all world regulatory domains
  */
 #define RTL819x_2GHZ_CH01_11   \
-   REG_RULE(2412-10, 2462+10, 40, 0, 20, 0)
+   REG_RULE(2412-10, 2462+10, 40, 0, 36, 0)

 /*
  *We enable active scan on these a case
  *by case basis by regulatory domain
  */
 #define RTL819x_2GHZ_CH12_13   \
-   REG_RULE(2467-10, 2472+10, 40, 0, 20,\
+   REG_RULE(2467-10, 2472+10, 40, 0, 36,\
    NL80211_RRF_PASSIVE_SCAN)

 #define RTL819x_2GHZ_CH14  \
-   REG_RULE(2484-10, 2484+10, 40, 0, 20, \
+   REG_RULE(2484-10, 2484+10, 40, 0, 36, \
    NL80211_RRF_PASSIVE_SCAN | \
    NL80211_RRF_NO_OFDM)

 /* 5G chan 36 - chan 64*/
 #define RTL819x_5GHZ_5150_5350 \
-   REG_RULE(5150-10, 5350+10, 80, 0, 30, 0)
+   REG_RULE(5150-10, 5350+10, 80, 0, 36, 0)
 /* 5G chan 100 - chan 165*/
 #define RTL819x_5GHZ_5470_5850 \
-   REG_RULE(5470-10, 5850+10, 80, 0, 30, 0)
+   REG_RULE(5470-10, 5850+10, 80, 0, 36, 0)
 /* 5G chan 149 - chan 165*/
 #define RTL819x_5GHZ_5725_5850 \
-   REG_RULE(5725-10, 5850+10, 80, 0, 30, 0)
+   REG_RULE(5725-10, 5850+10, 80, 0, 36, 0)

 #define RTL819x_5GHZ_ALL   \
    (RTL819x_5GHZ_5150_5350, RTL819x_5GHZ_5470_5850)

[yavincl]

Thanks! This will work nicely for me. I have a cooler blowing on the chip, that should be enough.

[leogx9r]

You should definitely add at least a heatsink + air rather than plain air as I did smell this burning after running 30 dBm for a while on it. I personally use a 30mm heatsink for the raspberry pi that I had with some thermal tape.

[yavincl]

Just a question, why 36 and not 30 in these entries?

[leogx9r]

Just a question, why 36 and not 30 in these entries?

That's when I tested an output of 36 dBm with multiple fans on the chip with a copper heatsink to see where the card's limits are. Replace them for 30 if you want what I have.

[yavincl]

Holy crap, you're right. The heat output on this thing is crazy. I had my finger on it for less than 10 seconds on 33dBm and it was too much for me, so I unloaded the driver to stop it.

[yavincl]

Unfortunately. this does not seem to increase the uplink speed. It's still stuck at 40Mbps at 40MHz and 50Mbps at 20MHz.

[leogx9r]

Then I don't think the driver is at fault. I myself get just over 120 Mbps with 20 MHz with both this and the stock driver. Haven't tested 40 Mhz.

Parameters for the default driver:

  Parameters:
    aspm                = "0"
    debug_level         = "0"
    debug_mask          = "0"
    disable_watchdog    = "N"
    dma64               = "Y"
    fwlps               = "N"
    ips                 = "N"
    msi                 = "Y"
    swenc               = "Y"
    swlps               = "N"

This driver's parameters: rtw_iqk_fw_offload=1 rtw_en_napi=1 rtw_pci_aspm_enable=0 rtw_lps_level=0 rtw_tx_pwr_by_rate=0 rtw_tx_pwr_lmt_enable=0 rtw_bw_mode=47 rtw_tx_bw_mode=47

I'm willing to bet the decreased speed is unrelated to the driver. I myself using the stock antennas didn't get over 80 Mbps but when getting newer antenna with higher gain and moving it to a more convenient location (less restriction) get the full speed of the card now.

One thing I've experienced with this card that I haven't with others is that even if the signal strength appears strong (eg. -24 dBm), I still got MUCH lower speeds than expected unless I positioned the antennas in particular ways. Sometimes the speed would drop as low as 10-20 Mbps and other times approach 100 Mbps.

After using better antennas that can move around, I've placed it away from as many walls as before and I do get the full speed. ( Signal strength is now -20 dBm all times )

[yavincl]

Are you using it as an access point?

[leogx9r]

Ah, no I'm not. Sorry, didn't catch that.

[kimocoder]

NOTE!

iwconfig is deprecated!! Use "iw " instead, and confirm with "iw adapter info"

Our Realtek drivers at aircrack-ng would take "iwconfig anymore, only "iw" commands.

[leogx9r]

NOTE!

iwconfig is deprecated!! Use "iw " instead, and confirm with "iw adapter info"

Our Realtek drivers at aircrack-ng would take "iwconfig anymore, only "iw" commands.

Yes, this also doesn't fix the output power for the device.

# iw dev wlp4s0 info                         
Interface wlp4s0
    ifindex 8
    wdev 0x200000001
    addr <snip>
    ssid <snip>
    type managed
    wiphy 2
    txpower 12.00 dBm

[yavincl]

Oh. So that's how you check txpower.

I can confirm that even with the patch my 8192ee and 8192eu both run at 12dbm

[kimocoder]

Ok.. I'll give you the answer . in Realtek the setting is hardcoded in "os_dep/linux/ioctl_cfg80211.c"

Open the file, search for "dbm = (12);" and change it to "dbm = (20);"

Recompile, reboot and it should be "20"

[yavincl]

bruh

[yavincl]

why did they do it like that

[kimocoder]

Lots of functions in these ancient bare-metal driver is hardcoded. Nobody knows

[yavincl]

I see this int dbm is set in the function to get txpower and show it to the system. Isn't changing this just an aesthetic change?

[kimocoder]

Yes, take a look below

https://github.com/astsam/rtl8812au/pull/16/commits/9c09c7f0d2444b1fecf0fb633748af685361fbca

[leogx9r]

I see this int dbm is set in the function to get txpower and show it to the system. Isn't changing this just an aesthetic change?

Exactly. This just changes the reporting to the user without any real effect.

I can't seem to find any of the txpower setting for this driver that the default does here: drivers/net/wireless/realtek/rtlwifi/rtl8192ee/phy.c

https://github.com/torvalds/linux/blob/386403a115f95997c2715691226e11a7b5cffcfd/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/phy.c#L379-L392

Seems this driver is actually missing a large amount of things from the kernel tree's driver.

[yavincl]

Could it be that you saw an improvement in performance due to a reduction of thermal noise on the chip, after placing the heatsink on it?

[leogx9r]

Could it be that you saw an improvement in performance due to a reduction of thermal noise on the chip, after placing the heatsink on it?

No, I've tested with and without my patch to raise txpower. The heatsink has no effect in regards to performance unless the patch is used.

[yavincl]

Really? I'm not getting any changes on the readings on my phone with either your patch to the regdb or even by applying this commit https://github.com/astsam/rtl8812au/commit/9c09c7f0d2444b1fecf0fb633748af685361fbca to the driver. Am I missing something?

[yavincl]

Unrelated question, but I'm not sure what the module parameters rtw_bw_mode=47 rtw_tx_bw_mode=47 do.

[yavincl]

I am trying to implement txpower control on this driver. My attempt is here: https://github.com/yagoplx/rtl8192ee

If you have any ideas, please let me know. I imported some code from rtl8812au's people and placed it into this driver with some modifications, but changing txpower does not work yet.

[lwfinger]

You may be running into conflicts with the regulatory restrictions, or the firmware of the chip preventing you from overheating it. Beyond that, I have no suggestions.

Can the kernel driver increase the TX power? If so, you might look at the read/writes that happen when the command is issued. It gets really messy, but you should be able to see what registers are being touched.

[yavincl]

Thanks for the suggestion. However, after some experimenting I realized that this driver has indeed a way to control txpower. It's just not bound to the "higher levels" accessible by userspace tools like iw. I know this because after messing with the txpower values in the code of rtw_mp.c and its respective include/ file, I got the chip to progressively drop its real transmit power after a while. Which is weird, since I set static, low, values, which shouldn't be overheating it. I may simply have changed too much stuff and lost track of it all.

Could say I am nearing a breakthrough.

The kernel driver seems to be able to change txpower through userspace tools like iw and the change persists, as checking with iw. However it does not translate to changes in real measured transmit power, which possibly means the functionality is broken or I might be using the wrong tool. (I am using <20 (default) dBm values for testing so I don't fry my chip or trip regdb.)

[yavincl]

This line caught my attention, and it may be what I am looking for. Can you see if it does anything in the code? This file in particular strikes the eye as possibly important for this issue.

https://github.com/lwfinger/rtl8192ee/blob/ef01ae1231fedd837f605fe503a957e455e1f255/core/rtw_mp.c#L322

I also found this just now. It might be that the driver doesn't take the txpower as dBm but rather as an index, whatever it means, because it goes up to 63. If that were dBm you'd have a interplanetary power transmitter.

https://github.com/lwfinger/rtl8192ee/blob/79432698d921eb12618b87c58a73653538dc5127/os_dep/linux/ioctl_mp.c#L1746

[yavincl]

Nevermind. I did it. I figured out how to manually set txpower. One moment.

[yavincl]

THIS right here is the magic value. Oh what a relief I found it! I will no longer need to buy a new wifi adapter to make my own router be "good".

https://github.com/lwfinger/rtl8192ee/blob/79432698d921eb12618b87c58a73653538dc5127/hal/rtl8192e/rtl8192e_phycfg.c#L755

Remove the whole equation, and just replace it with a number, say

power_idx = 4;

Change it to "1" to have your device transmit at the lowest power available. Change it to "63" to have your device transmit at the highest power available.

My tests show Index=1 getting -45dBm near the antenna. And Index=63 getting -18dBm in the same place. This is the best result I have gotten so far.

Could also modify extra_bias if you fancy saving some power and keeping extra range benefits.

[yavincl]

This issue can be closed as it is addressed by https://github.com/lwfinger/rtl8192ee/pull/12.
If you want to take development of txpower control further, it would be better to create a new issue/PR tackling what you believe needs improving.

[leogx9r]

Addressed in #12