Ath10k (5GHz card) after upgrade to 3.3

I had really bad packet loss after the upgrade to 3.3. The culprit seems to be the new firmware

ab36ef267d15cfc02317ceeb38e8f548 board.bin
d7e081e9782936ed544b78994c9133fb firmware-2.bin

eventually replaced with fw from debian stretch:

ab36ef267d15cfc02317ceeb38e8f548 board.bin
eca8fd35aec383278223efdf35a00f33 firmware-4.bin
982716ab286c337254a2a4553eb2d905 firmware-5.bin

which is

root@turris:~# ethtool -i wlan0
driver: ath10k_pci
version: 4.4.35-34abcd5e548fc8ed5390269f
firmware-version: 10.2.4.70.54
expansion-rom-version: 
bus-info: 0000:02:00.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no

seems more stable for me… anyone experienced the same?

1 Like

so…

before upgrade:

root@turris:~# btrfs subvol list / |tail -n2 |head -1  |awk '{print $NF}'
@5
root@turris:~# mount -o ro,subvol=@5 /dev/mmcblk0p1 /mnt/fix
root@turris:~# ls -l /mnt/fix/lib/firmware/ath10k/QCA988X/hw2.0/
-rw-r--r--    1 root     root          2116 Sep  5 14:44 board.bin
-rw-r--r--    1 root     root        245088 Sep  5 14:44 firmware-5.bin

after upgrade to 3.3:

root@turris:~# opkg files ath10k-firmware-qca988x-ct
Package ath10k-firmware-qca988x-ct (2016-09-13-307cb46b06661ebd3186723b5002de769c7add83-1) is installed on root and has the following files:
/lib/firmware/ath10k/QCA988X/hw2.0/firmware-2.bin
/lib/firmware/ath10k/QCA988X/hw2.0/board.bin
-rw-r--r--    1 root     root          2116 Dec  5 16:53 board.bin
-rw-r--r--    1 root     root        201372 Dec  5 16:53 firmware-2.bin

In changelog:

  • Update of WiFi drivers to the latest LEDE version, Candela Technologies driver for ath10k.

can be that Candela Technologies driver for ath10k have different version numeration and firmware-2.bin from Candela be more modern that old firmware-5.bin?

Maybe they forgot to include the same firmware ? :slight_smile:

@opotonil is right… candelatech company have used 10.1 version of QCA as a base for their version of the driver and backported some features to it. So my assumption that version went down is misleading

more info here:
http://www.candelatech.com/ath10k-10.1.php

The problem with candelatech driver is still there… I had “downtime” on my home network and wife was not happy about it :smiley: Another thing I’ll do is to remove from cron job update at 17 hour and leave only 05 :stuck_out_tongue:

btw my ath10k wifi serves 3 different ESSIDs so this could trigger it. For now I’m staying with 10.2.4.70.54

Hi guys,

Have a lot of troubles too with wifi since the upgrade to 3.3 (it was working very well before). Lots of packet loss, the wifi signal seems very poor (I can’t use it anymore in some room I used to have a good signal).

How do you install the other firmware from another distro ? Just copy them ? Is there a pkg ?

Is there a bug tracker to report this kind of issue ? How is the automatic upgrade is tested before beeing sent to production ?

I also have a lot of ATH10K_DBG_BUFFER dumped in the dmesg. Is it normal ?

just answering myself:

just copy firmware-{4,5}.bin to /lib/firmware/ath10k/QCA988X/hw2.0/ then reboot and it’s done. Back to 10.2.4.70.54 and it works perfectly !

But still interested having answers to my other questions. Thanks for help.

2 Likes

Thank you guy. I have the same problem with my old turris v. 1 after update. My wife is crazy, so I am going to try to follow your way once be back at home today.

I’ve done some really simple test for few firmwares out there

ping -c 1000 -i 0.1

md5sum
5b651c0458bcf5c20701308b5e519976 - 3% packet loss, 11ms avg - firmware-2-ct-full-community-16.bin-lede (10.1.467-ct-_fW-016-3389de7) 
d7e081e9782936ed544b78994c9133fb - 7% packet loss, 12ms avg - firmware-2-ct-full-community-16.1.bin-lede (10.1.467-ct-_fW-016-0c89552) <= version of Turris 3.3
62b30ffe154ea7c7c6c4c6a5b1eddc53 - 3% packet loss, 12ms avg - firmware-2-ct-full-community-17.bin (10.1.467-ct-_fW-017-8249e59)
665482e1fd20a410627996c9a0b93411 -28% packet loss, 52ms avg - firmware-2-ct-full-community.bin-18.rc2-lede (10.1.467-ct-_fW-018-a857715)
36768dc68572b3f2660211e20e89f558 - 2% packet loss, 11ms avg - firmware-5.bin (10.2.4.70-2) <= Turris 3.2, before upgrade
982716ab286c337254a2a4553eb2d905 - 0% packet loss,  8ms avg - firmware-5.bin (10.2.4.70.54) <= from debian

