ath10k-ct
ath10k-ct copied to clipboard
greearb
Support for mesh/rawmode in firmware 10.1
Hi,
I'm trying to bring up an interface in mesh mode. I'm using ath10k-ct driver and ct-firmware 10.1, specifically firmware-2-ct-full-htt-mgt-community-21.bin for QCA 988X. My OS is OpenWRT 18.06.
When trying to bring up the mesh interface, it results in:
[ 25.818719] ath10k_pci 0000:00:00.0: must load driver with rawmode=1 to add mesh interfaces
Not a big problem because I can load the driver with:
root@OpenWrt:~# cat /etc/modules.d/ath10k-core
ath10k_core rawmode=1
But after then, the problem comes from the firmware:
[ 13.308124] ath10k_pci 0000:00:00.0: rawmode = 1 requires support from firmware
[ 13.315676] ath10k_pci 0000:00:00.0: fatal problem with firmware features: -22
[ 13.323232] ath10k_pci 0000:00:00.0: could not probe fw (-22)
And here is where I am stuck. Is it possible to enable rawmode in the firmware through configuration? Or could you add this feature to your official releases?
I tried all firmware 10.1 variants (htt/no-htt/full/etc) but always get the same result. Also older firmware versions didn't work.
I can confirm that with official firmware from Qualcom-Atheros, rawmode is enabled and mesh interface is up and working.
Also in another wave-2 board with 10.4 firmware-ct, rawmode works. It seems to affect only to 10.1.
Let me know if you need some more information and thanks in advance.
This would be a reasonable amount of effort, and I have no immediate plans to add this support. I would like to get IBSS working properly on 10.1 (It works for some users, but there are bug reports open), and hope that can be used for mesh related features. Likely it is 40-120 hours of effort to get support for mesh in my 10.1 firmware.
Well @greearb, what are your plans of fixing IBSS bugs so ? I'm facing these bugs right now and I can't actually use neither IBSS nor MESH on Ubiquity Wave-1 devices.
I'll try to work on ibss soon. If you can do some detailed testing to try to narrow down what works and does not work with IBSS and add the details to some bug that is not this one, that will help.
@greearb perfect. Please guide me in details what I should do. I have UAP AC LITE devices and able to get any statistics including plots using Prometheus, so you can see values in dynamics. Yes, I can write exporter for it to gather any values you want.
I experience problem with throughput. If I set beacon_int to 100ms (as default), I have jittering performance from a couple of kbits/s to 30 megabits/s in any direction. There is the workaround: to set beacon_int to 10ms. That works (around 100 mbit/sec in both directions). But even with 10ms, increasing distance between devices gives poor performance. I guess because of management frames loosing.
Also, speaking about MESH. It doesn't work with CT firmware, but works with vanilla (kvalo) firmware. Performance is about 80 MBit/s in any direction. That strange. For example, AP mode gives up to 380 Mbit/sec on these devices (at distance about 1M).
Some graphs with data got from /sys/kernel/debug/ieee80211/phy*/ath10k/rx_reorder_stats:
With beacon_int=100:
And for beacon_int=10 (note scale of values from previous benchmarking test):
supplicant config:
country=RU
ctrl_interface=/var/run/wpa_supplicant
ap_scan=2
eapol_version=2
network={
ht40=1
max_oper_chwidth=1
frequency=5180
fixed_freq=1
vht=1
ieee80211w=0
ssid="S_a23a6db169687f67fe925a5819a1"
proto=RSN
group_rekey=86400
wpa_ptk_rekey=86400
key_mgmt=SAE
sae_password="(hidden)"
mode=1
scan_ssid=0
pairwise=CCMP
group=CCMP
disable_max_amsdu=1
bssid=42:27:5a:5a:0e:14
beacon_int=10
}
Another user long ago found out that 10ms beacons also improved performance, that seems strange but reproducible, so maybe that is the place I should start debugging this issue. I cannot work on it right away, but will try to get to it in a week or two.
This is capture of traffic in monitor mode on third device.
test results (not during this capture, unfortunately):
batctl tp -t 10000 4862-5g-2
Test duration 10570ms.
Sent 17712 Bytes.
Throughput: 1.64 KB/s (13.40 Kbps)
in spite of that:
iw dev ibss_5g_1 station dump
Station 46:bf:ad:48:48:62 (on ibss_5g_1)
inactive time: 20 ms
rx bytes: 22378331
rx packets: 147727
tx bytes: 4270808
tx packets: 13408
tx retries: 241
tx failed: 1
rx drop misc: 169
signal: -51 [-52, -58] dBm
signal avg: -51 [-52, -57] dBm
tx bitrate: 866.7 MBit/s VHT-MCS 9 80MHz short GI VHT-NSS 2
rx bitrate: 780.0 MBit/s VHT-MCS 8 80MHz short GI VHT-NSS 2
rx duration: 915024 us
authorized: yes
authenticated: yes
associated: yes
preamble: long
WMM/WME: yes
MFP: no
TDLS peer: no
DTIM period: 0
beacon interval:100
short slot time:yes
connected time: 2909 seconds
on another device:
iw dev ibss_5g_2 station dump
Station 82:1c:b2:26:7e:d2 (on ibss_5g_2)
inactive time: 40 ms
rx bytes: 25339891
rx packets: 156348
tx bytes: 2800548
tx packets: 11888
tx retries: 610
tx failed: 4
rx drop misc: 1936
signal: -51 [-52, -58] dBm
signal avg: -50 [-50, -57] dBm
tx bitrate: 780.0 MBit/s VHT-MCS 8 80MHz short GI VHT-NSS 2
rx bitrate: 866.7 MBit/s VHT-MCS 9 80MHz short GI VHT-NSS 2
rx duration: 970552 us
authorized: yes
authenticated: yes
associated: yes
preamble: long
WMM/WME: yes
MFP: no
TDLS peer: no
DTIM period: 0
beacon interval:100
short slot time:yes
connected time: 2992 seconds
WARNING! mac-addresses of two interfaces on same radio end with same value. Please don't be confused.
device1:
phy#0
Interface ap_5g_1_emerg
ifindex 17
wdev 0x3
addr 6a:39:d6:26:7e:d2
ssid Ideco Emergency
type AP
channel 36 (5180 MHz), width: 80 MHz, center1: 5210 MHz
txpower 10.00 dBm
Interface ibss_5g_1
ifindex 16
wdev 0x2
addr 82:1c:b2:26:7e:d2
ssid S_a23a6db169687f67fe925a5819a1
type IBSS
channel 36 (5180 MHz), width: 80 MHz, center1: 5210 MHz
txpower 10.00 dBm
device2:
phy#4
Interface ap_5g_2_emerg
ifindex 45
wdev 0x400000003
addr 1a:01:b0:48:48:62
ssid Ideco Emergency
type AP
channel 36 (5180 MHz), width: 80 MHz, center1: 5210 MHz
txpower 10.00 dBm
Interface ibss_5g_2
ifindex 44
wdev 0x400000002
addr 46:bf:ad:48:48:62
ssid S_a23a6db169687f67fe925a5819a1
type IBSS
channel 36 (5180 MHz), width: 80 MHz, center1: 5210 MHz
txpower 10.00 dBm
Both firmwares are the same: QCA988X-firmware-2-ct-full-htt-mgt-community-22.bin.lede.007
CT-driver is from commit a696e602a0fc83dd809e5860e21019cf48e0028b and subdir for 4.16 kernel.
supplicant.conf:
# ===============
country=RU
ctrl_interface=/var/run/wpa_supplicant
ap_scan=2
eapol_version=2
network={
# ===============
ht40=1
max_oper_chwidth=1
frequency=5180
fixed_freq=1
vht=1
ssid="S_a23a6db169687f67fe925a5819a1"
proto=RSN
group_rekey=86400
wpa_ptk_rekey=86400
key_mgmt=SAE
sae_password="d7adf86b1d126ff8853cceea1a12bd95"
mode=1
scan_ssid=0
pairwise=CCMP
group=CCMP
disable_max_amsdu=1
bssid=42:27:5a:5a:0e:14
beacon_int=100
}
I've been too busy to look at this issue. I'm primarily interested in working on wave-2 and later firmware these days.
@greearb We actually have exactly the same problems on wave-2 chip (encrypted MESH does not work without setting beacon_int=10). And when it works, speed is much slower (i.e. 100 mbti/sec) comparing to AP/STA mode (400 mbit/sec)
@greearb CT-firmware + IBSS + beacon_int=10 gives about 120 mbit/sec QCA firmware + 802.11s gives less than 100.
in my setup.
Anyway. I will follow your instructions how to debug. Please tell me how I can gather information you need. Moreover, I can give you SSH access.
For the numbers above, is this with wave-1 firmware or wave-2? You said you had the same problem with wave-2: Please open a separate bug to track that, with some details of the problems you see.
And, another thing, recent CT wave-1 firmware has some raw-tx support. In case that is all that is needed for MESH, you could try editing the driver to tell it to allow MESH and see if it works? Another user was able to get AP-VLANs working in a similar manner, evidently.
This would be a reasonable amount of effort, and I have no immediate plans to add this support. I would like to get IBSS working properly on 10.1 (It works for some users, but there are bug reports open), and hope that can be used for mesh related features. Likely it is 40-120 hours of effort to get support for mesh in my 10.1 firmware.
Hello there, so as far as i understand You will not include rawmode in any future for 10.1 firmware? Sorry but i would be very pleased to get that for mesh mode. Currently i have tp-link archer c7 v2 with openwrt and with ath10k rawmode works but the router i dunno why is rebooting everytime i try to connect to that wifi on ath10k driver with qualcomm driver. Only yours 10.1 works perfectly but without mesh.
Yes. ath10k-ct 10.1 firmware and driver support IBSS mode which works exactly like 802.11s without packet forwarding.
Besides that i have found a very interesting bug with the originall firmware:) The earlier comment about rebooting the kernel, i have found why are happening. The rebooting is taking place only when i try to connect to that 5GHz wirless from laptop with intel dual band wireless-ac 7260. All other clients doesn't cause such kernel panic feature :]
I tried to setup ad-hoc in luci and it dosn't work either.
Ok tried again and it works but i am not able to get internet connection.
Sorry, it's not an openwrt helpdesk. You cant try to ask people in the openwrt forum.
Sorry, it's not an openwrt helpdesk. You cant try to ask people in the openwrt forum.
Yes i know that this is not the openwrt helpdeks. I just wanted to inform that this is why this bug has occured, nothing more. I have also reverted back to ct firmware and what i have discoverd is that IBSS is not working for me with any encryption, and if no encryption is set than i can connect but my devices says that there is no internet connection. So i was woundering if you already persuaded me to use IBSS instead of MESH, than maybe you could help me with configuring it?