[user2035]

This is for my NG XR700 router (R9000 equiv HW) that lost all WiFi after a FW upgrade, a commonly reported issue.

During sysinit, it failed to load the Atheros controllers as shown in the console debug log. iwconfig showed no wlan0, ath0, ath1 wireless extensions. Part of my mtd partitions must be corrupted.

Does anyone know when the router initially boots up during sysinit, what files or where in the mtd partitions does it load the configuration for loading all the devices? What is in the u-boot-env partition? I have already replaced the ART with its backup ART.bak partition under the ddwrt build with the mtd command and also cleared the nvram, did wlan toggle. Have not been able to revive the wifi’s. What else can be tried?

[foz111]

Silly question, but have you tried flashing back to stock to see if the wireless starts working again?
There has been many posts over the years with R9000 radio's dying, I have one myself, very few have recovered these for my research.
There are numerous posts in DD-WRT forum, you may find the info you've asked for worth a search.

[user2035]

Flashing back to older bin was the first thing I did, including factory reset, using tftp, switching between ddwrt and NG bins, toggling wifi off/on switch at the advanced wireless setting, tried the wireless on/off button. None worked to bring WiFi back.

The 2.4/5/60 wifi lights immediately turn on after power button is pushed on, with the 2.4/5 lights dimmer at about 50% intensity. They stay same throughout and the antenna red lights turn on after booting. The WiFi lights coming immediately on is abnormal indicating wifi were not initiated. System Info tells all WiFi are disabled. Temp on wifi's are blank in debug.htm page.

[kernel-panic69]

Hardware failure or flash corruption. Happy reading, not going to quote all applicable content from eye-twitching-OCD-guy.

R9000 Wifi Failure = firmware load issues

R9000 can't enable Wifi

[user2035]

The unit was working perfectly before the FW upgrade. Unlikely all radios suddenly died. Likely the mtd is corrupted which I know happened often for the R9000. It is possible the EEPROM can go bad, but not all of a sudden. The lspci showed the 2 Atheros controllers were not loaded at sysinit. So some config may have been corrupted. But I don't know where. I have already looked at NG, Nduma, snb and some of dd-wrt histories. Still couldn't revive it. My original question was to find more info on the mtd structure. See where I can focus on, perhaps change out a possible corrupted partition.

[Alozaros]

Not much info, what did you flash it with, firmware number ?
Serial log, if it helps at all..art partition also contains the mac addresses and during the initial boot for first time firmware reads it, in order to add some important details...very likely there was
a mess happening..and your radios got messed up...unless those are not dead hardware...and those units are famous with bad heat sink design..and are prone to radio dead...good bit is, if firmware is working you can always add an AP using one of its LAN ports...

Personally i dont believe it was a DDWRT or boot err but...dead nvram sectors could be the source of the mess too...also very known problem...that's why reading and doing your homework could save your hassle...i always have in mind when i buy R9000 or XR700 that dead sectors could be a big regret !!

[user2035]

I went from the NG V1.0.1.20 firmware dated 10/2019 to the just released NetDuma beta v1.0.1.50-0626 with Duma 3.3.363 released in 7/2023 with verified users. This is the first and last major Duma 3 release for the xr700 since 2018. V1.0.1.20 was the last FW with telnet. During debug, I alternated between the NG bin and the dd-wrt 09-08-2023-r53469 bin. I have to use the dd-wrt to mtd read and write the flash as it is not in the NG shell. I have not used serial port deport as I don’t have a serial cable now.

I suspected that the ART partition was corrupted because I know it contains the radio mac addresses and the controllers were never loaded at boot. There is also the ART.bak partition. So I copied the ART.bak petition into the ART partition under dd-wrt and verified their same md5sum. I also downgraded back to the earliest NG stock bin 1.0.0.20 dated 8/2018 to try to match the old art.bak. The WiFi lights behaved exactly the same as before and lighted up the same way immediately at boot. Also with the earliest bin, probably too early and did not boot up to the interface. I think the unit came with 1.1.1.10. So I tftp in the 1.0.1.20 bin and it booted up but did not change the wifi still being off. I kept the ART.bak version in there but I have both versions in case I need to go back.