of course this simple test doesn’t prove anything at all… the proper testing is needed to confirm (multiple stations, multiple ESSID per card)

Where can you find the older firmware? Thank you.

Here for example: https://github.com/kvalo/ath10k-firmware/tree/master/QCA988X/hw2.0/10.2.4.70

for the bugtracker I found this https://gitlab.labs.nic.cz/groups/turris/issues
Should we open a ticket ?

That’s not neccesary in this case. @miska is working on it.
You can see this:
https://gitlab.labs.nic.cz/groups/turris/activity / https://gitlab.labs.nic.cz/turris/openwrt/commits/stable
it was pushed to stable few hours ago.

great news ! If I understand correctly, it will be pushed to us via an updated ath10k-firmware package ?

Well, don’t be so excited, I have no issue with current firmware so without being able to reproduce your problems, this is just a guess. Once I test that it is not entirely broken, I’ll ask you to give it a try.

I also have issues with new atk10k, after upgrade radio0 started to really behave badly on 2.4 ghz (I am not running 5ghz), another card -> radio1 was wonky from day one for me, so changing to radio0 was the only “stability” I had…

My setup is:

root@turris:/etc/config# cat /etc/config/wireless 
config wifi-device 'radio0'
    option type 'mac80211'
    option path 'platform/soc/soc:pcie-controller/pci0000:00/0000:00:02.0/0000:02:00.0'
    option disabled '0'
    option txpower '23'
    option hwmode '11g'
    option channel '9'
    option htmode 'HT20'
    option country 'US'
config wifi-device 'radio1'
    option type 'mac80211'
    option country 'CZ'
    option hwmode '11g'
    option path 'platform/soc/soc:pcie-controller/pci0000:00/0000:00:01.0/0000:01:00.0'
    option htmode 'HT20'
    option disabled '0'
    option txpower '19'
    option channel '4'
config wifi-iface
    option network 'wwan'
    option ssid 'redacted'
    option encryption 'psk2'
    option device 'radio1'
    option mode 'sta'
    option bssid '5C:0A:5B:XX:XX:XX'
    option key 'redacted'
config wifi-iface
    option device 'radio0'
    option mode 'ap'
    option ssid 'b_live'
    option encryption 'psk2'
    option key 'redacteda'
    option network 'lan'
config wifi-iface
    option device 'radio0'
    option mode 'ap'
    option ssid 'b_oob'
    option network 'oob'
    option encryption 'psk2'
    option key 'redactedb'
config wifi-iface
    option device 'radio0'
    option mode 'ap'
    option ssid 'b_guest'
    option encryption 'psk2'
    option key 'redactedc'
    option network 'guest'

b_guest serves 5 clients (mostly phones, printers etc)
b_live serves 4 clients (2x laptop, 2x raspbery pi)
b_oob 0 clients

I can provide more info (e.g. wireless devices, drivers and their versions) on request

Same experience like @Mateusz_Czeladka.

The wi-fi 2 works perfectly after the update. Wi-Fi 1 is disaster = absolutely unstable especially in rooms with weaker signal and entries like this in system log: debug kernel[]: [32695.471200] ath10k: [0000]: 01FEF741 14004C2F 00000090 0041F014 00438FB8 00000000 00000000 01FEF741

Wi-Fi 2 was disabled during the update and works now. Wi-Fi 1 was up and running during the update and has issues now. Can this be related somehow?

I did rollback to previous snapshot and executed updater.sh manually afterwards. It did not help. Issues still remain. I can provide output of the manual updater run if this can help somehow.

My problem are mostly on radio0 5Ghz with an estimated rate at 6Mbits/s. Have to disable it.
About 10 clients on radio1 2.4Ghz and a couple on radio0.

Here is my config

config wifi-device 'radio0'
	option type 'mac80211'
	option hwmode '11a'
	option path 'platform/soc/soc:pcie-controller/pci0000:00/0000:00:02.0/0000:02:00.0'
	option htmode 'VHT80'
	option disabled '0'
	option country 'FR'
	option txpower '20'
	option channel 'auto'

config wifi-iface
	option device 'radio0'
	option network 'lan'
	option mode 'ap'
	option disabled '0'
	option encryption 'psk2+tkip+aes'
	option key 'XXX'
	option ssid 'BZH'

config wifi-device 'radio1'
	option type 'mac80211'
	option channel '11'
	option hwmode '11g'
	option path 'platform/soc/soc:pcie-controller/pci0000:00/0000:00:01.0/0000:01:00.0'
	option htmode 'HT20'
	option disabled '0'
	option txpower '19'
	option country 'FR'

config wifi-iface
	option device 'radio1'
	option network 'lan'
	option mode 'ap'
	option disabled '0'
	option ssid 'BZH'
	option encryption 'psk2+tkip+aes'
	option key 'XXX'

Have you changed cabling for that? In default cabling, 2.4 GHz signal is blocked by diplexer boards for the radio0 card, so when you operate radio0 in 2.4 GHz band, it gets only the middle antenna. This could cause some issues.

1 Like