Wifi AR922x not detected after upgrade 18.06

The problem is with firmware loading. Do you have a firmware file in /lib/firmware?
If not, it means that the firmware address is wrong in the script.

What is the target of this device?

I think so

root@OpenWrt:/# ls /lib/firmware
adsl.bin                           ltq-dsl-fw-b-danube.bin
ath9k-eeprom-pci-0000:00:0e.0.bin  regulatory.db
ath9k_htc

Target is

root@OpenWrt:/# cat /proc/cpuinfo 
system type             : Danube rev 1.5
machine                 : Speedport W 504V Typ A
processor               : 0
cpu model               : MIPS 24KEc V4.1
BogoMIPS                : 221.18
wait instruction        : yes
microsecond timers      : yes
tlb_entries             : 16
extra interrupt vector  : yes
hardware watchpoint     : yes, count: 4, address/irw mask: [0x0ffc, 0x0ffc, 0x0ffb, 0x0ffb]
isa                     : mips1 mips2 mips32r1 mips32r2
ASEs implemented        : mips16 dsp
shadow register sets    : 1
kscratch registers      : 0
package                 : 0
core                    : 0
VCED exceptions         : not available
VCEI exceptions         : not available

What is in the ath9k-eeprom-pci-0000:00:0e.0.bin? Do hexdump on it.

I thought ath9k does not require firmware ?
I dont see this ath9k-eeprom-pci-0000:00:0e.0.bin in my router /lib/firmware folder.

https://wiki.openwrt.org/doc/howto/wireless.overview

  • Atheros ath9k does not require firmware.

See this for details, in short, it's extracted from the system flash (ART) and patched as needed (MAC addresses, endianess, etc.) to be re-used as needed on subsequent reboots.

It does require calibration data, but on ar71xx it is loaded a different way without having this file.

Hi, I think we all are after the same bug.

Yesterday, I decided to upgrade my tdw8980 running 17.01.2 to 18.06.1, but wifi did not came up after the upgrade. In fact, it doesn't get detected anymore. I've tried development snapshot, as well as rollback to 17.01.2, but nothing helped. Fortunately, I do have 2nd tdw8980 still running 17.01.4 so I could compare the differences between running systems. And I think I might have idea what happened.

tdw8980 has AR9287 listed on PCI bus, giving in lspci:

good-one # lspci -nn
...
02:00.0 Network controller [0280]: Qualcomm Atheros AR9287 Wireless Network Adapter (PCI-Express) [168c:002e] (rev 01)
broken-one # lspci -nn
...
02:00.0 Ethernet controller [0200]: Qualcomm Atheros AR5008 Wireless Network Adapter [168c:ff1c] (rev 01)

As both devices hold nearby mac addresses for their eth phy, I believe that the hardware is of the same revision (still need to check the board though). So the broken-one should list AR9287 as well, but instead it gets broken device identifier ff1c. As this persists once broken, I believe that ath9k in 18.06.1 has somehow managed to overwrite portions of memory on wifi card it was not supposed to, effectively breaking the device.

Inspecting device nodes in sysfs, one gets:

root@broken-one:/sys/devices/pci0000:01/0000:01:00.0/0000:02:00.0# ls -aihl
   1020 drwxr-xr-x    2 root     root           0 Jan  1  1970 .
    986 drwxr-xr-x    4 root     root           0 Jan  1  1970 ..
   1038 -rw-r--r--    1 root     root        4.0K Nov 21 11:38 broken_parity_status
   1030 -r--r--r--    1 root     root        4.0K Nov 21 11:35 class
   3666 -rw-r--r--    1 root     root        4.0K Nov 21 11:35 config
   1036 -r--r--r--    1 root     root        4.0K Nov 21 11:38 consistent_dma_mask_bits
   1027 -r--r--r--    1 root     root        4.0K Nov 21 11:35 device
   1040 -r--r--r--    1 root     root        4.0K Nov 21 11:38 devspec
   1035 -r--r--r--    1 root     root        4.0K Nov 21 11:38 dma_mask_bits
   1041 -rw-r--r--    1 root     root        4.0K Nov 21 11:38 driver_override
   1037 -rw-r--r--    1 root     root        4.0K Nov 21 11:38 enable
   1031 -r--r--r--    1 root     root        4.0K Nov 21 11:35 irq
   1033 -r--r--r--    1 root     root        4.0K Nov 21 11:38 local_cpulist
   1032 -r--r--r--    1 root     root        4.0K Nov 21 11:38 local_cpus
   1034 -r--r--r--    1 root     root        4.0K Nov 21 11:38 modalias
   1039 -rw-r--r--    1 root     root        4.0K Nov 21 11:38 msi_bus
   1022 lrwxrwxrwx    1 root     root           0 Nov 21 11:38 of_node -> ../../../../firmware/devicetree/base/fpi@10000000/pcie@d900000/pcie@0/wifi@168c,002e
   1023 --w--w----    1 root     root        4.0K Nov 21 11:38 remove
   1024 --w--w----    1 root     root        4.0K Nov 21 11:38 rescan
   3668 --w-------    1 root     root        4.0K Nov 21 11:38 reset
   1025 -r--r--r--    1 root     root        4.0K Nov 21 11:35 resource
   3667 -rw-------    1 root     root       64.0K Nov 21 11:38 resource0
   1043 lrwxrwxrwx    1 root     root           0 Nov 21 11:38 subsystem -> ../../../../bus/pci
   1029 -r--r--r--    1 root     root        4.0K Nov 21 11:38 subsystem_device
   1028 -r--r--r--    1 root     root        4.0K Nov 21 11:38 subsystem_vendor
   1021 -rw-r--r--    1 root     root        4.0K Nov 21 11:38 uevent
   1026 -r--r--r--    1 root     root        4.0K Nov 21 11:35 vendor

while on working one:

root@good-one:/sys/devices/pci0000:01/0000:01:00.0/0000:02:00.0# ls -aihl
   1021 drwxr-xr-x    6 root     root           0 Nov 21 10:40 .
    986 drwxr-xr-x    4 root     root           0 Jan  1  1970 ..
   1039 -rw-r--r--    1 root     root        4.0K Nov 21 10:54 broken_parity_status
   1031 -r--r--r--    1 root     root        4.0K Nov 21 10:54 class
   3668 -rw-r--r--    1 root     root        4.0K Nov 21 10:54 config
   1037 -r--r--r--    1 root     root        4.0K Nov 21 10:54 consistent_dma_mask_bits
   1028 -r--r--r--    1 root     root        4.0K Nov 21 10:54 device
   1041 -r--r--r--    1 root     root        4.0K Nov 21 10:54 devspec
   1036 -r--r--r--    1 root     root        4.0K Nov 21 10:54 dma_mask_bits
   4746 lrwxrwxrwx    1 root     root           0 Nov 21 10:54 driver -> ../../../../bus/pci/drivers/ath9k
   1043 -rw-r--r--    1 root     root        4.0K Nov 21 10:54 driver_override
   1038 -rw-r--r--    1 root     root        4.0K Nov 21 10:54 enable
   4851 drwxr-xr-x    3 root     root           0 Nov 21 10:54 gpio
   4748 drwxr-xr-x    3 root     root           0 Nov 21 10:40 ieee80211
   1032 -r--r--r--    1 root     root        4.0K Nov 21 10:54 irq
   4860 drwxr-xr-x    3 root     root           0 Nov 21 10:54 leds
   1034 -r--r--r--    1 root     root        4.0K Nov 21 10:54 local_cpulist
   1033 -r--r--r--    1 root     root        4.0K Nov 21 10:54 local_cpus
   1035 -r--r--r--    1 root     root        4.0K Nov 21 10:54 modalias
   1040 -rw-r--r--    1 root     root        4.0K Nov 21 10:54 msi_bus
   4763 drwxr-xr-x    3 root     root           0 Nov 21 10:54 net
   1023 lrwxrwxrwx    1 root     root           0 Nov 21 10:54 of_node -> ../../../../firmware/devicetree/base/fpi@10000000/pcie@d900000/pcie@0/wifi@168c,002e
   1024 --w--w----    1 root     root        4.0K Nov 21 10:54 remove
   1025 --w--w----    1 root     root        4.0K Nov 21 10:54 rescan
   4425 --w-------    1 root     root        4.0K Nov 21 10:54 reset
   1026 -r--r--r--    1 root     root        4.0K Nov 21 10:54 resource
   4424 -rw-------    1 root     root       64.0K Nov 21 10:54 resource0
   3667 lrwxrwxrwx    1 root     root           0 Nov 21 10:54 subsystem -> ../../../../bus/pci
   1030 -r--r--r--    1 root     root        4.0K Nov 21 10:54 subsystem_device
   1029 -r--r--r--    1 root     root        4.0K Nov 21 10:54 subsystem_vendor
   1022 -rw-r--r--    1 root     root        4.0K Nov 21 10:54 uevent
   1027 -r--r--r--    1 root     root        4.0K Nov 21 10:54 vendor