From the captured boot up debug logs enclosed, the console-log showed the sysinit errors, and the missing wireless extensions. Wireless log showed longer details.

I have tried many of the basic techniques others used. I have revived my R9000 couple years before from a FW upgrade corruption. This time it could be some portion of the flash chip going bad and being written in. I am just trying to see where it failed to load the Wifi device initially. When it first boot, where does it go to find the load config? Or does it go to the ART to find the mac address right away? What is in the mdt1: u-boot-env partition? How do I find the wifi mac addresses in the mdt2: ART ? Does the upgrade FW go into mtd6: firmware partition?
I am back to using the R9000 while the XR700 is down. All the controls between the 2 routers are identical.

[D.F.Cruizer]

I admire your patience and perseverance. How about one more trial using the following steps:

1. Reflash your XR700 with a DDWRT version say 53130 with 'Reset to factory' option selected.
2. Wait till ALL the corresponding lights come back to normal (as you can observe).
3. Give it, say, a full two minutes AFTER the lights are back.
4. Now, do ANOTHER reset of XR700 (via Administration/Reboot Router).
5. Wait again as in step 3 above.

Now log in your XR700, if it fixes your issue then good. If not, it just confirms your suspicion regarding your XR700 unit.

Nothing to loose but about a quarter of an hour wasted.

I wish you luck. 98% of issues that I've come across relating to routers is their dead power adapters. Truth be told.

[Alozaros]

i dearly hope you used the factory to ddwrt (factory-to-ddwrt.img ) first than the xr700-webupgrade.bin as otherwise if you missed the .img and went for the .bin strait away, there you go troubles ...and than with R9000 and XR700 waiting is the key those tend to boot quite slow...
good things take time
I hope you will sort it it..

[kernel-panic69]

It's a design (or rather, manufacturing) flaw, among other things for both R9000/XR700. A fine example of an experiment in creating an expensive paper weight. I don't know what it is about DD-WRT or OpenWRT or any firmware that triggers the issue other than lack of proper cooling(?). Voxel does not support anything with DumaOS - not entirely sure the same rules apply as I do not have one of these in hand. But again, I suspect it's the same problem with the R9000 and either one is a pain in the a$$ to repair after the radio chip(s) get fried (and can be quite expensive, unless you know people or can get an RMA processed). Best bet on either one of these is to buy new, break it down to parade rest, and fix the antenna cable routing issue, taking care to properly renew any thermal paste / tape / pads disturbed. Netgear support wanted to be difficult and I chose to have SFP, 60-2.4-5GHz radios completely removed from the picture altogether on mine that crapped out. The remaining bits make one helluva wired ethernet router. You'll be lucky to recover this router after wifi failure without 3rd-party repair activity involved.

[user2035]

As I mentioned before, this router worked perfectly before I flashed in the new FW. I didn’t think there was any HW issue. Unlikely all 3 radios died all at once. I believed there is a corruption in the mtd flash somewhere.

However today when I turned on the device to try to reflash back to dd-wrt after a whole day not having the router on. I noticed the wifi lights did not go on immediately after power on. Actually the 5GHz and the 60GHz came on, but no 2.4G. The temp of the 5G and 60G were there in the debug page. Iwconfig showed that they are there as ath0 and wlan0. My WiFi Analyzer on my tablet detected that the 5G was there, but at very low level at -95 dBm. The 5G radio was intermittent, meaning that it turned itself off, then came back on. After say 3-5 mins, the unit rebooted itself also. Not stable. When the wifi were not there before, it never reboot itself. So I am not sure if there is hardware issue or just wifi power level calibration table corrupted or something else. This has my art.bak still in the art, and still has the NG V1.0.1.20 FW. In the settings, the option to unbind the 2.4 and the 5 has been grey out since I got FW corruption. Not sure what to make of all these yet.

iwconfig now, no ath1:

wlan0 IEEE 802.11 Mode:Master
Retry short limit:7 RTS thr:off Fragment thr:off
Power Management:on

ath0 IEEE 802.11ac ESSID:"Net5G"
Mode:Master Frequency:5.765 GHz Access Point: A0:40:A0:62:AD:6C
Bit Rate:1.7333 Gb/s Tx-Power=29 dBm
RTS thr:off Fragment thr:off
Encryption key:E4F6-8C15-F201-FA10-2EF7-FB11-E215-0D27 [2] Security mode:open
Power Management:off
Link Quality=0/94 Signal level=-95 dBm Noise level=-95 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0

lspci now:

0000:00:00.0 Ethernet controller: Device 1c36:0002 (rev 01)
0000:00:01.0 Ethernet controller: Device 1c36:0001 (rev 01)
0000:00:03.0 Ethernet controller: Device 1c36:0001 (rev 01)
0000:00:04.0 Network and computing encryption device: Device 1c36:0011 (rev 01)
0000:00:04.1 Network and computing encryption device: Device 1c36:8011 (rev 01)
0000:00:05.0 System peripheral: Device 1c36:0021 (rev 01)
0000:00:05.1 System peripheral: Device 1c36:8021 (rev 01)
0001:00:00.0 PCI bridge: Device 1c36:0031 (rev 01)
0001:01:00.0 PCI bridge: ASMedia Technology Inc. Device 1182
0001:02:03.0 PCI bridge: ASMedia Technology Inc. Device 1182
0001:02:07.0 PCI bridge: ASMedia Technology Inc. Device 1182
0001:04:00.0 Network controller: Qualcomm Atheros Device 0046
0002:00:00.0 PCI bridge: Device 1c36:0031 (rev 01)
0002:01:00.0 USB controller: ASMedia Technology Inc. ASM1042A USB 3.0 Host Controller
0003:00:00.0 PCI bridge: Device 1c36:0031 (rev 01)
0003:01:00.0 Network controller: Wilocity Ltd. Wil6200 802.11ad Wireless Network Adapter (rev 02)


Did not list the 2 Network controller: Qualcomm Atheros QCA9984 802.11ac Wave2 Wireless Network Adaptors as I see in my R9000

[foz111]

May be worth trying another power supply, they can do some funky stuff when PSU is failing?

[Alozaros]

although it sounds like a mess with partitions, and scarce info on some Q points..
+1 for another PSU as those radio issues are similar to my bad experience with failed
psu on R7000 in the past ..radio was going on/off in a similar way

[user2035]

I have used a different power adaptor. Nothing changed.
The same very weak 5GHz signal appeared, no 2.4G, the wifi turns on and off by itself.
I think there is still something wrong with sysinit and config. Maybe a config calibration issue. I am not convinced if this indicated a HW failure.

[NetgearAdmin]

I have experienced the same problem with the newest DD-wrt on my XR700 with no wifi network on 2.4 GHz and weak 5GHz signal. I use it mostly as AP but in Router mode with WAN IP Disabled option and router's WAN configured as LAN port on XR700 switch.
I have been using quite stable 10-13-2022-r50500 release over 10 months. After last unresponsive/freeze event of LAN ports I decided to flash newest release: 09-08-2023-r53469. After reboot the wifi problem has started. I flashed month older 08-01-2023-r53339 - wifi problem persisted. I rolled back to quite stable 10-13-2022-r50500 and wifi problem disappeared. I acknowledge that there was no config change between versions. I have found that if I change radio channels of WIFI 2.4GHz (from 9 to 12 channel and back, the GUI becomes unresponsive and forced me to reboot by powering it off. The channel changes was visible after power on , next boot.