OpenWrt/LEDE Project

  • Status New
  • Percent Complete
    0%
  • Task Type Bug Report
  • Category Base system
  • Assigned To No-one
  • Operating System All
  • Severity Medium
  • Priority Low
  • Reported Version openwrt-19.07
  • Due in Version Undecided
  • Due Date Undecided
  • Private
Attached to Project: OpenWrt/LEDE Project
Opened by Thai Tran - 29.01.2020
Last edited by Adrian Schmutzler - 25.02.2020

FS#2781 - Archer C50 v4 Mac80211 Looses Internet Access after 20’+ Away from Router But Maintains Connection

Supply the following if possible:
- Device problem occurs on
- Software versions of OpenWrt/LEDE release, packages, etc.
- Steps to reproduce

 

Problem Device:
TP-Link Archer C50 (Canadian) v4 + v4.2

Software version:
openwrt 19.07 r10860, default packages versions.

Steps to reproduce:
Setup wireless like below. I’ve intentionally left encryption set to “none” for both radio’s for quick testing but i’ve tested with WPA2 CCMP encryption with no change in results.

config wifi-device ‘radio0’ option type ‘mac80211’ option channel ‘11’ option hwmode ‘11g’ option path ‘platform/10300000.wmac’ option htmode ‘HT20’ option legacy_rates ‘0’ option country ‘CA’

config wifi-iface ‘default_radio0’ option device ‘radio0’ option network ‘lan’ option mode ‘ap’ option ssid ‘OpenWrt’ option encryption ‘none’

config wifi-device ‘radio1’ option type ‘mac80211’ option hwmode ‘11a’ option path ‘pci0000:00/0000:00:00.0/0000:01:00.0’ option htmode ‘VHT80’ option channel ‘112’ option legacy_rates ‘0’ option country ‘CA’

config wifi-iface ‘default_radio1’ option device ‘radio1’ option network ‘lan’ option mode ‘ap’ option ssid ‘OpenWrt’ option encryption ‘none’

Alternative Settings:

htmode ‘HT40’ No change in results
channel ‘1’, ‘6’, ‘11’ No change in results
disassoc_low_ack ‘0’ No change in results

Thai Tran commented on 29.01.2020 15:42

Symptom persistent with openwrt-19.07-snapshot-r10269.
Not an environmental issue as the router has been tested on different locations within my City.

Zap McZap commented on 29.01.2020 16:46

The bug affects me and one more person as well (OP here and there are the same), see.
My router is brazilian, which internally is the same as the european one (as stated here, search "Brazil" on the page).

I had the problem with no extra packages installed, right after flashing 19.0.7.

I'm 99% sure there is a small improvement by setting:

option distance '15' # larger values produce nor further improvement
option HTMODE 'HT40'

Thanks for your time.

Zap McZap commented on 30.01.2020 02:34

I have some additional info.

When I restart the 2.4GHz interface there are two error messages in the system log that do not appear when restarting the 5GHz interface:

#More stuff above
Thu Jan 30 01:55:04 2020 user.notice mac80211: Failed command: iw phy phy0 set antenna 0xffffffff 0xffffffff
Thu Jan 30 01:55:05 2020 daemon.err hostapd: Configuration file: /var/run/hostapd-phy0.conf
#More stuff below

Investigating the first error

If I re-run the the first command on the terminal I get:

~# iw phy phy0 set antenna 0xffffffff 0xffffffff
command failed: Not supported (-122)

I could not find any information about the error code on the web.

The output of of "wl list" is: https://pastebin.com/raw/66UYQyvK

Some interesting things to notice are:
1. Both coverage class are set to "0 (up to 0m)". phy1(5GHz) has been like that since the beginning, I did not touch it. I did change phy0(2.4GHz) to 0 but even after setting it to "auto" on the Web GUI it remains as 0.

2. Both interfaces have "Available Antennas" and "Configured Antennas" set to 0x3. From the error message it seems like phy0(2.4GHz) should be set to 0xf.

3. I did try setting phy0(2.4GHz) antennas to 0x0, 0x1, 0x2, 0x3 and all others up to 0xf. All antenna codes up to and including 0x3 (the one currently set) gave the error:

command failed: Not supported (-122)

The codes above 0x3 and up to 0xf gave the error:

command failed: Invalid argument (-22)

Investigating the second error

The contents of the file " /var/run/hostapd-phy0.conf" are here: https://pastebin.com/raw/rwQrWabE

Some interesting things to note are:

1. There is no analogous file for phy1(5GHz).

2. On the Web GUI "mode" is set to "n".

hw_mode=g

3.On the Web GUI "Isolate clients" is not set.

ap_isolate=1

Finally I set the kernel log leave to 7 (debug, highest) and dmesg gave a normal output after restarting phy0(2.4GHz)

[ 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
Zap McZap commented on 30.01.2020 15:12

Update:

I think I found the problem but I still do not how to fix it.

This gives me improvements on the receiving power. When doing a scan from the router I can now find networks that I couldn't before.

iw phy phy0 set antenna_gain 20

On the other hand I'm not able to change the transmission power. I tried many values, large and small.

#Neither of those commands works (the number is in mDm, 2000mDm == 20dBm)
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 found this ticket reporting the same problem with a different router that uses same driver (mt76). The driver has had problems setting power before.

Update: Of course 90% of the links on the linked ticket are broken and now I'm in the dark.

Zap McZap commented on 30.01.2020 19:39

I opened a bug report on the kernel mail list: https://bugzilla.kernel.org/show_bug.cgi?id=206363

Project Manager
Adrian Schmutzler commented on 25.02.2020 22:39

I'm also having problems with low range on 2.4 GHz. I'm using EU 4.2 HW version and self-built 19.07 from 2020-02-25. However, for me txpower is shown as 20 dB which is the allowed maximum (with 0 dB antenna_gain!).

Has anybody tested this with master?

Project Manager
Adrian Schmutzler commented on 25.02.2020 22:56

Seems to be similar on master ...

Zap McZap commented on 03.03.2020 16:50

You can improve antenna gain with:

iw phy phy0 set antenna_gain 20

This improves the receiving signal strength considerably. With this I'm able to see networks that I couldn't before.

Unfortunately we still do not have any replies on the kernel bug report.

Project Manager
Adrian Schmutzler commented on 03.03.2020 18:16

What you do with antenna_gain here is just reducing the txpower:
txpower = legal maximum tx - antenna_gain

So, having better receiving quality seems to be a result of the reduced transmitting power here, and thus isn't really helpful after all ...

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing