Modify

Opened 4 years ago

Closed 3 years ago

Last modified 2 years ago

#16589 closed defect (worksforme)

ATH10k for Tp-Link Archer C7 V2

Reported by: optimizerapp@… Owned by: kaloz
Priority: normal Milestone: Chaos Calmer 15.05
Component: packages Version: Trunk
Keywords: Cc:

Description

The driver kmod-ath10k_3.10.36+2014-05-19-1_ar71xx.ipk has stopped supporting the original mini pcie card qca9880-br4a (nhy150.002c 1405 korea) in Tp-link Archer C7 V2 router. I have tried re-installing everything many times.

Now it works only for COMPEX WLE900V5-18 mini pcie card.

Attachments (3)

firmware-2.bin (192.7 KB) - added by michal.kazior@… 4 years ago.
board.bin (2.1 KB) - added by michal.kazior@… 4 years ago.
Initial Commit.sln (14.2 KB) - added by anonymous 22 months ago.

Download all attachments as: .zip

Change History (117)

comment:1 Changed 4 years ago by WonderWoofy

I just got a tp-link archer c7 v2 today, and can confirm that this seems to be the case. When the module gets loaded I get this:

root@OpenWrt:/# dmesg | grep ath10k
[ 210.560000] ath10k_pci 0000:01:00.0: BAR 0: assigned [mem 0x12000000-0x121fffff 64bit]
[ 210.870000] ath10k: pci irq legacy irq_mode 0 reset_mode 0
[ 210.960000] ath10k: otp calibration failed: 2
[ 210.960000] ath10k: failed to run otp: -22
[ 210.970000] ath10k: could not init core (-22)
[ 211.230000] ath10k: could not probe fw (-22)
[ 211.230000] ath10k: failed to register driver core: -22
[ 211.230000] ath10k_pci: probe of 0000:01:00.0 failed with error -22

comment:2 Changed 4 years ago by anonymous

This might help narrow down the cause. My flash is working:

BARRIER BREAKER (Bleeding Edge, r40698)

# dmesg | grep ath10
[ 10.260000] ath10k_pci 0000:01:00.0: BAR 0: assigned [mem 0x12000000-0x121fffff 64bit]
[ 10.580000] ath10k: pci irq legacy
[ 11.890000] ath10k: qca988x hw2.0 (0x4100016c) fw 10.1.467.2-1 api 2 htt 2.1

comment:3 Changed 4 years ago by michal.kazior@…

Can you verify what mac address you get with the offending card on older OpenWRT build?

comment:4 follow-up: Changed 4 years ago by anonymous

I am also getting the same failure. In the earlier version of OpenWrt the MAC was 00:03:07:12:34:56. The 5GHz card was detected, but had very poor performance (6 Mbps). Both versions of the firmware gave the same MAC address, and would not detect the correct MAC address.

In the current version of OpenWrt, I also get the OTP failure

comment:5 Changed 4 years ago by anonymous

Still present on r40896 (Archer C7 v2). ac is useless until this is fixed

comment:6 in reply to: ↑ 4 Changed 4 years ago by michal.kazior@…

Replying to anonymous:

I am also getting the same failure. In the earlier version of OpenWrt the MAC was 00:03:07:12:34:56. The 5GHz card was detected, but had very poor performance (6 Mbps). Both versions of the firmware gave the same MAC address, and would not detect the correct MAC address.

In the current version of OpenWrt, I also get the OTP failure

For the record, if you had 00:03:07:12:34:56 mac address in older OpenWRT builds this strongly suggests OTP is messed up on your device in the first place. I don't know if anything can be really done with this.

What do mean by "both versions of firmware"? The 2 branches (main and 10.1) that are available on Kalle Valo's github or did you test something else?

I wonder if firmware and otp binaries found on the original TP-Link Archer C7 v2 software would work? Did you try that?

comment:7 follow-up: Changed 4 years ago by anonymous

I am able to reflash the original TP-Link firmware and get the correct MAC address, which suggests that OTP is not messed up. What do you think ? Reflashing the TP-Link firmware would not rewrite the OTP, right ? This is done only in silicon production, right ?

I tried the firmware for station (999 version), and the AP firmware. Both of these are available from the OpenWrt build.

comment:8 in reply to: ↑ 7 Changed 4 years ago by michal.kazior@…

Replying to anonymous:

I am able to reflash the original TP-Link firmware and get the correct MAC address, which suggests that OTP is not messed up. What do you think ? Reflashing the TP-Link firmware would not rewrite the OTP, right ? This is done only in silicon production, right ?

I don't think reflashing touches OTP. Nonetheless it's good that you can reflash the original firmware.

Did you try to use firmware binaries found on the original TP-Link with ath10k? Beats me what filenames they have. Maybe athwlan.bin and otp.bin.

For now I consider two options:

  1. tp-link firmware is different and it reads/executes otp correctly (this suggests perhaps a differently stored otp although this is highly speculative as I have no expertise with this at all)
  1. tp-link overrides interface mac address (ifconfig $iface hw ether $mac) so it's visible with something else than 00:03:07:12:34:56

You (or at least another anonymous) mentioned 6mbps throughput with older OpenWRT build (while ath10k booted the offending card) - how did you measure it? Was it real throughput measured (e.g. with iperf) or was it what you saw in output of iw wlan0 station dump on AP? If it's the latter then it's fine, because firmware isn't capable of reporting tx rate to ath10k so it always states 6mbps.

I tried the firmware for station (999 version), and the AP firmware. Both of these are available from the OpenWrt build.

Thanks for claryfing.

comment:9 follow-up: Changed 4 years ago by anonymous

Yes, I am the person who reported 6 Mbps. I measured this by setting up an FTP server and ad-hoc network with the client and server connected to a TP-link router each. The rate was about 4 Mb/s on the air. I checked the RX rate on the receiver which reported 6 Mbps.

I also checked using iw, which reported the same rate.

My thinking is that somehow the OTP is not read correctly, and hence not validated correctly.

The firmware that I reflashed was the one found on TP-Link website. It does not have a separate OTP file. It is a single file.

http://www.tp-link.com/lk/support/download/?model=Archer+C7&version=V2

comment:10 in reply to: ↑ 9 Changed 4 years ago by michal.kazior@…

Replying to anonymous:

Yes, I am the person who reported 6 Mbps. I measured this by setting up an FTP server and ad-hoc network with the client and server connected to a TP-link router each. The rate was about 4 Mb/s on the air. I checked the RX rate on the receiver which reported 6 Mbps.

I also checked using iw, which reported the same rate.

I don't think ad-hoc network is a good thing to test throughput with. Rate control seems to behave weird in ad-hoc from what I recall.

My thinking is that somehow the OTP is not read correctly, and hence not validated correctly.

The firmware that I reflashed was the one found on TP-Link website. It does not have a separate OTP file. It is a single file.

http://www.tp-link.com/lk/support/download/?model=Archer+C7&version=V2

Oh, thanks for the link.

I've extracted the rootfs from the zip/bin and then extracted wireless firmware files from umac.ko. I'll prepare and attach firmware files ready for testing with ath10k.

Changed 4 years ago by michal.kazior@…

Changed 4 years ago by michal.kazior@…

comment:11 follow-up: Changed 4 years ago by michal.kazior@…

Can you test ath10k with the attached firmware files and report if it helps, please?

comment:12 Changed 4 years ago by anonymous

ar9344+qca9882
root@OpenWrt:/# dmesg |grep ath10
[ 11.530000] ath10k_pci 0000:00:00.0: BAR 0: assigned [mem 0x10000000-0x101fffff 64bit]
[ 11.840000] ath10k: pci irq legacy irq_mode 0 reset_mode 0
[ 12.210000] ath10k: otp calibration failed: 2
[ 12.210000] ath10k: failed to run otp: -22
[ 12.220000] ath10k: could not init core (-22)
[ 12.480000] ath10k: could not probe fw (-22)
[ 12.480000] ath10k: failed to register driver core: -22
[ 12.480000] ath10k_pci: probe of 0000:00:00.0 failed with error -22

comment:13 follow-up: Changed 4 years ago by anonymous

I'm not sure if comment 12 was in response to michal.kazior's extracted firmware files.

But I would like to help if I can. I just have no idea what to actually do with those files. I have a feeling that embedded doesn't load firmware like x86 (from /lib/firmware). So I imagine that these would apply to a particular partition of the flash.

If anyone would be willing to give me a brief explanation of where to stick these files, or where to put them in order to build them into an image, I would be happy to help.

comment:14 in reply to: ↑ 13 Changed 4 years ago by michal.kazior@…

Replying to anonymous:

I'm not sure if comment 12 was in response to michal.kazior's extracted firmware files.

But I would like to help if I can. I just have no idea what to actually do with those files. I have a feeling that embedded doesn't load firmware like x86 (from /lib/firmware). So I imagine that these would apply to a particular partition of the flash.

If anyone would be willing to give me a brief explanation of where to stick these files, or where to put them in order to build them into an image, I would be happy to help.

OpenWRT still loads firmware files from /lib/firmware. The difference is ath10k expects firmware files to be in a particular sub-directory depending on hw.

The files I had attached should go to: /lib/firmware/ath10k/QCA988X/hw2.0/

---

Can you guys try doing the following?

dd if=/dev/mtd4 of=/lib/firmware/ath10k/QCA988X/hw2.0/board.bin bs=1 count=2116 skip=20480
rmmod ath10k_pci
modprobe ath10k_pci

The mtd4 partition contains calibration data from what I understand.

comment:15 Changed 4 years ago by anonymous

For anyone trying that dd command above the 'skip=20480' should also be part of that command.

comment:16 Changed 4 years ago by skandalfo

I have the same hardware and the same problem. I tried the firmware files attached above, with and without overwriting the calibration data via the dd command.

I get the same messages in the kernel logs:

[ 1002.080000] ath10k_pci 0000:01:00.0: BAR 0: assigned [mem 0x12000000-0x121fffff 64bit]
[ 1002.390000] ath10k: pci irq legacy irq_mode 0 reset_mode 0
[ 1002.490000] ath10k: otp calibration failed: 2
[ 1002.490000] ath10k: failed to run otp: -22
[ 1002.490000] ath10k: could not init core (-22)
[ 1002.760000] ath10k: could not probe fw (-22)
[ 1002.760000] ath10k: failed to register driver core: -22
[ 1002.770000] ath10k_pci: probe of 0000:01:00.0 failed with error -22