As you can see, the driver does not even claim the device. Furthermore, I had checked the mtd for signs of possible corruption, however mtd stands clear from this. If you look to the posts here in the thread, it shows signs of similar behavior. I hope to get a bit more time to look into this.

Maybe @nbd has an idea about this, it being ath9k related.

1 Like

Did you reset settings to defaults?

Hi, the workflow was:

  1. backup /overlay mounted from flashdrive
  2. prepare image with default network, password, firewall, ssh configurations
  3. wipe out /overlay, have 17.01.2 boot with clean /overlay, transfer the customized 18.06.1 image to bad-one and perform sysupgrade without preserving configuration (did not explicitly check whether wireless was already proken or not, but presuming good-one started with clean /overlay and 17.01.4 created the same way, presume working)
  4. Boot into 18.06.1, no wireless. Downgrade to 17.01.6 with the same method. Then 17.01.4. Eventualy trying 17.01.2 with and without pre-installed /etc/config/wireless; without any success bringing the wifi back online.
  5. Did a couple of reboots, without any success. I eventualy decided to restore the backup /overlay, did a couple of reboots, made sure that previous configuration is working, however still without wifi.

I might have possibly narrow down the issue to (perhaps) initialization order on 17.01.2, as I managed to (hopefuly) restore the wifi couple of minutes ago by removal and reinsertion of owl-loader.ko (did that on remote, will check whether wifi works later once I get home).

Btw, /lib/firmware/ath9k-eeprom-pci-0000:02:00.0.bin is part of the backup, did not get generated in any of the rollback attempts.

Hunting ghosts here. Climbed up for the device, brought it down for testing.

  1. Did fully fresh install without any backups (18.06.1). Firmware got generated, ifaces appeared.

  2. Followed by image with only etc/dropbear + etc/config/dropbear. Firmware got generated, ifaces appeared.

  3. Followed by image with etc/config/wireless. Firmware got generated, ifaces (2x essid) missing.
    => Reproduced bug

  4. Followed by previous image, firmware generated, devices missing even though no wireless config installed. Iface has reappeared.

  5. Copied generated wireless into image, flashed, iface appeared.

  6. Set country, channel and htmode; flashed. Iface appeared.

  7. Added essid configurations; flashed. Iface appeared.

  8. Dropped option disabled from wireless config. Firmware got extracted; iface did not appear.

Furthermore, cases #5 and #8 end up with same files in /overlay, only wireless differs.

Ok, so apparently enabling wifi in default is what kills wifi. There is however one difference
against my past attempts - dmesg contains reports from ath module, which was not the previous case.
Also, wifi card is assigned correct pci device ID. lsmod reports ath9k is used by 1 userspace process.
So I believe that this behavior is different from the one observed before and I did not reproduce the original bug.

logcat:

[   10.612050] PCI: Enabling device 0000:02:00.0 (0000 -> 0002)
[   10.618348] owl-loader 0000:02:00.0: Direct firmware load for ath9k-eeprom-pci-0000:02:00.0.bin failed with error -2
[   10.628038] owl-loader 0000:02:00.0: Falling back to user helper
[   10.811551] kmodloader: done loading kernel modules from /etc/modules.d/*
[   12.459126] owl-loader 0000:02:00.0: fixup device configuration
[   12.466484] pci 0000:02:00.0: [168c:002e] type 00 class 0x028000
[   12.466587] pci 0000:02:00.0: reg 0x10: [mem 0x1c000000-0x1c00ffff 64bit]
[   12.466884] pci 0000:02:00.0: supports D1
[   12.466911] pci 0000:02:00.0: PME# supported from D0 D1 D3hot
[   12.467517] pci 0000:02:00.0: BAR 0: assigned [mem 0x1c000000-0x1c00ffff 64bit]
[   12.473796] PCI: Enabling device 0000:02:00.0 (0140 -> 0142)
[   12.487452] ath: phy0: Ignoring endianness difference in EEPROM magic bytes.
[   12.494760] ath: EEPROM regdomain: 0x0
[   12.494776] ath: EEPROM indicates default country code should be used
[   12.494782] ath: doing EEPROM country->regdmn map search
[   12.494801] ath: country maps to regdmn code: 0x3a
[   12.494811] ath: Country alpha2 being used: US
[   12.494817] ath: Regpair used: 0x3a
[   12.511373] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
[   12.518124] ieee80211 phy0: Atheros AR9287 Rev:2 mem=0xbc000000, irq=144

So apparently, phy was initialized. Further lreading log, I found out: daemon.notice netifd: radio0 (3442): ./mac80211.sh: eval: line 1: /usr/sbin/hostapd: not found

TL;DR:
Even though imagebuilder builds image for my device, it does not do so using corresponding profile automatically. In fact, it ommits some of the packages required. Therefore, explicit PROFILE="tplink_tdw8980" was required. This pulls in wpad-mini, satisfying the dependency.
Followed this, I restored the original broken image, figured out I was missing kmod-owl-loader (this fixed the wrong pci ID), and wpad-mini.

This (+ that) thread does not describe whether original authors used custom images or factory ones; however it did fix the issues for me. Although figuring out what is going on was somewhat...

Anyway, thanks everybody for help. Hope this will be case of the other thread as well.

meaning you got the wifi back by remove /overlay ?
First I'm upgraded with the custom 18.06 and wifi gone, then I try to restore it use the factory or downgraded it doesn't help at all.

Hi, in short, no.

/overlay has nothing to do with it - given that in my case the issues persisted even after reflashes, which cleared it. I suggest to go step by step, if we have the same problem, one of the things I did fixed it. First, can you flash to the openwrt version you had before the upgrade to 18.06 and post lspci -nn?

Hello

Same problem with ubnt ac-lite. After upgrade from 17.01.4 there is no Wi-Fi.
Is there any bug report created?

Thank you!

This remember me another post...

Version 18.06 erased CAL_DATA partition of three of my routers. I don't know if your router had this partition, but if you don't get the calibration data, your router is bricked. Try to flash original stock firmware, maybe the CAL_DATA partition back, and then flash 17.01.04.

Ticket created on 31.07.2018.

https://bugs.openwrt.org/index.php?do=details&task_id=1719

I have 2 ac-lite router.
Router A has 17.01.4. If I upgrade this to 18.06.1 wifi disappears. When I go back to 17.01.4 wifi is back again.
Router B has stock ubnt firmware. If I upgrade it to 18.06.1 wifi works well.

I restored the original ubnt firmware on Router A then upgraded directly to 18.06 and now wifi works on this router as well.

same problem in 18.06 (don't know previous versions). I think is the same device [1]

upgrading to snapshot (2019-10-25) solved the problem and wifi works as expected. I think/hope wifi will work in next stable (maybe 19.07)
[1]
root@OpenWrt:~# cat /etc/board.json
{
"model": {
"id": "arcadyan,arv7518pw",
"name": "Astoria Networks ARV7518PW"
},

my wifi broke completely with openwrt and original d-link after flashing - AR9287 ( D-Link DSL-2740B):

solution:
go back to d-link http://files.dlink.com.au/products/DSL-2740B/REV_F1/Firmware/Firmware_v2.04_(26-07-2012)/DSL2740B_F1_AU_2.04_07262012.bin

and you have working wifi again, and you can use it in openwrt.
somehow openwrt deletes important flash memory in 2nd update.

btw. i have eu Version, no Australia. but works also.