What's new

[Release 380] Asuswrt-Merlin 380.69 is now available

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

I have odd problem about every 5 day I can't gain access to the router or freeze up the web browser after login force me unplug the power .
 
I've retried flashing 380.69 on my RT-AC56U, and it still complains that it is not valid (the trx file). I also tried to flash380.68_4 and it complained in the same way. Most likely I'm out of some resource or have replaced something from optware and broken the update process. Any chance @RMerlin, could you tell me where to look in the firmware to learn how flashing is done and validated? Where is the image to be flashed stored?
 
I've retried flashing 380.69 on my RT-AC56U, and it still complains that it is not valid (the trx file). I also tried to flash380.68_4 and it complained in the same way. Most likely I'm out of some resource or have replaced something from optware and broken the update process. Any chance @RMerlin, could you tell me where to look in the firmware to learn how flashing is done and validated? Where is the image to be flashed stored?
Have you unpacked zip file and use .trx file?
 
Have you unpacked zip file and use .trx file?
and: unplug USB devices and reboot before firmware update (removes also all optware stuff).
 
@octopus: yes, I've used just the trx file. Checksum is fine as well
@joegreat: Actually I don't have any usb drives attached. I've moved my optware in jffs. But I will disable it, reboot and try again.
 
Basically, it involves rewriting the T-Mobile CFE with stock ASUS's. Then install the ASUS stock fw. From there you can install Merlin fw. There are some variations of the instructions on line:

https://slickdeals.net/forums/showpost.php?p=73690012&postcount=3895
https://slickdeals.net/forums/showpost.php?p=92546119&postcount=5816
https://slickdeals.net/forums/showpost.php?p=92917711

Honestly, I can't remember which one I followed. I think it was the bootymonger instructions (the second link).
Obligatory warning: it will void the router's warranty, and there's a chance the router will be bricked.

warning noted, and thank you!
 
Yes, it's the correct firmware. Anyway I managed to do the upgrade after disabling jffs and rebooting. Must have had something there that was breaking the update process. Update went fine (did it from my phone, over wifi).
Thank you all for your help!
 
Update went fine (did it from my phone, over wifi).
Thank you all for your help!
Very brave! Should not be done via WiFi! :rolleyes:
 
This indicates that your problem has nothing to do with the firmware update but with something else in your environment.
I am back on 380.68_4 which is working perfectly (on rt-ac87u), except now the CPU total usage for both cores is always above 101%, one goes down, one goes up, always moving even in very low usage. RAM usage is around 23%. I noticed that when restoring, I had first installed the latest ASUS firmware, the CPU cores usage was very low, below 10% each. Also on a rt-ac68u using Merlin the CPU cores usage is very low and stable, even though there are about 10 clients connected, wired and wireless. Is this normal for this firmware on the 87u? is there anything I can do to stabilize the fluctuations?
Many thanks for your input.
 
Very brave! Should not be done via WiFi!

Why not? 95% of my firmware flashing is done over Wifi, as I mostly do my development from my laptop.

I am back on 380.68_4 which is working perfectly (on rt-ac87u), except now the CPU total usage for both cores is always above 101%, one goes down, one goes up, always moving even in very low usage. RAM usage is around 23%. I noticed that when restoring, I had first installed the latest ASUS firmware, the CPU cores usage was very low, below 10% each. Also on a rt-ac68u using Merlin the CPU cores usage is very low and stable, even though there are about 10 clients connected, wired and wireless. Is this normal for this firmware on the 87u? is there anything I can do to stabilize the fluctuations?
Many thanks for your input

Run "top" over SSH to determine which process is using your CPU. Most common causes are the DLNA media server scanning plugged USB disks.
 
My AC68U that ran 380.65_4 was all of a sudden plagued by reboots so I upgraded it to see if 380.69_0 would fix these. However that was not the case. I restored factory defaults after the upgrade and manually updated the settings via the UI.

The reboots are most likely caused by Android 8.1.0 on my Pixel phone that is causing a lot of havoc. There have been a lot of reports about Android 8.1.0 devices that crash or reboot routers when you awake them when they have been sleeping for a while. See also the 200+ posts in this thread: https://support.google.com/pixelphone/forum/AAAAb4-OgUsE7sQJOTnXNk/? People are even buying new routers because of it while Google remains totally silent.

I've attached the dmesg output of such a crash on my AC68U with 380.69_0 in reboot1.txt.

So I've banned the Pixel from my network to see if that fixes the reboots. Today however I got another type of reboot when I woke my Nexus 5 with Android 6.0.1. I've attached the dmsg output of that crash in reboot2.txt. I did not see any of those reboots on 380.65_4.
 

Attachments

  • reboot1.txt
    3 KB · Views: 584
  • reboot2.txt
    2.7 KB · Views: 369
My AC68U that ran 380.65_4 was all of a sudden plagued by reboots so I upgraded it to see if 380.69_0 would fix these. However that was not the case. I restored factory defaults after the upgrade and manually updated the settings via the UI.

The reboots are most likely caused by Android 8.1.0 on my Pixel phone that is causing a lot of havoc. There have been a lot of reports about Android 8.1.0 devices that crash or reboot routers when you awake them when they have been sleeping for a while. See also the 200+ posts in this thread: https://support.google.com/pixelphone/forum/AAAAb4-OgUsE7sQJOTnXNk/? People are even buying new routers because of it while Google remains totally silent.

I've attached the dmesg output of such a crash on my AC68U with 380.69_0 in reboot1.txt.

So I've banned the Pixel from my network to see if that fixes the reboots. Today however I got another type of reboot when I woke my Nexus 5 with Android 6.0.1. I've attached the dmsg output of that crash in reboot2.txt. I did not see any of those reboots on 380.65_4.

Sounds like your AC68 could have some hardware issues or overheating? devices should not cause your wifi to reboot.
 
My AC68U that ran 380.65_4 was all of a sudden plagued by reboots so I upgraded it to see if 380.69_0 would fix these. However that was not the case. I restored factory defaults after the upgrade and manually updated the settings via the UI.
Looking thru the kernel trace it might be a Out of Memory (OoM) situation: Do you have an USB drive attached? Then you could create a swap file and have room for swapping out memory content if needed.
Or your attached drive has a read error? At least the 2nd trace shows something like drive issues... :rolleyes:
 
Thanks for helping out! Its winter here and the AC68U has been residing in a well ventilated area ever since I got it so the temperatures are not really an issue I think (see temperatures.png).

Also I don't have any USB devices connected. I use the AC68U just for basic network functionality in wireless router mode so it can route traffic of about 54 devices which used to work very well. So I don't use: QoS, AiCloud, AiProtection, traffic statistics, IPv6. Occasionally I connect using VPN.

The reboots always occur after waking up an Android device after it has been sleeping for a while. So my Nexus 5 seems to have caused a reboot again, see reboot3.txt . :(
 

Attachments

  • temperatures.png
    temperatures.png
    238.7 KB · Views: 643
  • reboot3.txt
    2.2 KB · Views: 309
I don't know if this is the correct thread to post, since i also experienced this on previous versions of the firmware.
Whenever I set my 5ghz wifi channel fixed, it sometimes automatically reverts to channel 36.
Could this have someting todo with DFS? In my country (BE) there are weather radars operating at 5600-5650Ghz and we can only use these frequencies with DFS enabled, but I've set my 5ghz to channel 60 which operates at 5300ghz which doesn't require DFS.

I don't know why it always wants to select channel 36 because in my apartment building that is the only 5ghz channel used by other AP's, while channel 50 to 64 (UNII-2) is totally unused.

The syslog doesn't show anything related except for the wireless service being restarted every time the channel changes.

Anyone got any ideas on what might cause this strange behavior?
 

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top