comment:17 in reply to: ↑ 11 ; follow-up: Changed 4 years ago by anonymous

Replying to michal.kazior@…:

Can you test ath10k with the attached firmware files and report if it helps, please?

root@OpenWrt:/# dmesg|grep ath10k
[   10.650000] ath10k_pci 0000:01:00.0: BAR 0: assigned [mem 0x12000000-0x121fffff 64bit]
[   10.970000] ath10k: pci irq legacy irq_mode 0 reset_mode 0
[   10.980000] ath10k: invalid firmware magic
[   71.200000] ath10k: could not fetch firmware (-2)
[   71.200000] ath10k: could not fetch firmware files (-2)
[   71.470000] ath10k: could not probe fw (-2)
[   71.470000] ath10k: failed to register driver core: -2
[   71.470000] ath10k_pci: probe of 0000:01:00.0 failed with error -2
root@OpenWrt:/lib/firmware/ath10k/QCA988X/hw2.0# md5sum *
76006692749644937e6712a4026bb749  board.bin
676f4da0d18593ec08bfa8dc1bdd4b17  firmware-2.bin

comment:18 in reply to: ↑ 17 Changed 4 years ago by andrew

Replying to anonymous:

Replying to michal.kazior@…:

Can you test ath10k with the attached firmware files and report if it helps, please?

root@OpenWrt:/# dmesg|grep ath10k
[   10.650000] ath10k_pci 0000:01:00.0: BAR 0: assigned [mem 0x12000000-0x121fffff 64bit]
[   10.970000] ath10k: pci irq legacy irq_mode 0 reset_mode 0
[   10.980000] ath10k: invalid firmware magic
[   71.200000] ath10k: could not fetch firmware (-2)
[   71.200000] ath10k: could not fetch firmware files (-2)
[   71.470000] ath10k: could not probe fw (-2)
[   71.470000] ath10k: failed to register driver core: -2
[   71.470000] ath10k_pci: probe of 0000:01:00.0 failed with error -2
root@OpenWrt:/lib/firmware/ath10k/QCA988X/hw2.0# md5sum *
76006692749644937e6712a4026bb749  board.bin
676f4da0d18593ec08bfa8dc1bdd4b17  firmware-2.bin

Sorry – I made a mistake with wget. Tested again with the correct files:

[34709.790000] ath10k_pci 0000:01:00.0: BAR 0: assigned [mem 0x12000000-0x121fffff 64bit]
[34710.110000] ath10k: pci irq legacy irq_mode 0 reset_mode 0
[34710.200000] ath10k: otp calibration failed: 2
[34710.200000] ath10k: failed to run otp: -22
[34710.210000] ath10k: could not init core (-22)
[34710.470000] ath10k: could not probe fw (-22)
[34710.470000] ath10k: failed to register driver core: -22
[34710.470000] ath10k_pci: probe of 0000:01:00.0 failed with error -22
root@OpenWrt:/lib/firmware/ath10k/QCA988X/hw2.0# md5sum *
419d73569cb0effc0a8b380f8e4dd197  board.bin
13385cef5d83c3fa96dfaaeb69c155d9  firmware-2.bin

comment:19 Changed 4 years ago by anonymous

With rev.40799.The 5G is ok.But 2.4g is defective.Please somebody look into it.

comment:20 Changed 4 years ago by anonymous

I am also facing the same problem. In my case 5Ghz radio is not coming up. 2Ghz radio is working fine. Please have a look into it and provide solution for the same.

root@OpenWrt:/# dmesg | grep 10k
[ 9.740000] ath10k_pci 0000:01:00.0: BAR 0: assigned [mem 0x12000000-0x121fffff 64bit]
[ 10.060000] ath10k: pci irq legacy irq_mode 0 reset_mode 0
[ 10.490000] ath10k: otp calibration failed: 2
[ 10.500000] ath10k: failed to run otp: -22
[ 10.500000] ath10k: could not init core (-22)
[ 10.760000] ath10k: could not probe fw (-22)
[ 10.760000] ath10k: failed to register driver core: -22
[ 10.760000] ath10k_pci: probe of 0000:01:00.0 failed with error -22

root@OpenWrt:/# uci show wireless
wireless.radio0=wifi-device
wireless.radio0.type=mac80211
wireless.radio0.path=platform/qca955x_wmac
wireless.radio0.htmode=HT20
wireless.radio0.txpower=30
wireless.radio0.country=US
wireless.radio0.channel=auto
wireless.@wifi-iface[0]=wifi-iface
wireless.@wifi-iface[0].device=radio0
wireless.@wifi-iface[0].mode=ap
wireless.@wifi-iface[0].ssid=OpenWrt
wireless.@wifi-iface[0].encryption=none
wireless.@wifi-iface[0].network=lan
root@OpenWrt:/#

comment:21 Changed 4 years ago by anonymous

ath10k claims that they dropped the support for qca98xx (http://www.spinics.net/lists/linux-wireless/msg110852.html)

However, here I see some news about updating the firmware etc to v2: http://wireless.kernel.org/en/users/Drivers/ath10k/firmware#Update_firmware

can we go based on the information on https://github.com/kvalo/ath10k-firmware/tree/master/ and http://wireless.kernel.org/en/users/Drivers/ath10k/firmware ?

comment:22 Changed 4 years ago by anonymous

the problem is that tplink put the radio calibration data on flash, see https://dev.openwrt.org/browser/trunk/target/linux/ar71xx/files/arch/mips/ath79/mach-archer-c7.c#L62

ath10k has no way to load that, it is looking for the calibration data on eeprom

comment:23 Changed 4 years ago by Lonifer2000

+1 to this.
Good luck, and thank you all for your hard work.

comment:24 Changed 4 years ago by anonymous

A change was checked in today for nbg6716 that looks like it might be able to help if we edit that script to include this board. Here is the change: https://dev.openwrt.org/browser/trunk/target/linux/ar71xx/base-files/lib/preinit/81_load_ath10k_board_bin?rev=41562

I would prefer if someone that knows more than me can look at it before I brick my router this weekend.

comment:25 follow-up: Changed 4 years ago by anonymous

The nbg6716's fix has nothing to do with this issue.

comment:26 in reply to: ↑ 25 Changed 4 years ago by anonymous

Replying to anonymous:

The nbg6716's fix has nothing to do with this issue.

Yeah. On the Tp-Link Archer C7 V2, 'art' is on the mtd4 anyways:

mtd0: 00020000 00010000 "u-boot"
mtd1: 0010c448 00010000 "kernel"
mtd2: 00ec3bb8 00010000 "rootfs"
mtd3: 00cf0000 00010000 "rootfs_data"
mtd4: 00010000 00010000 "art"
mtd5: 00fd0000 00010000 "firmware"

comment:27 follow-up: Changed 4 years ago by fox1

At witch Position of the art mtd is the otp data?

comment:28 in reply to: ↑ 27 Changed 4 years ago by anonymous

Replying to fox1:

At witch Position of the art mtd is the otp data?

#define ARCHER_C7_WMAC_CALDATA_OFFSET 0x1000
#define ARCHER_C7_PCIE_CALDATA_OFFSET 0x5000

The first is ath9k's for 802.11n radio, the second is the one ath10k should use.

comment:29 follow-up: Changed 4 years ago by anonymous

From what I've read, there are really two options to hack functionality back in for ath10k;

1) stop it from bailing out on otp error:
comment out lines 279-284 of drivers/net/wireless/ath/ath10k/core.c
add in their place add "return ret;"

  • the actual reason for the failure is not entirely clear, but it appears that ath10k is trying to look at the pcie card itself for the otp data, which is actually located in the art partition. This means pretty much a *complete* failure of otp, but would restore to previous functionality (bad calibration), which is, realistically, equivalent to option 2.

2) prevent it from TRYING to run otp:
Comment out lines 587-589 of the same file.

What is *entirely* unclear (at least to me) is what running otp actually does, and how it compares to what is apparently the fallback mode of reading the calibration values from board.bin. In any case, I have been lead to believe that creating a custom board.bin from the content of the art partition *should* apply the proper calibration values... however, it does *NOT* appear that the mac addresses are actually located in the art partition -- in its place, "00 03 7F 00 00 00"... so... ???

Note that the MAC address from a working openwrt *is* consistent with the one at the start of board.bin. Maybe code it in manually?

comment:30 in reply to: ↑ 29 Changed 4 years ago by michal.kazior@…

Replying to anonymous:

From what I've read, there are really two options to hack functionality back in for ath10k;

1) stop it from bailing out on otp error:
comment out lines 279-284 of drivers/net/wireless/ath/ath10k/core.c
add in their place add "return ret;"

  • the actual reason for the failure is not entirely clear, but it appears that ath10k is trying to look at the pcie card itself for the otp data, which is actually located in the art partition. This means pretty much a *complete* failure of otp, but would restore to previous functionality (bad calibration), which is, realistically, equivalent to option 2.

This is not entirely correct I believe, see below.

2) prevent it from TRYING to run otp:
Comment out lines 587-589 of the same file.

What is *entirely* unclear (at least to me) is what running otp actually does, and how it compares to what is apparently the fallback mode of reading the calibration values from board.bin. In any case, I have been lead to believe that creating a custom board.bin from the content of the art partition *should* apply the proper calibration values... however, it does *NOT* appear that the mac addresses are actually located in the art partition -- in its place, "00 03 7F 00 00 00"... so... ???

Note that the MAC address from a working openwrt *is* consistent with the one at the start of board.bin. Maybe code it in manually?

The OTP data on the board doesn't contain board.bin per se. There's not enough room for one from what I know. It just contains some meta information saying what board type it is, what mac it has and some capabilities. The OTP binary itself contains a dozen of board.bin templates and one is picked based on what is found in the OTP stream on the board and then it is filled in with other specific bits (e.g. mac address).

In case of some devices the OTP stream is apparently empty (full of zeroes) which leads to error 2. In that case the board.bin data provided from the host is used. The error 2 also prevents mac address from being set up properly (I infer it's not in the OTP stream but somewhere else as UART prints have shown these boards know their mac address). That's why you end up seeing the mac from board.bin template now.

comment:31 follow-up: Changed 4 years ago by anonymous

In other words, the OTP binary (part of firmware-2.bin) is supposed to read the OTP data and effectively generate a board.bin. Same problem though, since the OTP data is stored in a location where ath10k doesn't know to look (art partition +0x5000).

And like I said, temporary hackaround has to be stopping it from bailing out on the error 2, either by preventing it from running the OTP binary, or by disregarding the error, and handing it a fallback that makes more sense than the generic template.

The part that bugs me about the way ath10k handles the failure is that in the function ath10k_download_and_run_otp(struct ath10k *ar), a comment specifically says /* OTP is optional */. If its optional, it really should NOT bail out on the error at all.

comment:32 follow-up: Changed 4 years ago by anonymous

Hmm, am I correct in understanding that the OTP firmware itself is currently responsible for knowing where to look for the OTP data?

comment:33 in reply to: ↑ 31 Changed 4 years ago by michal.kazior@…

Replying to anonymous:

In other words, the OTP binary (part of firmware-2.bin) is supposed to read the OTP data and effectively generate a board.bin. Same problem though, since the OTP data is stored in a location where ath10k doesn't know to look (art partition +0x5000).

Wrong. Art partition doesn't contain OTP stream/data at 0x5000. It contains a board.bin template for the specific board type that was originally shipped with the platform. The length of the data in the art partition seems to be 2116 which matches board.bin size. This suggests there's no additional OTP data there.


And like I said, temporary hackaround has to be stopping it from bailing out on the error 2, either by preventing it from running the OTP binary, or by disregarding the error, and handing it a fallback that makes more sense than the generic template.

In which case you end up with a mac address from the template unless you override it manually.

The part that bugs me about the way ath10k handles the failure is that in the function ath10k_download_and_run_otp(struct ath10k *ar), a comment specifically says /* OTP is optional */. If its optional, it really should NOT bail out on the error at all.

OTP *execution* is optional. OTP is just a program that prepares board information for main firmware to consume.

You're free to skip the OTP execution but then you're supposed to deliver a complete board.bin yourself (including mac address, supported bands, etc).

Ideally I'm thinking the solution is be to have 2 configuration flows:

1) don't provide board.bin template, run otp, run main fw
2) provide board.bin (e.g. via platform data), manually setup missing bits (mac address, etc)*, run main fw

  • this is the difficult part

comment:34 in reply to: ↑ 32 Changed 4 years ago by michal.kazior@…

Replying to anonymous:

Hmm, am I correct in understanding that the OTP firmware itself is currently responsible for knowing where to look for the OTP data?

Yes. OTP accesses EEPROM on the device itself via some voodoo magic. I'm not sure how (if at all) this can be done directly from the host.

comment:35 follow-up: Changed 4 years ago by anonymous

Do you have any idea where the factory firmware is getting the MAC address?

comment:36 in reply to: ↑ 35 Changed 4 years ago by michal.kazior@…

Replying to anonymous:

Do you have any idea where the factory firmware is getting the MAC address?

Unfortunately, I don't.

comment:37 Changed 4 years ago by kaloz

  • Owner changed from developers to kaloz
  • Status changed from new to accepted

comment:38 Changed 4 years ago by kaloz

  • Resolution set to fixed
  • Status changed from accepted to closed

Fixed with [41756] and [41757].

comment:39 follow-up: Changed 4 years ago by anonymous

Has this been fixed for both versions of firmware ? When I try the station version, still gets problems reminiscent of OTP failure to read.

comment:40 follow-up: Changed 4 years ago by redbeard0531@…

It is mostly working for me with the latest build as of this morning (LuCI Trunk (svn-r10459) OpenWrt Barrier Breaker r41777) but I am having a possibly related issue. I can get 5GHz channels and 802.11ac/VHT80 to work when set up in /etc/config/wireless, but LuCI treats wlan1 as 2.4GHz/bgn-only. Strangely the status shows the correct information (other than bitrate), but the config options are all wrong. If this is unrelated, I can open a new ticket.

comment:41 in reply to: ↑ 39 Changed 4 years ago by anonymous

Replying to anonymous:

Has this been fixed for both versions of firmware ? When I try the station version, still gets problems reminiscent of OTP failure to read.

I don't see how that would happen, are you sure you have the same build (except for the firmware)?

comment:42 in reply to: ↑ 40 ; follow-up: Changed 4 years ago by anonymous

Replying to redbeard0531@…:

It is mostly working for me with the latest build as of this morning (LuCI Trunk (svn-r10459) OpenWrt Barrier Breaker r41777) but I am having a possibly related issue. I can get 5GHz channels and 802.11ac/VHT80 to work when set up in /etc/config/wireless, but LuCI treats wlan1 as 2.4GHz/bgn-only. Strangely the status shows the correct information (other than bitrate), but the config options are all wrong. If this is unrelated, I can open a new ticket.

Because wlan0 is the 802.11ac interface and wlan1 is the internal 2.4GHz-only 802.11n interface.

comment:43 in reply to: ↑ 42 ; follow-up: Changed 4 years ago by anonymous

Replying to anonymous:

Replying to redbeard0531@…:

It is mostly working for me with the latest build as of this morning (LuCI Trunk (svn-r10459) OpenWrt Barrier Breaker r41777) but I am having a possibly related issue. I can get 5GHz channels and 802.11ac/VHT80 to work when set up in /etc/config/wireless, but LuCI treats wlan1 as 2.4GHz/bgn-only. Strangely the status shows the correct information (other than bitrate), but the config options are all wrong. If this is unrelated, I can open a new ticket.

Because wlan0 is the 802.11ac interface and wlan1 is the internal 2.4GHz-only 802.11n interface.

I have seen it happen where the /etc/config/wireless has all the 0's and 1's swapped the wrong way. This is totally unrelated.

comment:44 in reply to: ↑ 43 Changed 4 years ago by redbeard0531@…

Replying to anonymous:

Replying to anonymous:

Replying to redbeard0531@…:

It is mostly working for me with the latest build as of this morning (LuCI Trunk (svn-r10459) OpenWrt Barrier Breaker r41777) but I am having a possibly related issue. I can get 5GHz channels and 802.11ac/VHT80 to work when set up in /etc/config/wireless, but LuCI treats wlan1 as 2.4GHz/bgn-only. Strangely the status shows the correct information (other than bitrate), but the config options are all wrong. If this is unrelated, I can open a new ticket.

Because wlan0 is the 802.11ac interface and wlan1 is the internal 2.4GHz-only 802.11n interface.

I have seen it happen where the /etc/config/wireless has all the 0's and 1's swapped the wrong way. This is totally unrelated.

Yeah, somehow radio0 was wlan1 and vice-versa. That still left radio1/wlan0 reporting 2.4GHz only bands. When I swapped the radio numbers in /etc/config/wireless, LuCI now shows 5GHz channels on radio0/wlan0. However it reports it as "Generic MAC80211 802.11n" and only shows 802.11n options (eg HT20/40 but no VHT80), event though 802.11ac is setup in the config file and working properly. Is this a bug or is there no webgui yet for ac?

Thanks for all of your work to get 5GHz running on this router.

comment:45 Changed 4 years ago by anonymous

Mine, which hasn't been updated in a while, shows the 5 GHz as "Generic MAC80211 802.11abgn (radio0)" and the 2.4 GHz as "Generic MAC80211 802.11bgn (radio1)". There should be a setting in radio0/advanced for mode, which can be set to auto,b,g,a,g+n,a+n.

comment:46 Changed 4 years ago by anonymous

The mixed radio0/radio1 happens if you upgrade to a release with working 80211.ac wifi, given you carry over the config where you only had a single radio.

comment:47 follow-up: Changed 4 years ago by anonymous

I tried r40799 on Archer c7 v2.5G runs flawlessly.But 2.4g can not be connected!
I tried the latest trunk but result in those errors continuously!

[ 27.560000] ath10k: firmware crashed!
[ 27.560000] ath10k: hardware name qca988x hw2.0 version 0x4100016c
[ 27.570000] ath10k: firmware version: 999.999.0.636
[ 27.580000] ath10k: target register Dump Location: 0x0040AC14
[ 27.580000] ath10k: target Register Dump
[ 27.590000] ath10k: [00]: 0x4100016C 0x00000000 0x009C4521 0x00000000
[ 27.590000] ath10k: [04]: 0x009C4521 0x00060330 0x00000019 0xFFFFFFFD
[ 27.600000] ath10k: [08]: 0x00007CCB 0x00000000 0x0040CC94 0x00000020
[ 27.610000] ath10k: [12]: 0x00000000 0x00000000 0x00958360 0x0095836B
[ 27.610000] ath10k: [16]: 0x809A0978 0x0040AD94 0x00439304 0x0040D074
[ 27.620000] ath10k: [20]: 0x00000000 0x00000000 0x000249F0 0x00000001
[ 27.630000] ath10k: [24]: 0x809A0978 0x0040AD94 0x00439304 0x01F32E9D
[ 27.630000] ath10k: [28]: 0x809AD1A2 0x0040ADE4 0x00439304 0x0043F68C
[ 27.640000] ath10k: [32]: 0x809B5DA3 0x00000000 0x000000FE 0x004440FC
[ 27.650000] ath10k: [36]: 0x00000000 0x00000000 0x00000000 0x00000000
[ 27.650000] ath10k: [40]: 0x00000000 0x00000000 0x00443C54 0x00000004
[ 27.660000] ath10k: [44]: 0x00439BB8 0x00000000 0x00000000 0x00400000
[ 27.670000] ath10k: [48]: 0x809AE0B4 0x0040AE04 0x00400000 0x0043F68C
[ 27.670000] ath10k: [52]: 0x00000001 0x00000000 0x004231F0 0x00400000
[ 27.680000] ath10k: [56]: 0x809AE17E 0x0040AE44 0x0040FE6C 0x0040D310
[ 28.630000] br-lan: port 3(wlan1) entered forwarding state
[ 30.690000] ath10k: failed to to request monitor vdev 1 stop: -11
[ 35.690000] ath10k: failed to synchronise monitor vdev 1: -145
[ 35.690000] ath10k: failed to stop monitor vdev: -145
[ 38.700000] ath10k: failed to request wmi monitor vdev 1 removal: -11
[ 38.700000] ath10k: failed to delete monitor vdev: -11
[ 39.230000] ieee80211 phy0: Hardware restart was requested
[ 39.670000] ath10k: otp stream is empty, using board.bin contents
[ 40.780000] ath10k: device successfully recovered
[ 41.790000] ath10k: firmware crashed!
[ 41.790000] ath10k: hardware name qca988x hw2.0 version 0x4100016c
[ 41.800000] ath10k: firmware version: 999.999.0.636
[ 41.800000] ath10k: target register Dump Location: 0x0040AC14
[ 41.810000] ath10k: target Register Dump
[ 41.810000] ath10k: [00]: 0x4100016C 0x00000000 0x009C4521 0x00000000
[ 41.820000] ath10k: [04]: 0x009C4521 0x00060330 0x00000019 0x0040F948
[ 41.830000] ath10k: [08]: 0x0000B30E 0x00000000 0x0040CC94 0x00000020
[ 41.830000] ath10k: [12]: 0x00000000 0x00000000 0x00958360 0x0095836B
[ 41.840000] ath10k: [16]: 0x809A0978 0x0040AD94 0x00439304 0x0040D074
[ 41.850000] ath10k: [20]: 0x00412EB0 0x121134F0 0x0000001C 0x0043E8D4
[ 41.850000] ath10k: [24]: 0x809A0978 0x0040AD94 0x00439304 0x02CC38CC
[ 41.860000] ath10k: [28]: 0x809AD1A2 0x0040ADE4 0x00439304 0x0043F6FC
[ 41.870000] ath10k: [32]: 0x809B01DA 0x00000001 0x00410110 0x0041937C
[ 41.870000] ath10k: [36]: 0x00000000 0x00000000 0x00000000 0x00000000
[ 41.880000] ath10k: [40]: 0x00000000 0x00000000 0x0040AE38 0x00412718
[ 41.890000] ath10k: [44]: 0x00439C00 0x00000000 0x00000000 0x00400000
[ 41.890000] ath10k: [48]: 0x809AE0B4 0x0040AE04 0x00400000 0x0043F6FC
[ 41.900000] ath10k: [52]: 0x00000001 0x00000000 0x004231F0 0x00400000
[ 41.900000] ath10k: [56]: 0x809AE17E 0x0040AE44 0x0040FE6C 0x0040D310

comment:48 follow-up: Changed 4 years ago by anatol.pomozov@…

I just installed OpenWRT (OpenWrt Barrier Breaker r41846 / LuCI Trunk (svn-r10459)) on my new Archer C7 V2 and I see only 2.4GHz network.

# dmesg | grep wlan
[  284.220000] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[  284.220000] device wlan0 entered promiscuous mode
[  284.240000] br-lan: port 2(wlan0) entered forwarding state
[  284.250000] br-lan: port 2(wlan0) entered forwarding state
[  284.250000] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[  286.250000] br-lan: port 2(wlan0) entered forwarding state
[  375.390000] device wlan0 left promiscuous mode
[  375.390000] br-lan: port 2(wlan0) entered disabled state
[  376.580000] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[  376.650000] device wlan0 entered promiscuous mode
[  377.480000] br-lan: port 2(wlan0) entered forwarding state
[  377.490000] br-lan: port 2(wlan0) entered forwarding state
[  377.490000] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[  379.490000] br-lan: port 2(wlan0) entered forwarding state
# cat /etc/config/wireless 

config wifi-device 'radio0'
	option type 'mac80211'
	option channel '11'
	option hwmode '11g'
	option path 'platform/qca955x_wmac'
	option htmode 'HT20'
	option txpower '30'
	option country 'US'

config wifi-iface
	option device 'radio0'
	option network 'lan'
	option mode 'ap'
	option ssid 'MYNETWORK'
	option encryption 'psk2'
	option key 'foobar'

What can be wrong with the device? 5Ghz worked fine on OEM firmware.

comment:49 Changed 4 years ago by anonymous

When I mentioned in my previous comment (https://dev.openwrt.org/ticket/16589#comment:48) that I "installed" OpenWRT I mean the quick start guide http://wiki.openwrt.org/toh/tp-link/tl-wdr7500#quick.start.guide

The forum wisdom says there are additional steps should be done https://forum.openwrt.org/viewtopic.php?id=44201&p=20

What are the current official instructions for Archer C7 V2? I would really love to get OpenWRT+5GHz at my new router.

comment:50 in reply to: ↑ 47 Changed 4 years ago by michal.kazior@…

Replying to anonymous:

I tried r40799 on Archer c7 v2.5G runs flawlessly.But 2.4g can not be connected!
I tried the latest trunk but result in those errors continuously!

[ 27.560000] ath10k: firmware crashed!
[ 27.560000] ath10k: hardware name qca988x hw2.0 version 0x4100016c
[ 27.570000] ath10k: firmware version: 999.999.0.636
[ 27.580000] ath10k: target register Dump Location: 0x0040AC14
[ 27.580000] ath10k: target Register Dump
[ 27.590000] ath10k: [00]: 0x4100016C 0x00000000 0x009C4521 0x00000000
[ 27.590000] ath10k: [04]: 0x009C4521 0x00060330 0x00000019 0xFFFFFFFD
[ 27.600000] ath10k: [08]: 0x00007CCB 0x00000000 0x0040CC94 0x00000020
[ 27.610000] ath10k: [12]: 0x00000000 0x00000000 0x00958360 0x0095836B
[ 27.610000] ath10k: [16]: 0x809A0978 0x0040AD94 0x00439304 0x0040D074
[ 27.620000] ath10k: [20]: 0x00000000 0x00000000 0x000249F0 0x00000001
[ 27.630000] ath10k: [24]: 0x809A0978 0x0040AD94 0x00439304 0x01F32E9D
[ 27.630000] ath10k: [28]: 0x809AD1A2 0x0040ADE4 0x00439304 0x0043F68C
[ 27.640000] ath10k: [32]: 0x809B5DA3 0x00000000 0x000000FE 0x004440FC
[ 27.650000] ath10k: [36]: 0x00000000 0x00000000 0x00000000 0x00000000
[ 27.650000] ath10k: [40]: 0x00000000 0x00000000 0x00443C54 0x00000004
[ 27.660000] ath10k: [44]: 0x00439BB8 0x00000000 0x00000000 0x00400000
[ 27.670000] ath10k: [48]: 0x809AE0B4 0x0040AE04 0x00400000 0x0043F68C
[ 27.670000] ath10k: [52]: 0x00000001 0x00000000 0x004231F0 0x00400000
[ 27.680000] ath10k: [56]: 0x809AE17E 0x0040AE44 0x0040FE6C 0x0040D310
[ 28.630000] br-lan: port 3(wlan1) entered forwarding state
[ 30.690000] ath10k: failed to to request monitor vdev 1 stop: -11
[ 35.690000] ath10k: failed to synchronise monitor vdev 1: -145
[ 35.690000] ath10k: failed to stop monitor vdev: -145
[ 38.700000] ath10k: failed to request wmi monitor vdev 1 removal: -11
[ 38.700000] ath10k: failed to delete monitor vdev: -11

You're trying to use the main firmware branch for AP - that's not going to work well.

There's a known bug with main firmware and monitor (started when an interface is set to promiscuous mode, e.g. when adding an interface to a bridge) crashing often.

Try using the 10.x branch firmware please.

comment:51 in reply to: ↑ 48 Changed 4 years ago by michal.kazior@…

Replying to anatol.pomozov@…:

I just installed OpenWRT (OpenWrt Barrier Breaker r41846 / LuCI Trunk (svn-r10459)) on my new Archer C7 V2 and I see only 2.4GHz network.

# dmesg | grep wlan
[  284.220000] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[  284.220000] device wlan0 entered promiscuous mode
[  284.240000] br-lan: port 2(wlan0) entered forwarding state
[  284.250000] br-lan: port 2(wlan0) entered forwarding state
[  284.250000] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[  286.250000] br-lan: port 2(wlan0) entered forwarding state
[  375.390000] device wlan0 left promiscuous mode
[  375.390000] br-lan: port 2(wlan0) entered disabled state
[  376.580000] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[  376.650000] device wlan0 entered promiscuous mode
[  377.480000] br-lan: port 2(wlan0) entered forwarding state
[  377.490000] br-lan: port 2(wlan0) entered forwarding state
[  377.490000] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[  379.490000] br-lan: port 2(wlan0) entered forwarding state

This filtered output is useless. Can you provide full dmesg, please?

comment:52 follow-up: Changed 4 years ago by anatolik

This filtered output is useless. Can you provide full dmesg, please?

I installed 'opkg install kmod-ath10k' as mentioned at the forum. Now at network->wifi UI page I see two radios: radio0 (802.11n) and radio1(802.11bgn). radio0 works at 2.4GHz, but I cannot enable radio1... And why it is not a 802.11ac radio??

Anyway here are dmesg https://gist.github.com/anatol/abb0751e09f82561e1cf and system logs https://gist.github.com/anatol/8fdfb1178935ce771249

comment:53 in reply to: ↑ 52 ; follow-up: Changed 4 years ago by michal.kazior@…

Replying to anatolik:

This filtered output is useless. Can you provide full dmesg, please?

I installed 'opkg install kmod-ath10k' as mentioned at the forum. Now at network->wifi UI page I see two radios: radio0 (802.11n) and radio1(802.11bgn). radio0 works at 2.4GHz, but I cannot enable radio1... And why it is not a 802.11ac radio??

Anyway here are dmesg https://gist.github.com/anatol/abb0751e09f82561e1cf and system logs https://gist.github.com/anatol/8fdfb1178935ce771249

Thanks. Can you paste iw list, uci show wireless, iwinfo and cat /var/run/hostapd-phy0.conf too, please?

comment:55 in reply to: ↑ 54 Changed 4 years ago by michal.kazior@…

Replying to anatolik:

Replying to michal.kazior@…:

Thanks. Can you paste iw list, uci show wireless, iwinfo and cat /var/run/hostapd-phy0.conf too, please?

https://gist.github.com/anatol/2d25e25b9403cf012901
https://gist.github.com/anatol/3e934b48dbe555692d43
https://gist.github.com/anatol/cb06476db109e5ed99f9
https://gist.github.com/anatol/966fdb52c031a53f1085
https://gist.github.com/anatol/ac888f3a303011ac1913

Hopefully it will be useful.

Thanks.

ath10k advertises bands correctly (i.e. 5GHz).

UCI configuration and hostapd.conf have incorrect hwmode set - 11g. This should be at least 11a. You also have channel 36 set for ath10k device.

Not sure how you ended up with this, but this isn't correct.

Try: uci set wireless.radio1.hwmode=11a; uci commit wireless; wifi.

comment:56 follow-up: Changed 4 years ago by xbarmar

I'm note sure if this is the case here, since the wireless config has the radio1 (11ac device) present. Maybe you added it manually(?)..

I remember a problem with detecting the 11ac card from the init.d/boot script after the ath10k patch for registering the ath10k_core async. I worked around this by increasing the delay before wifi detect.

--- a/package/base-files/files/etc/init.d/boot
+++ b/package/base-files/files/etc/init.d/boot
@@ -56,7 +56,7 @@ boot() {

/sbin/kmodloader

# allow wifi modules time to settle

  • sleep 1

+ sleep 2

/sbin/wifi detect > /tmp/wireless.tmp
[ -s /tmp/wireless.tmp ] && {

What will 'wifi detect' return if you trigger it manually? Will it return correct hwmode?

comment:57 in reply to: ↑ 56 Changed 4 years ago by xbarmar

Replying to xbarmar:

I'm note sure if this is the case here, since the wireless config has the radio1 (11ac device) present. Maybe you added it manually(?)..

I remember a problem with detecting the 11ac card from the init.d/boot script after the ath10k patch for registering the ath10k_core async. I worked around this by increasing the delay before wifi detect.

--- a/package/base-files/files/etc/init.d/boot
+++ b/package/base-files/files/etc/init.d/boot
@@ -56,7 +56,7 @@ boot() {

/sbin/kmodloader

# allow wifi modules time to settle

  • sleep 1

+ sleep 2

/sbin/wifi detect > /tmp/wireless.tmp
[ -s /tmp/wireless.tmp ] && {

What will 'wifi detect' return if you trigger it manually? Will it return correct hwmode?

Most likely what I wrote above it's not the root cause, as the release you used does have a mac80211 package from '2014-05-22' afaics, so the 'ath10k_core async registering patch' is not yet there.

(I used a custom backports/mac80211 package with bleeding-edge ath10k code)

comment:58 follow-up: Changed 4 years ago by anatolik

What will 'wifi detect' return if you trigger it manually?

It returns nothing, error code is 0. I looked at /sbin/wifi file and see that $DRIVERS is empty and do not see where it is set.

So currently UI shows radio0 and radio1. Radio1 is detected as 5Ghz - it appeared after I installed kmod-ath10k using opkg. But I cannot connect to this channel. If I try to change the password it gets disabled: 'Wireless is disabled or not associated'.

I tried to update all packages in 'opkg list-upgradable' and make sysupgrade - still the same issue. Here is result of 'list-installed' https://gist.github.com/anatol/fa6a7535122d08e8ca6e

Last edited 4 years ago by anatolik (previous) (diff)

comment:59 in reply to: ↑ 58 Changed 4 years ago by anonymous

Replying to anatolik:

What will 'wifi detect' return if you trigger it manually?

It returns nothing, error code is 0. I looked at /sbin/wifi file and see that $DRIVERS is empty and do not see where it is set.

I just checked - you need to remove /etc/config/wireless file prior you run 'wifi detect' - to get an output. If it returns correct values you may redirect the output back there: 'wifi detect > /etc/config/wireless'

So currently UI shows radio0 and radio1. Radio1 is detected as 5Ghz - it appeared after I installed kmod-ath10k using opkg. But I cannot connect to this channel. If I try to change the password it gets disabled: 'Wireless is disabled or not associated'.

I would not start with UI (web interface?) at this point, but rather with 'uci' and wifi up/down. Here's my config, but as I said - I'm using a but customized version of openwrt - a but old baseline, so the mac80211.sh may faced some problems with at your end if taken as is.

config wifi-device radio0

option type mac80211
option channel 36
option hwmode 11acna
option path 'pci0000:00/0000:00:00.0'
option htmode HT40+
list ht_capab LDPC
list ht_capab SHORT-GI-20
list ht_capab SHORT-GI-40
list ht_capab TX-STBC
list ht_capab RX-STBC1
list ht_capab DSSS_CCK-40
option vhtmode VHT80
list vht_capab MAX-MPDU-11454
list vht_capab RXLDPC
list vht_capab SHORT-GI-80
list vht_capab TX-STBC-2BY1
list vht_capab RX-STBC-1
list vht_capab MAX-A-MPDU-LEN-EXP7
list vht_capab RX-ANTENNA-PATTERN
list vht_capab TX-ANTENNA-PATTERN

config wifi-iface

option device radio0
option network lan
option mode ap
option ssid OpenWrt
option encryption none
option maxassoc 128
option uapsd 1


I tried to update all packages in 'opkg list-upgradable' and make sysupgrade - still the same issue. Here is result of 'list-installed' https://gist.github.com/anatol/fa6a7535122d08e8ca6e

comment:60 follow-up: Changed 4 years ago by xbarmar

I've re-compiled the latest trunk (vanilla) and tried what I wrote above.
@anatolik - maybe you will find this helpfull for your case: http://pastebin.com/r22wzDkA

comment:61 in reply to: ↑ 60 ; follow-ups: Changed 4 years ago by anatolik

Thanks everyone for your help. I removed /etc/config/wireless and regenerated it. Now my computers can see 5GHz network. But any attempt to modify 5Ghz network settings via UI breaks it.

I also suggest to update the wiki page and include information about installing 'kmod-ath10k' package.

root@OpenWrt:/etc/config# cat wireless
config wifi-device  radio0
	option type     mac80211
	option channel  36
	option hwmode   11a
	option path	'pci0000:01/0000:01:00.0'
	option htmode   VHT80

config wifi-iface
	option device radio0
	option network lan
	option mode ap
	option ssid BARFOO1
	option encryption psk2
	option key foobar

config wifi-device 'radio1'
	option type 'mac80211'
	option channel '11'
	option hwmode '11g'
	option path 'platform/qca955x_wmac'
	option htmode 'HT20'

config wifi-iface
	option device 'radio1'
	option network 'lan'
	option mode 'ap'
	option ssid 'BARFOO2'
	option encryption 'psk2'
	option key 'foobar'
root@OpenWrt:/etc/config# iwinfo 
wlan0     ESSID: "BARFOO1"
          Access Point: E8:94:F6:AE:14:5E
          Mode: Master  Channel: 36 (5.180 GHz)
          Tx-Power: 17 dBm  Link Quality: 27/70
          Signal: -83 dBm  Noise: -102 dBm
          Bit Rate: 6.0 MBit/s
          Encryption: WPA2 PSK (CCMP)
          Type: nl80211  HW Mode(s): 802.11nac
          Hardware: 168C:003C 0000:0000 [Generic MAC80211]
          TX power offset: unknown
          Frequency offset: unknown
          Supports VAPs: yes  PHY name: phy0

wlan1     ESSID: "BARFOO2"
          Access Point: E8:94:F6:AE:14:5F
          Mode: Master  Channel: 11 (2.462 GHz)
          Tx-Power: 23 dBm  Link Quality: unknown/70
          Signal: unknown  Noise: -95 dBm
          Bit Rate: unknown
          Encryption: WPA2 PSK (CCMP)
          Type: nl80211  HW Mode(s): 802.11bgn
          Hardware: unknown [Generic MAC80211]
          TX power offset: unknown
          Frequency offset: unknown
          Supports VAPs: yes  PHY name: phy1

It reports BitRate == 6Mbit/s. Is it very low rate?

Last edited 4 years ago by anatolik (previous) (diff)

comment:62 in reply to: ↑ 61 Changed 4 years ago by michal.kazior@…

Replying to anatolik:

Thanks everyone for your help. I removed /etc/config/wireless and regenerated it. Now my computers can see 5GHz network. But any attempt to modify 5Ghz network settings via UI breaks it.

I also suggest to update the wiki page and include information about installing 'kmod-ath10k' package.

[...]

root@OpenWrt:/etc/config# iwinfo 
wlan0     ESSID: "BARFOO1"
          Access Point: E8:94:F6:AE:14:5E
          Mode: Master  Channel: 36 (5.180 GHz)
          Tx-Power: 17 dBm  Link Quality: 27/70
          Signal: -83 dBm  Noise: -102 dBm
          Bit Rate: 6.0 MBit/s
          Encryption: WPA2 PSK (CCMP)
          Type: nl80211  HW Mode(s): 802.11nac
          Hardware: 168C:003C 0000:0000 [Generic MAC80211]
          TX power offset: unknown
          Frequency offset: unknown
          Supports VAPs: yes  PHY name: phy0

It reports BitRate == 6Mbit/s. Is it very low rate?

http://wireless.kernel.org/en/users/Drivers/ath10k:

Known bugs/limitations

  • tx rate is reported as 6mbps due to firmware limitation (no tx rate information in tx completions); instead see /sys/kernel/debug/ieee80211/phyX/ath10k/fw_stats

comment:63 in reply to: ↑ 61 ; follow-up: Changed 4 years ago by xbarmar

Replying to anatolik:

[...]

But any attempt to modify 5Ghz network settings via UI breaks it.

AFAICS luCI does not have yet any implementation for 802.11ac (luci/modules/admin-full/luasrc/model/cbi/admin_network/wifi.lua)..

comment:64 in reply to: ↑ 63 Changed 4 years ago by anatolik

Replying to xbarmar:

AFAICS luCI does not have yet any implementation for 802.11ac (luci/modules/admin-full/luasrc/model/cbi/admin_network/wifi.lua)..

I created a separate ticket to track 802.11AC+Luci progress #17323 . Could anyone who has experience with Luci code look at that issue? I promise to test the changes and provide feedback quickly.

comment:65 Changed 4 years ago by anatolik

Also could you please add kmod-ath10k module to openwrt image? openwrt-ar71xx-generic-archer-c7-v2-squashfs-factory.bin

comment:66 follow-up: Changed 3 years ago by anonymous

Even with this OTP fix, the adhoc mode does not seem to be working (using STA firmware). The stations do not associate fully, and the RX and TX rate seem to be stuck at 6 Mbps.Has anyone tested the adhoc mode with this firmware ?

comment:67 Changed 3 years ago by anonymous

The reason for adhoc mode not working seems to be that antennas are not configured correctly. The available antennas for TX and RX is 0.

Wiphy phy0

max # scan SSIDs: 16
max scan IEs length: 199 bytes
Retry short limit: 7
Retry long limit: 4
Coverage class: 0 (up to 0m)
Device supports AP-side u-APSD.
Available Antennas: TX 0 RX 0
Supported interface modes:

  • IBSS
  • managed
  • AP
  • AP/VLAN
  • monitor
  • P2P-client
  • P2P-GO

Band 2:

Capabilities: 0x19e3

RX LDPC
HT20/HT40
Static SM Power Save
RX HT20 SGI
RX HT40 SGI
TX STBC
RX STBC 1-stream
Max AMSDU length: 7935 bytes
DSSS/CCK HT40

Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: 8 usec (0x06)
HT TX/RX MCS rate indexes supported: 0-23
VHT Capabilities (0x338001b2):

Max MPDU length: 11454
Supported Channel Width: neither 160 nor 80+80
RX LDPC
short GI (80 MHz)
TX STBC
RX antenna pattern consistency
TX antenna pattern consistency

VHT RX MCS set:

1 streams: MCS 0-9
2 streams: MCS 0-9
3 streams: MCS 0-9
4 streams: not supported
5 streams: not supported
6 streams: not supported
7 streams: not supported
8 streams: not supported

VHT RX highest supported: 0 Mbps
VHT TX MCS set:

1 streams: MCS 0-9
2 streams: MCS 0-9
3 streams: MCS 0-9
4 streams: not supported
5 streams: not supported
6 streams: not supported
7 streams: not supported
8 streams: not supported

VHT TX highest supported: 0 Mbps
Frequencies:

  • 5180 MHz [36] (17.0 dBm)
  • 5200 MHz [40] (17.0 dBm)
  • 5220 MHz [44] (17.0 dBm)
  • 5240 MHz [48] (17.0 dBm)
  • 5260 MHz [52] (23.0 dBm) (no IR, radar detection) DFS state: usable (for 1131 sec) DFS CAC time: 60000 ms
  • 5280 MHz [56] (23.0 dBm) (no IR, radar detection) DFS state: usable (for 1131 sec) DFS CAC time: 60000 ms
  • 5300 MHz [60] (23.0 dBm) (no IR, radar detection) DFS state: usable (for 1131 sec) DFS CAC time: 60000 ms
  • 5320 MHz [64] (23.0 dBm) (no IR, radar detection) DFS state: usable (for 1131 sec) DFS CAC time: 60000 ms
  • 5500 MHz [100] (disabled)
  • 5520 MHz [104] (disabled)
  • 5540 MHz [108] (disabled)
  • 5560 MHz [112] (disabled)
  • 5580 MHz [116] (disabled)
  • 5600 MHz [120] (disabled)
  • 5620 MHz [124] (disabled)
  • 5640 MHz [128] (disabled)
  • 5660 MHz [132] (disabled)
  • 5680 MHz [136] (disabled)
  • 5700 MHz [140] (disabled)
  • 5745 MHz [149] (30.0 dBm)
  • 5765 MHz [153] (30.0 dBm)
  • 5785 MHz [157] (30.0 dBm)
  • 5805 MHz [161] (30.0 dBm)
  • 5825 MHz [165] (30.0 dBm)

valid interface combinations:

  • #{ managed, P2P-client } <= 8, #{ P2P-GO } <= 3, #{ AP } <= 7, total <= 8, #channels <= 1, STA/AP BI must match

HT Capability overrides:

  • MCS: ff ff ff ff ff ff ff ff ff ff
  • maximum A-MSDU length
  • supported channel width
  • short GI for 40 MHz
  • max A-MPDU length exponent
  • min MPDU start spacing

comment:68 follow-ups: Changed 3 years ago by aaron@…

The speeds I'm getting from ath10k are rather slow:

Device Archer C7_V2_131217 OpenWrt Barrier Breaker 14.07-rc3 / LuCI Trunk (svn-r10467) w/ ath10k 3.10.49+2014-05-22-1
802.11n 2.4ghz (2010 Macbook Pro) 86.96 93.06
802.11n 5ghz (2010 Macbook Pro) 191.4 138.6
802.11n 2.4ghz (HTC One X) 48.74 43.56
802.11n 5ghz (HTC One X) 49.92 108.2
802.11n 2.4ghz (2014 Macbook Air) 111.2 103.8
802.11ac 5ghz (2014 Macbook Air) 432.6 139.6

All results are a mean (n=5) in mbit/s, taken using iperf 2.0.5. I have gigabit speeds for the wired network.

Column 1 shows the wireless mode I was testing and the device.
Column 2 shows the speeds attained on the TP-Link firmware version C7_V2_131217.
Column 3 shows the speeds attained on the OpenWRT (14.07-rc3) with ath10k 3.10.49+2014-5-22-1

Here is some info about my wifi configs: https://gist.github.com/promythyus/3636d4cd4c65668edb1d

Any chance we'll see a fix for this? It'd be nice to be achieving the same speeds as stock.

comment:69 in reply to: ↑ 68 Changed 3 years ago by anonymous

Why is RX antenna and TX antenna 0 for phy 0 ? This may explain the difference. I am getting the same in my Archer C7.

Replying to aaron@…:

The speeds I'm getting from ath10k are rather slow:

Device Archer C7_V2_131217 OpenWrt Barrier Breaker 14.07-rc3 / LuCI Trunk (svn-r10467) w/ ath10k 3.10.49+2014-05-22-1
802.11n 2.4ghz (2010 Macbook Pro) 86.96 93.06
802.11n 5ghz (2010 Macbook Pro) 191.4 138.6
802.11n 2.4ghz (HTC One X) 48.74 43.56
802.11n 5ghz (HTC One X) 49.92 108.2
802.11n 2.4ghz (2014 Macbook Air) 111.2 103.8
802.11ac 5ghz (2014 Macbook Air) 432.6 139.6

All results are a mean (n=5) in mbit/s, taken using iperf 2.0.5. I have gigabit speeds for the wired network.

Column 1 shows the wireless mode I was testing and the device.
Column 2 shows the speeds attained on the TP-Link firmware version C7_V2_131217.
Column 3 shows the speeds attained on the OpenWRT (14.07-rc3) with ath10k 3.10.49+2014-5-22-1

Here is some info about my wifi configs: https://gist.github.com/promythyus/3636d4cd4c65668edb1d

Any chance we'll see a fix for this? It'd be nice to be achieving the same speeds as stock.

comment:70 in reply to: ↑ 66 Changed 3 years ago by michal.kazior@…

Replying to anonymous:

Even with this OTP fix, the adhoc mode does not seem to be working (using STA firmware). The stations do not associate fully, and the RX and TX rate seem to be stuck at 6 Mbps.Has anyone tested the adhoc mode with this firmware ?

If memory serves right IBSS has broken hw rate control. You should look though ath10k mailing list for more info.

comment:71 in reply to: ↑ 68 Changed 3 years ago by michal.kazior@…

Replying to aaron@…:

The speeds I'm getting from ath10k are rather slow:

Device Archer C7_V2_131217 OpenWrt Barrier Breaker 14.07-rc3 / LuCI Trunk (svn-r10467) w/ ath10k 3.10.49+2014-05-22-1
802.11n 2.4ghz (2010 Macbook Pro) 86.96 93.06
802.11n 5ghz (2010 Macbook Pro) 191.4 138.6
802.11n 2.4ghz (HTC One X) 48.74 43.56
802.11n 5ghz (HTC One X) 49.92 108.2
802.11n 2.4ghz (2014 Macbook Air) 111.2 103.8
802.11ac 5ghz (2014 Macbook Air) 432.6 139.6

All results are a mean (n=5) in mbit/s, taken using iperf 2.0.5. I have gigabit speeds for the wired network.

By the looks of it this should be fixed in the latest upstream code. Not sure when OpenWRT will pull these changes.

comment:72 Changed 3 years ago by xa

Whats the word on this? I'm new to openwrt, and its not clear from the wiki that there is anything speical that needs doing after installing 14.07-rc3. If I need not use the web interface, no trouble, but whatever config needs plopping into /etc/config/wireless would be appreciated. Should I expect an rc4 to contain a working 5ghz system for the archer c7?

comment:73 Changed 3 years ago by anonymous

I believe it is just a matter of enabling 80 Mhz channels in the ac mode, which would definitely increase speed, not to mention when using 3 of them simultaneously, as it is allowed by the specification. I believe it should already be supported by the driver, but I am not sure how to activate it. One thing that is quite obvious: it cannot be done from the LuCi gui at the moment.

comment:74 follow-up: Changed 3 years ago by anonymous

The latest OpenWRT release supports 80Mhz ac mode but speed appears limited. My Internet connection is 50/15 but through ath10k I get 50/6 so the upload is having issues somehow.

comment:75 in reply to: ↑ 74 Changed 3 years ago by anonymous

Downloading firmware-3.bin to /lib/firmware/ath10k/QCA988X/hw2.0/ helped improved the Wifi performance on the latest trunk.

https://github.com/kvalo/ath10k-firmware/blob/master/10.2/firmware-3.bin_10.2-00082-4-2

comment:76 Changed 3 years ago by anonymous

How do you install the firmware-3.bin? Did you rename it to firmware-2.bin or leave it as firmware-3.bin? OpenWRT doesn't seem to pick up firmware-3.bin on system, defaulting to v2 API.

comment:77 Changed 3 years ago by aaron@…

It would seem this change has been pulled into trunk, so just grab the latest image?
/changeset/42768.html

comment:78 Changed 3 years ago by anonymous

Looking forward to hear some updates on this before buying the C7.

comment:79 Changed 3 years ago by anonymous

With the latest trunk build I'm seeing 1300Mbps 5Ghz connections to the Archer C7. Most things work fine, however I'm very confused about not being able to connect to some websites, such as netflix.com or newegg.com. If I switch to the 2.4Ghz ath9k network, everything works fine and browsers load those sites instantly. Is OpenWRT using the very latest ath10k code?

comment:80 Changed 3 years ago by skandalfo

I've experienced the same (not with the newest version, but some time ago): pages with complex content having to do a number of HTTP requests would stall while on the 5GHz band, but the same page would load instantly on the 2.4GHz band.

I verified this with at least two clients, so I suspect there's some kind of packet loss or corruption on the 5GHz band, but I didn't manage to get a packet capture at the time that would tell me what the problem was.

I might try again at some point, but my time budget for this kind of thing is small, and at the time I just turned off the 5GHz band.

EDIT: Grammar/typos.

Last edited 3 years ago by skandalfo (previous) (diff)

comment:81 Changed 3 years ago by anonymous

  • Resolution fixed deleted
  • Status changed from closed to reopened

I can confirm the same issue. ath10k is unreliable on both Barrier Breaker and Chaos Calmer. I tried different firmware versions and it made no difference, so it's most likely the ath10k driver.

comment:82 Changed 3 years ago by anonymous

Same issue here also (Archer C5, but same hardware)

It also affects the iPhone ebay app "Network error", and as soon as 5GHz is disabled, it opens fine & websites all work again.

comment:83 Changed 3 years ago by anonymous

5GHz works for my Archer C7 v2, but speeds are lower than native firmware, sometimes much lower. I posted in the forums here:

https://forum.openwrt.org/viewtopic.php?pid=252476

So it seems there's nothing to be done by the OpenWRT devs until ath10k is "fixed"?

comment:84 Changed 3 years ago by anonymous

Essentially any firmware after OpenWrt Barrier Breaker r40698 / LuCI Trunk (svn-r10265) in June 2014 is unusable due to ath10k's unbearably slow wireless speeds. I have tried to update to the newest build several times since then, but I always return to my custom compiled r40698 since the 5ghz wifi speed is roughly cut in half with anything later than that build.

comment:85 Changed 3 years ago by anonymous

Seeing the same slow speeds on the 5g band with bb the archer c7v2 a bit less then half of stock firmware I did enable 80 and still see the slowdown any chance of a update soon to help this?

comment:86 follow-up: Changed 3 years ago by anonymous

Is there any news about how works going. 5GHz working or not?

comment:87 in reply to: ↑ 86 Changed 3 years ago by anonymous

Replying to anonymous:

Is there any news about how works going. 5GHz working or not?

Working perfectly. Using currently Chaos Calmer r43602 (trunk). Speed on 5Ghz similar to the factory firmware.

comment:88 Changed 3 years ago by anonymous

You must install additional package: kmod-ath10k after the initial install of the openwrt trunk image.

comment:89 Changed 3 years ago by nbd

  • Resolution set to worksforme
  • Status changed from reopened to closed

comment:90 Changed 3 years ago by adub

It should be noted that there is a newer firmware version available then what is currently used in OpenWRT.

firmware-4.bin is now available here: https://github.com/kvalo/ath10k-firmware/tree/master/10.2.4

comment:91 follow-up: Changed 3 years ago by anonymous

What should I do after copying firmware-4.bin into /lib/.../QCA988X/hw2.0 ? Any other change needed? Does it loads auto on barrier breaker? If not, what should I do after? Sorry, I'm a newbie one...

comment:92 in reply to: ↑ 91 Changed 3 years ago by anonymous

Replying to anonymous:

What should I do after copying firmware-4.bin into /lib/.../QCA988X/hw2.0 ? Any other change needed? Does it loads auto on barrier breaker? If not, what should I do after? Sorry, I'm a newbie one...

I don't think you can just copy over and rename the firmware-4.bin to firmware-3.bin. I believe there are API changes which requires the corresponding version of ath10k, which isn't in trunk yet. Hopefully soon?

comment:93 Changed 3 years ago by davebytes

why was this closed? I see ONE report of 'working perfectly' after a string of problem reports, and recent note about an even newer ath10k firmware.

I'd love to see the new firmware tested and integrated, and more reports of it all working equal or better to stock, before I go zap my brand new router!

comment:94 follow-up: Changed 3 years ago by satadru@…

The current trunk builds (as of January 27, 2015) no longer have a working kmod-ath10k package available. I see a firmware loading error in the dmesg:

[ 528.400000] ath10k_pci 0000:01:00.0: pci irq legacy interrupts 0 irq_mode 0 reset_mode 0
[ 528.750000] ath10k_pci 0000:01:00.0: Direct firmware load failed with error -2
[ 528.750000] ath10k_pci 0000:01:00.0: Falling back to user helper
[ 528.890000] ath10k_pci 0000:01:00.0: otp stream is empty, using board.bin contents
[ 530.060000] ath10k_pci 0000:01:00.0: qca988x hw2.0 (0x4100016c, 0x043202ff) fw 10.2-00082-4-2 api 3 htt 2.1 wmi 65.109.0.0 cal otp
[ 530.070000] ath10k_pci 0000:01:00.0: debug 0 debugfs 1 tracing 0 dfs 1 testmode 1
[ 530.680000] ath: EEPROM regdomain: 0x0
[ 530.680000] ath: EEPROM indicates default country code should be used
[ 530.690000] ath: doing EEPROM country->regdmn map search
[ 530.690000] ath: country maps to regdmn code: 0x3a
[ 530.700000] ath: Country alpha2 being used: US
[ 530.700000] ath: Regpair used: 0x3a

comment:95 in reply to: ↑ 94 Changed 3 years ago by anonymous

Here's how you fix the current firmware loading issue with trunk for ath10k:

Download this firmware to your local computer:
https://github.com/kvalo/ath10k-firmware/blob/master/10.2.4/untested/firmware-3.bin_10.2.4.13-1

Then copy it to the router's firmware directory:

scp firmware-3.bin_10.2.4.13-1 root@ROUTER_IP_ADDRESS:/lib/firmware/ath10k/QCA988X/hw2.0/firmware-3.bin

Then reboot the router, and you should be back up with the 5ghz network.

comment:96 Changed 3 years ago by anonymous

Is the ath10k module fixed in latest trunk? I don't want to manually copy firmware files after every update.

comment:97 Changed 3 years ago by anonymous

  • Resolution worksforme deleted
  • Status changed from closed to reopened

Is the ath10k module fixed in latest trunk? I don't want to manually copy firmware files after every update.

comment:98 follow-up: Changed 3 years ago by timurminulin

I get the same message on r44186, even after downloading firmware from git -
[ 12.400000] cfg80211: Calling CRDA to update world regulatory domain
[ 12.400000] cfg80211: World regulatory domain updated:
[ 12.410000] cfg80211: DFS Master region: unset
[ 12.410000] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
[ 12.420000] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
[ 12.430000] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
[ 12.440000] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (N/A, 2000 mBm), (N/A)
[ 12.450000] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz), (N/A, 2000 mBm), (N/A)
[ 12.460000] cfg80211: (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (0 s)
[ 12.460000] cfg80211: (5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A, 2000 mBm), (0 s)
[ 12.470000] cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 2000 mBm), (N/A)
[ 12.480000] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 0 mBm), (N/A)
[ 12.580000] PCI: Enabling device 0000:01:00.0 (0000 -> 0002)
[ 12.580000] ath10k_pci 0000:01:00.0: pci irq legacy interrupts 0 irq_mode 0 reset_mode 0
[ 12.930000] ath10k_pci 0000:01:00.0: Direct firmware load failed with error -2
[ 12.930000] ath10k_pci 0000:01:00.0: Falling back to user helper
[ 13.490000] ath10k_pci 0000:01:00.0: otp stream is empty, using board.bin contents
[ 14.500000] ath10k_pci 0000:01:00.0: qca988x hw2.0 (0x4100016c, 0x043202ff) fw 10.2-00082-4-2 api 3 htt 2.1 wmi 65.109.0.0 cal otp
[ 14.510000] ath10k_pci 0000:01:00.0: debug 0 debugfs 1 tracing 0 dfs 1 testmode 1
[ 15.120000] ath: EEPROM regdomain: 0x0
[ 15.120000] ath: EEPROM indicates default country code should be used
[ 15.120000] ath: doing EEPROM country->regdmn map search
[ 15.120000] ath: country maps to regdmn code: 0x3a
[ 15.120000] ath: Country alpha2 being used: US
[ 15.120000] ath: Regpair used: 0x3a
[ 15.130000] cfg80211: Calling CRDA for country: US
[ 15.140000] cfg80211: Regulatory domain changed to country: US
[ 15.140000] cfg80211: DFS Master region: FCC
[ 15.150000] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
[ 15.160000] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 3000 mBm), (N/A)
[ 15.160000] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 1700 mBm), (N/A)
[ 15.170000] cfg80211: (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2300 mBm), (0 s)
[ 15.180000] cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 3000 mBm), (N/A)
[ 15.190000] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 4000 mBm), (N/A)

I still have working 5Ghz vht80 wifi. By the way, is that possible to use vht160? I tried and failed.

comment:99 Changed 3 years ago by timurminulin

Sorry, here's dmesg after loading the FW from git -

[ 12.940000] PCI: Enabling device 0000:01:00.0 (0000 -> 0002)
[ 12.950000] ath10k_pci 0000:01:00.0: pci irq legacy interrupts 0 irq_mode 0 reset_mode 0
[ 13.300000] ath10k_pci 0000:01:00.0: Direct firmware load failed with error -2
[ 13.300000] ath10k_pci 0000:01:00.0: Falling back to user helper
[ 13.800000] ath10k_pci 0000:01:00.0: otp stream is empty, using board.bin contents
[ 14.710000] ath10k_pci 0000:01:00.0: qca988x hw2.0 (0x4100016c, 0x043202ff) fw 10.2.4.13-1 api 3 htt 2.1 wmi 65.13.0.0 cal otp
[ 14.720000] ath10k_pci 0000:01:00.0: debug 0 debugfs 1 tracing 0 dfs 1 testmode 1

comment:100 Changed 3 years ago by timurminulin

Sorry, here's dmesg after loading the FW from git -

[ 12.940000] PCI: Enabling device 0000:01:00.0 (0000 -> 0002)
[ 12.950000] ath10k_pci 0000:01:00.0: pci irq legacy interrupts 0 irq_mode 0 reset_mode 0
[ 13.300000] ath10k_pci 0000:01:00.0: Direct firmware load failed with error -2
[ 13.300000] ath10k_pci 0000:01:00.0: Falling back to user helper
[ 13.800000] ath10k_pci 0000:01:00.0: otp stream is empty, using board.bin contents
[ 14.710000] ath10k_pci 0000:01:00.0: qca988x hw2.0 (0x4100016c, 0x043202ff) fw 10.2.4.13-1 api 3 htt 2.1 wmi 65.13.0.0 cal otp
[ 14.720000] ath10k_pci 0000:01:00.0: debug 0 debugfs 1 tracing 0 dfs 1 testmode 1

comment:101 Changed 3 years ago by backglass

Same Here

root@OpenWrt:~# dmesg |grep ath
[ 12.180000] ath10k_pci 0000:01:00.0: pci irq legacy interrupts 0 irq_mode 0 reset_mode 0
[ 12.530000] ath10k_pci 0000:01:00.0: Direct firmware load failed with error -2
[ 12.530000] ath10k_pci 0000:01:00.0: Falling back to user helper
[ 13.090000] ath10k_pci 0000:01:00.0: otp stream is empty, using board.bin contents
[ 14.100000] ath10k_pci 0000:01:00.0: qca988x hw2.0 (0x4100016c, 0x043202ff) fw 10.2-00082-4-2 api 3 htt 2.1 wmi 65.109.0.0 cal otp
[ 14.110000] ath10k_pci 0000:01:00.0: debug 0 debugfs 1 tracing 0 dfs 1 testmode 1
[ 14.720000] ath: EEPROM regdomain: 0x0
[ 14.720000] ath: EEPROM indicates default country code should be used
[ 14.720000] ath: doing EEPROM country->regdmn map search
[ 14.720000] ath: country maps to regdmn code: 0x3a
[ 14.720000] ath: Country alpha2 being used: US
[ 14.720000] ath: Regpair used: 0x3a
[ 14.920000] ath: EEPROM regdomain: 0x0
[ 14.920000] ath: EEPROM indicates default country code should be used
[ 14.920000] ath: doing EEPROM country->regdmn map search
[ 14.920000] ath: country maps to regdmn code: 0x3a
[ 14.920000] ath: Country alpha2 being used: US
[ 14.920000] ath: Regpair used: 0x3a
[ 82.330000] ath10k_pci 0000:01:00.0: otp stream is empty, using board.bin contents
[ 93.750000] ath10k_pci 0000:01:00.0: otp stream is empty, using board.bin contents
[ 171.860000] ath10k_pci 0000:01:00.0: otp stream is empty, using board.bin contents
[ 183.470000] ath10k_pci 0000:01:00.0: otp stream is empty, using board.bin contents
root@OpenWrt:~#

