Bug 206363

Summary: PROBLEM: mt76: setting txpower with iw doesn't change the txpower of the interface
Product: Drivers Reporter: mbcm
Component: network-wirelessAssignee: drivers_network-wireless (drivers_network-wireless)
Status: NEW ---    
Severity: normal CC: daniel, jbr439
Priority: P1    
Hardware: Mips32   
OS: Linux   
Kernel Version: 4.14.162 Subsystem:
Regression: No Bisected commit-id:
Attachments: The content of /proc/ files and the kernel configs.

Description mbcm 2020-01-30 19:36:38 UTC
Created attachment 287035 [details]
The content of /proc/ files and the kernel configs.

Note 1: This message is written with markdown syntax.
Note 2: The content of /proc/ files and the kernel configs are attached in a zip file because I can only attach one file. Pasting it here would make it impossible to read.

## Decription of the problem:

Open Wrt is a distribution focused on home routers. Multiple users have reported[1] weak 2.4 GHz signal on the TP-Link Archer C50 v4 (EU, CA) and v5 (US).

Internally this router uses the MediaTek MT7628A.

I'm at 1 meter(3 feet) and in a straight line from the router. The signal strength is at 70%~80% (16 dBm). At distances larger than 3 meters (9 feet) other devices can't find the access point.

In trying to solve the problem[2] I attempted to change the txpower of the interface with:

```
~# iw dev wlan0 set txpower fixed 2000
~# iw phy phy0 set txpower fixed 2000
```

Those commands do not return any error and return 0 to the shell. Yet the transmission power of the interface remains unchanged (1.0 dBm):

```
~# iw dev wlan0 info
Interface wlan0
         ifindex 12
        wdev 0x2
        addr 68:ff:7b:aa:39:79
        ssid barroscorreia2
        type AP
        wiphy 0
        channel 11 (2462 MHz), width: 20 MHz, center1: 2462 MHz                
        txpower 1.00 dBm
        multicast TXQ:
                qsz-byt qsz-pkt flows   drops   marks   overlmt hashcol tx-bytestx-packets
                0       0       663     0       0       0       3       128049 740
```

I believe this is a driver related bug because:
1. Others have reported similar issues in the past that were driver problems[3];
2. This recent patch[4] by the kernel developer Felix Fietkau mentions that another driver from the same family, mt7615, has had issues setting tx power.

## Steps to reproduce:

Install Open Wrt 19.7.0 (kernel 4.14.162) on a TP-Link Archer C50 v4 or v5 and try to use the 2.4GHz Wi-Fi.

## Attempts at fixing:

We played around with all Wi-Fi configurations available. Some people reported small improvements by setting the channel width to 40MHz, no other change resulted in any report of improvements.

I set the antenna gain to 20 with the command below. I'm now able to find networks that I couldn't before when scanning **from** the router. 

```
~# iw phy phy0 set antenna_gain 20
```

## Kernel information:

Kernel .config file (as attachment).
Kernel version (from /proc/version): 

```
Linux version 4.14.162 (builder@buildhost) (gcc version 7.5.0 (OpenWrt GCC 7.5.0 r10860-a3ffeb413b)) #0 Mon Jan 6 16:47:09 2020
```

I'm not aware of any previous kernel version on Open Wrt that did not have this problem. 

The problem was not present on the original firmware, the source code of which is available at[5]. I don't know if it is the vanilla kernel or if there are any patches. 

The original firmware uses the kernel version 2.6.36. The .config file from within the source directory is attached. It was not the only config file present but it was the one on the root of the kernel source and it was named just ".config". The other files were either in other directories or had other names.

## Environment on the problematic Open Wrt firmware:

To make this message more readable, large command outputs were attached as text files. Since the original firmware doesn't give shell access I was not able to run those same commands from it.

"/proc/cpuinfo" > proc_cpuinfo.txt
"/proc/modules" > proc_modules.txt
"/proc/ioports" > proc_ioports.txt 
"/proc/iomem" > proc_iomem.txt

iw version 5.0.1

There is not PCI or SCSI information, since it's a domestic router. I was not able to find the ver_linux script online or on my source tree.

## Notes:

It took me sometime to gather all this information, I hope it's enough. Feel free to ask for any further information.

Thanks for your time.

## References:

[1] https://forum.openwrt.org/t/archer-c50-v4-mac80211-looses-internet-access-after-20-away-from-router-but-maintains-connection/53575/16

[2] https://bugs.openwrt.org/index.php?do=details&task_id=2781

[3] https://dev.archive.openwrt.org/ticket/20369

[4] https://lore.kernel.org/linux-wireless/20200130160121.14714-1-nbd@nbd.name/

[5] https://static.tp-link.com/resources/gpl/GPL_C50V4.tar.gz
Comment 1 mbcm 2020-01-30 19:43:25 UTC
I forgot to mention that restarting the interface gives a completely normal dmesg output:

```
[ 1249.141474] device wlan0 left promiscuous mode
[ 1249.146112] br-lan: port 2(wlan0) entered disabled state
[ 1249.970349] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 1249.994203] br-lan: port 2(wlan0) entered blocking state
[ 1249.999701] br-lan: port 2(wlan0) entered disabled state
[ 1250.005499] device wlan0 entered promiscuous mode
[ 1250.010421] br-lan: port 2(wlan0) entered blocking state
[ 1250.015809] br-lan: port 2(wlan0) entered forwarding state
[ 1250.179960] br-lan: port 2(wlan0) entered disabled state
[ 1250.598653] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 1250.605402] br-lan: port 2(wlan0) entered blocking state
[ 1250.610831] br-lan: port 2(wlan0) entered forwarding state
```
Comment 2 dtrautmann 2020-09-03 15:06:23 UTC
there is a pull request that should fix the problem: https://github.com/openwrt/mt76/pull/442