I really don't understand. Update the router to the latest firmware (over the air on manually), unplug it and put it in a drawer. If and when you ever need it, plug it in and update to the latest firmware at that time. BTW, I haven't had any issues with the latest firmware 3.0.0.4.386.51665 with either of my RT-AC68U routers.I've replaced my AC68W and wanted to update the firmware to the latest one prior to putting it away as a backup router. Has anyone tried updating FW while the router is offline? I already downloaded the latest FW so it would be a manual update. I believe the only thing it would not be able to do is fetch the new asd file, but there may be other things so was hoping to get some input before I give this a shot. I've disabled both radios and the DHCP server so it doesn't interfere with my running router. Is there any reason this would not work?
Do it all the time with my spare RT-AC68U. I don't connect it to the internet, just connect a PC to it and flash the already downloaded firmware file to it. Then put it away in a closet. The next time its connected to the internet it will auto update the ASD file(s) or other content. No issues and it's not a big deal.Has anyone tried updating FW while the router is offline?
Thanks for the heads up. I'll keep this in mind. I haven't any issues with this router until the ASUS problems last week. I thought it was hardware related cause it's pretty old. So I replaced it with a newer router that I already bought but didn't have the time to set up. The new one did the same thing, locking up every 10 minutes or so.You don't need to update the firmware on a router not in use. When you need it - it will work well to get you going and a newer (perhaps better) firmware may be available for it. You can update it offline if you want to, but I have some reservations about 386_51665. I never found the cause, but my own AC66U B1 model (the same hardware and firmware) locked up in about 10 days uptime and because it's in another country I had to ask someone to reboot it manually. On 386_49703 the same router did 150 days uptime and was only rebooted for the update to 386_51255 and again to 386_51665.
Perfect! This is exactly what I was hoping for. This router was a workhorse and I want to keep it as a spare in case the one running goes south. Thanks a lot for confirming there are no issues with doing this.Do it all the time with my spare RT-AC68U. I don't connect it to the internet, just connect a PC to it and flash the already downloaded firmware file to it. The next time its connected to the internet it will auto update the ASD file(s) or other content. No issues and it's not a big deal.
I haven't any issues with this router until the ASUS problems last week.
Before I found out about the bad security file that Asus pushed out, I thought it was a hardware issue. I was seeing "No space left on device" in the logs even though it was showing 2% usage on that filesystem, IIRC. It was locking up every 10-15 minutes. So I didn't troubleshoot further and decided to swap it out with an AX89X that I had on standby but was too lazy to set up. It also started doing the same thing so I checked online and found that most everyone was having the same issues. The eventual fix for the AX89X was beta FW that was released to another user. Some time after that, folks started posting about deleting the /jffs/asd/* files, which supposedly also fixed the lock up issues, but I never tried it. The symptoms you describe seems to related to the asd files unless it's something else. Not sure what you've tried but have you tried deleting the files in /jssf/asd/* and restarting the routers? Although my recollection is that if you restart now, you'll get a good copy of the security file/s. Sorry, I didn't do a whole lot of troubleshooting on the AC68 since I had a running router.but what symptoms did you see?
Not sure what you've tried
This was what was happening to the AC68 except for much shorter intervals. Pings didn't stop but internet would drop and the GUI became unresponsive. After a reboot, does RAM in the GUI max out after a period of time, usually right up to the router locking up? I recall that while monitoring the GUI, I was running top and see the cpu usage climb with asd as the process using the most cpu. In your case, it might be a different process. Eventually the GUI would hang but if I recall, CLI was still responding and I was able to keep top running. This might give you an idea what's causing the problem.When this happens you can ping the APs, but no access to their own GUI and no Internet to still connected clients.
After a reboot, does RAM in the GUI max out after a period of time, usually right up to the router locking up?
I'm far from an expert on Asus routers as mine have been set it and forget it. But the GUI has limitations when you're troubleshooting. If you think he can handle instructions on using putty or terminal and setting SSH up, it might be your best bet to figure out what's going on. If not, I think the options are limited. Must be frustrating as it sounds like it's been going on for a bit.SSH is too advanced for the owner.
Could it be a corrupt ROM? I'm assuming that's where the factory settings are kept but that's just a wild guess since the RAM is volatile.The surprising part is some routers don't fully recover even after hard reset.
This worked like a charm. Thanks again.Do it all the time with my spare RT-AC68U.
Could it be a corrupt ROM?
I was going to suggest that earlier but it seemed you had a good handle on what needed to be done. I think this is a good alternative since you've already sunk so much time into trying to fix it. Good luck, keep us posted if this finally works out for the owner.No idea. The 2x RT-AC1900P are being replaced with 2x RT-AX86S tomorrow.
May 23 02:59:33 kernel: asd/176: potentially unexpected fatal signal 11.
May 23 02:59:33 kernel: Pid: 176, comm: asd
May 23 02:59:33 kernel: CPU: 0 Tainted: P (2.6.36.4brcmarm #1)
May 23 02:59:33 kernel: PC is at 0x404f65b0
May 23 02:59:33 kernel: LR is at 0x404f71b4
May 23 02:59:33 kernel: pc : [<404f65b0>] lr : [<404f71b4>] psr: 20000010
May 23 02:59:33 kernel: sp : becee448 ip : 40503994 fp : ffffffff
May 23 02:59:33 kernel: r10: 404fa648 r9 : 404fb3bc r8 : 00016900
May 23 02:59:33 kernel: r7 : 00016958 r6 : becee46c r5 : 405038c8 r4 : 000187a8
May 23 02:59:33 kernel: r3 : 0002b7c8 r2 : 00000010 r1 : 00000400 r0 : 00000000
May 23 02:59:33 kernel: Flags: nzCv IRQs on FIQs on Mode USER_32 ISA ARM Segment user
May 23 02:59:33 kernel: Control: 10c53c7d Table: 9efe804a DAC: 00000015
Welcome To SNBForums
SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.
If you'd like to post a question, simply register and have at it!
While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!