comment:102 Changed 3 years ago by asayler

I'm seeing this as well. It seems that as of the 2/16/15 snapshots, there's still no 5 GHz firmware for the Archer C7 included in a fresh install.

comment:103 Changed 3 years ago by krikkit

i have CHAOS CALMER (Bleeding Edge, r44541) (dated 26 Feb.2015) running and i also get this errors...

[   14.110000] ath10k_pci 0000:01:00.0: pci irq legacy interrupts 0 irq_mode 0 reset_mode 0
[   14.460000] ath10k_pci 0000:01:00.0: Direct firmware load for ath10k/cal-pci-0000:01:00.0.bin failed with error -2
[   14.470000] ath10k_pci 0000:01:00.0: Falling back to user helper
[   14.520000] firmware ath10k!cal-pci-0000:01:00.0.bin: firmware_loading_store: map pages failed
[   15.040000] ath10k_pci 0000:01:00.0: otp stream is empty, using board.bin contents
[   16.490000] ath10k_pci 0000:01:00.0: qca988x hw2.0 (0x4100016c, 0x043202ff) fw 10.2-00082-4-2 api 3 htt 2.1 wmi 65.109.0.0 cal otp
[   16.500000] ath10k_pci 0000:01:00.0: debug 0 debugfs 1 tracing 0 dfs 1 testmode 1
[   27.060000] ath10k_pci 0000:01:00.0: otp stream is empty, using board.bin contents

BUT my 5 ghz wlan works... and i get about 400 Mbit/sec transfer (directly next to the router) on a quick windows fileshare copying, so this is not so bad, and its working with the firmware which comes with that snapshot

root@OpenWrt:/# md5sum /lib/firmware/ath10k/QCA988X/hw2.0/*
f3c8843f92aee286aa1b22e55c2e7374  /lib/firmware/ath10k/QCA988X/hw2.0/board.bin
5163aa8de591f80b06c77f22e9777473  /lib/firmware/ath10k/QCA988X/hw2.0/firmware-3.bin

but i am only an advanced user, not a developer :)

comment:104 in reply to: ↑ 98 Changed 3 years ago by michal.kazior@…

Replying to timurminulin:

I get the same message on r44186, even after downloading firmware from git -
[ 12.400000] cfg80211: Calling CRDA to update world regulatory domain
[ 12.400000] cfg80211: World regulatory domain updated:
[ 12.410000] cfg80211: DFS Master region: unset
[ 12.410000] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
[ 12.420000] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
[ 12.430000] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
[ 12.440000] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (N/A, 2000 mBm), (N/A)
[ 12.450000] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz), (N/A, 2000 mBm), (N/A)
[ 12.460000] cfg80211: (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (0 s)
[ 12.460000] cfg80211: (5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A, 2000 mBm), (0 s)
[ 12.470000] cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 2000 mBm), (N/A)
[ 12.480000] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 0 mBm), (N/A)
[ 12.580000] PCI: Enabling device 0000:01:00.0 (0000 -> 0002)
[ 12.580000] ath10k_pci 0000:01:00.0: pci irq legacy interrupts 0 irq_mode 0 reset_mode 0
[ 12.930000] ath10k_pci 0000:01:00.0: Direct firmware load failed with error -2
[ 12.930000] ath10k_pci 0000:01:00.0: Falling back to user helper
[ 13.490000] ath10k_pci 0000:01:00.0: otp stream is empty, using board.bin contents
[ 14.500000] ath10k_pci 0000:01:00.0: qca988x hw2.0 (0x4100016c, 0x043202ff) fw 10.2-00082-4-2 api 3 htt 2.1 wmi 65.109.0.0 cal otp
[ 14.510000] ath10k_pci 0000:01:00.0: debug 0 debugfs 1 tracing 0 dfs 1 testmode 1
[ 15.120000] ath: EEPROM regdomain: 0x0
[ 15.120000] ath: EEPROM indicates default country code should be used
[ 15.120000] ath: doing EEPROM country->regdmn map search
[ 15.120000] ath: country maps to regdmn code: 0x3a
[ 15.120000] ath: Country alpha2 being used: US
[ 15.120000] ath: Regpair used: 0x3a
[ 15.130000] cfg80211: Calling CRDA for country: US
[ 15.140000] cfg80211: Regulatory domain changed to country: US
[ 15.140000] cfg80211: DFS Master region: FCC
[ 15.150000] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
[ 15.160000] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 3000 mBm), (N/A)
[ 15.160000] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 1700 mBm), (N/A)
[ 15.170000] cfg80211: (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2300 mBm), (0 s)
[ 15.180000] cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 3000 mBm), (N/A)
[ 15.190000] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 4000 mBm), (N/A)

I still have working 5Ghz vht80 wifi. By the way, is that possible to use vht160? I tried and failed.

qca988x hw chip doesn't support VHT160. It supports VHT80 max.

Replying to krikkit:

[ 14.110000] ath10k_pci 0000:01:00.0: pci irq legacy interrupts 0 irq_mode 0 reset_mode 0
[ 14.460000] ath10k_pci 0000:01:00.0: Direct firmware load for ath10k/cal-pci-0000:01:00.0.bin failed with error -2
[ 14.470000] ath10k_pci 0000:01:00.0: Falling back to user helper
[ 14.520000] firmware ath10kcal-pci-0000:01:00.0.bin: firmware_loading_store: map pages failed
[ 15.040000] ath10k_pci 0000:01:00.0: otp stream is empty, using board.bin contents
[ 16.490000] ath10k_pci 0000:01:00.0: qca988x hw2.0 (0x4100016c, 0x043202ff) fw 10.2-00082-4-2 api 3 htt 2.1 wmi 65.109.0.0 cal otp
[ 16.500000] ath10k_pci 0000:01:00.0: debug 0 debugfs 1 tracing 0 dfs 1 testmode 1
[ 27.060000] ath10k_pci 0000:01:00.0: otp stream is empty, using board.bin contents

The Direct firmware load for ath10k/cal-pci-0000:01:00.0.bin failed with error -2 and otp stream is empty, using board.bin contents are expected. These are due to the fact OpenWRT had a custom patch for loading chip calibration data off of flash partition (instead of on-chip EEPROM which is empty on TP-Link Archer devices among others). In the meantime upstream driver code changed a bit. This is harmless anyway (other than being a maintenance burden I suppose).

This should be cleaned up eventually by a volunteer with some spare time ;-)

comment:105 Changed 3 years ago by hlarsen

fwiw, i recently upgraded from BB to CC r45027 on my C7 v2's and the 5ghz radio was not detected until i installed kmod-ath10k (and maybe rebooted or restarted networking/wifi).

on BB i was unable to establish a WDS bridge with another C7 v2 using the 5ghz radio at all. on CC it's established and working, and while i haven't done any formal throughput testing, my main HTPC is on the other side of the wifi bridge from my file server, and i haven't had any issues with buffering.

comment:106 Changed 3 years ago by nbd

  • Resolution set to worksforme
  • Status changed from reopened to closed

comment:107 Changed 2 years ago by mwarning

I've build Chaos Calmer (r46681) and encountered the same problem. The 5Ghz section in /etc/config/wireless was missing.

The official release image worked: https://downloads.openwrt.org/chaos_calmer/15.05-rc3/ar71xx/generic/openwrt-15.05-rc3-ar71xx-generic-archer-c5-squashfs-factory.bin (r46163)

It worked when I'd build my image with kmod-ath10k. Looks like it is not selected by default - which it probably should. :/

comment:108 Changed 2 years ago by mwarning

ok, it seems the problem was because I selected "Default Profile (all drivers)" and did not deleted the .config beforehand.

comment:109 Changed 2 years ago by anonymous

The 15.05 release image for the archer c5 does not detect the 5Ghz card (as compared to the rc3 image): https://downloads.openwrt.org/chaos_calmer/15.05/ar71xx/generic/openwrt-15.05-ar71xx-generic-archer-c5-squashfs-factory.bin

Something seems to be broken.

comment:110 Changed 2 years ago by anonymous

I can confirm this.

comment:111 Changed 2 years ago by anonymous

I can confirm this bug too. After an update to the lates version of chaos_calmer, 5Ghz is not available anymore.

comment:112 Changed 2 years ago by asayler

This issue is being discussed in a more recent ticket as well: /ticket/20488.html.

comment:113 Changed 2 years ago by MichalZ

Hello,
it seems to me that this is not a bug driver. A gui which forces the channel width up to 160 Mhz. A card ath9 in the C7 does not support.
If you enforce the width 20,40,80 5GHz radio will be up and running. (Requires restarting the router)

--
MichalZ

comment:114 Changed 2 years ago by anonymous

Yup, choosing 80 MHz and restarting the router works, but be prepared that unlike 2.4 GHz WiFi the 5 GHz interfaces takes ages to come up again each time you make a change to its configuration - so be patient.

Changed 22 months ago by anonymous

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.