OpenWrt/LEDE Project

  • Status Waiting on reporter   Reopened
  • Percent Complete
    0%
  • Task Type Bug Report
  • Category Base system
  • Assigned To No-one
  • Operating System All
  • Severity High
  • Priority Very Low
  • Reported Version openwrt-19.07
  • Due in Version Undecided
  • Due Date Undecided
  • Private
Attached to Project: OpenWrt/LEDE Project
Opened by psyborg - 12.11.2019
Last edited by Petr Štetiar - 15.01.2020

FS#2593 - no AC wifi with ath10k on 19.07-rc1

- Archer C7, Netgear R7800
- 19.07-RC1 default
- install image, configure wifi, try to connect, in my case i’m getting 300Mbps rate, others report as low as up to 54 (legacy only)

 

R7800 report: https://forum.openwrt.org/t/openwrt-19-07-0-first-release-candidate/48040/33

Archer C7 v2 report: https://forum.openwrt.org/t/openwrt-19-07-rc1-archer-c7-v2-5g-wifi-died-after-trying-to-change-channels/48182/7

the situation is the same with intree 4.9.200 driver or any of the latest backports installed on client PC

Uwe Gradenegger [MSFT] commented on 12.12.2019 19:09

I can confirm similar behavior with my TP-Link Archer C2600. 5GHz Wifi is unuseable with 19.07-rc1 (didnt try with rc2 so far). Massive drops as soon as I go away from the AP a few metres.

psyborg commented on 12.12.2019 19:55

rc2 makes no difference

cj commented on 30.12.2019 01:33

I can't say I see a problem with my C2600 running 19.07 RC1; Access point is in the attic and i'm in the basement... relevant info..

I'll upgrade to the latest RC and see if it *makes* a problem..

root@:~# cat /etc/openwrt_*
DISTRIB_ID='OpenWrt'
DISTRIB_RELEASE='19.07.0-rc1'
DISTRIB_REVISION='r10649-c4fdb377a2'
DISTRIB_TARGET='ipq806x/generic'
DISTRIB_ARCH='arm_cortex-a15_neon-vfpv4'
DISTRIB_DESCRIPTION='OpenWrt 19.07.0-rc1 r10649-c4fdb377a2'
DISTRIB_TAINTS=''
r10649-c4fdb377a2

root@:~# dmesg | grep -i archer
[ 0.000000] OF: fdt: Machine model: TP-Link Archer C2600

root@:~# iw dev wlan0 info
Interface wlan0

ifindex 10
wdev 0x3
addr ec:08:6b:bb:03:18
ssid WIFI-AC
type AP
wiphy 0
channel 36 (5180 MHz), width: 80 MHz, center1: 5210 MHz
txpower 23.00 dBm
multicast TXQ:
	qsz-byt	qsz-pkt	flows	drops	marks	overlmt	hashcol	tx-bytes	tx-packets
	0	0	1178	0	0	0	0	106841		1178

root@:~# iw dev wlan1 info
Interface wlan1

ifindex 11
wdev 0x100000003
addr ec:08:6b:bb:03:19
ssid WIFI-N
type AP
wiphy 1
channel 11 (2462 MHz), width: 20 MHz, center1: 2462 MHz
txpower 30.00 dBm
multicast TXQ:
	qsz-byt	qsz-pkt	flows	drops	marks	overlmt	hashcol	tx-bytes	tx-packets
	0	0	0	0	0	0	0	0		0

root@:~#

[@thinkarch ~]$ iperf -c bigbox -i 1 -t 10


Client connecting to bigbox, TCP port 5001
TCP window size: 178 KByte (default)


[ 3] local 192.168.11.215 port 42158 connected with 192.168.11.10 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 1.0 sec 28.2 MBytes 237 Mbits/sec
[ 3] 1.0- 2.0 sec 28.2 MBytes 237 Mbits/sec
[ 3] 2.0- 3.0 sec 27.2 MBytes 229 Mbits/sec
[ 3] 3.0- 4.0 sec 32.1 MBytes 269 Mbits/sec
[ 3] 4.0- 5.0 sec 31.9 MBytes 267 Mbits/sec
[ 3] 5.0- 6.0 sec 32.5 MBytes 273 Mbits/sec
[ 3] 6.0- 7.0 sec 32.2 MBytes 271 Mbits/sec
[ 3] 7.0- 8.0 sec 31.4 MBytes 263 Mbits/sec
[ 3] 8.0- 9.0 sec 32.1 MBytes 269 Mbits/sec
[ 3] 9.0-10.0 sec 28.4 MBytes 238 Mbits/sec
[ 3] 0.0-10.0 sec 304 MBytes 254 Mbits/sec
[@thinkarch ~]$

cj commented on 30.12.2019 02:11

Upgraded to RC2; still don't see a problem; I may not have done a full reconfiguration on any of the upgrades.. (carried over config) i may try doing that to see if i see the issues ya'll are seeing.

root@:~# cat /etc/openwrt_*
DISTRIB_ID='OpenWrt'
DISTRIB_RELEASE='19.07.0-rc2'
DISTRIB_REVISION='r10775-db8345d8e4'
DISTRIB_TARGET='ipq806x/generic'
DISTRIB_ARCH='arm_cortex-a15_neon-vfpv4'
DISTRIB_DESCRIPTION='OpenWrt 19.07.0-rc2 r10775-db8345d8e4'
DISTRIB_TAINTS=''
r10775-db8345d8e4


Client connecting to bigbox, TCP port 5001
TCP window size: 170 KByte (default)


[ 3] local 192.168.11.215 port 55934 connected with 192.168.11.10 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 1.0 sec 25.1 MBytes 211 Mbits/sec
[ 3] 1.0- 2.0 sec 19.9 MBytes 167 Mbits/sec
[ 3] 2.0- 3.0 sec 23.1 MBytes 194 Mbits/sec
[ 3] 3.0- 4.0 sec 22.2 MBytes 187 Mbits/sec
[ 3] 4.0- 5.0 sec 24.5 MBytes 206 Mbits/sec
[ 3] 5.0- 6.0 sec 21.0 MBytes 176 Mbits/sec
[ 3] 6.0- 7.0 sec 21.0 MBytes 176 Mbits/sec
[ 3] 7.0- 8.0 sec 22.8 MBytes 191 Mbits/sec
[ 3] 8.0- 9.0 sec 22.8 MBytes 191 Mbits/sec
[ 3] 9.0-10.0 sec 21.4 MBytes 179 Mbits/sec
[ 3] 0.0-10.1 sec 224 MBytes 187 Mbits/sec

cj commented on 31.12.2019 02:06

I have an archer c7 V2 that I can provide/ set up to help with troubleshooting;
What steps are needed to recreate the problem?
Is it client-dependent? I see mentions of the client machine in both of the linked threads...

I'm happy to do a few builds and testing with some guidance..

psyborg commented on 14.01.2020 03:06

wlan0: capabilities/regulatory prevented using AP HT/VHT configuration, downgraded

on one of 4.14 builds i did get: Could not set channel for kernel driver

on trunk with US regdomain card VHT80 is available but clients connecting from linux machines are limited to 300Mbps (unless patched regdb, in which case it works as expected and no performance issues are present)
having a card with different regdomain, e.g. CR fallbacks to VHT20 mode and there was no way to get VHT80 using any of the 5GHz channels...

psyborg commented on 15.01.2020 16:03

not a duplicate, this is not performance issue it is mac80211 screwup, read my logs posted on forum

Admin
Petr Štetiar commented on 15.01.2020 16:07

The relevatn info should be distilled and available here. Don't expect, that someone is going to read such a long threads in order to find a signal in this noise.

In other words, provide as much details as possible. I for example miss an information about the client, if this is regression, if so, what was last working version. Is it happening also on master?

psyborg commented on 15.01.2020 19:22

client used QCA9880 in linux laptop, message wlan0: capabilities/regulatory prevented using AP HT/VHT configuration, downgraded appears when connecting to QCA9880 AP running master or any of the 19.07 rc. still it connects at HT rates, but not VHT. client tests made using several latest backports versions compiled with default kconfig. connecting using VHT rates works at least with trunk build from 2018. on 4.9.111

another problem is VHT80 doesn't work at all for some countries and this is not on client but on AP, there is no way to get VHT80 using that country code regardless of switching to non-DFS channel it fallbacks to VHT20

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing