Release Asuswrt-Merlin 386.2 is now available

[Datalink]

At some point when you can get back into the UI, and are able to navigate around the tabs, I'd reboot the router. You'll have to judge whether or not the time that it takes to switch from one tab to another is normal or still running slow. I think when you determine that the router appears to be behaving normally, at least in the time that it takes to navigate thru the tabs, at that point, reboot the router.

Don't know why the speedtest was blocked. Maybe its the result of the database maintenance ??

 

[derek87]

thanks for the tips. i am finally in the UI and speediest now works on my iPhone so it must have been database management going on. i will let it sit a little longer but then reboot as you suggested. i think i will hold off in shifting over from AP mode to AI Mesh 2.0. i've done enough experimenting for one night

thanks again for your speedy help. i greatly appreciate it.

 

[MvW]

i'm sorry if i am missing reading all 23 pages here but in my skimming i didn't quite see the scenario or situation i am having.

Hopefully all is back to responsive now. Hopefully you don't take this the wrong way, as that's not my intention, but for the next time, I can understand skimming to 23 (now 24) pages is hard and my compliments to @Datalink for his patience, but really, all you had to was read the changelog on the first post. It's all in there, that it might take some time as Asus has built in some database maintenance to be done on first run. The guestion has been asked a dozen times in both this and the previous 386.x release thread, and if people would just RTFCL, it would have saved you a lot of time, if you ask me. Not that the database maintenance would have been shorter, but well, you wouldn't have had to worry about something being wrong. All the information you needed was already provided in the first post.

Best regards,
Marco

 

[derek87]

Hopefully all is back to responsive now. Hopefully you don't take this the wrong way, as that's not my intention, but for the next time, I can understand skimming to 23 (now 24) pages is hard and my compliments to @Datalink for his patience, but really, all you had to was read the changelog on the first post. It's all in there, that it might take some time as Asus has built in some database maintenance to be done on first run. The guestion has been asked a dozen times in both this and the previous 386.x release thread, and if people would just RTFCL, it would have saved you a lot of time, if you ask me. Not that the database maintenance would have been shorter, but well, you wouldn't have had to worry about something being wrong. All the information you needed was already provided in the first post.

Best regards,
Marco

hi Marco, i apprecite your sharing this thought. yet, i need to defend myself partially here. i did see the 5 min to hour, but when i wrote originally, i was at least 80 minutes in, and i think by the time i found the GUI had freed itself, it was well past 90 minutes.

i was very perplexed that this time was not needed for my ac68u, but i suppose that because it was running as an AP, it didn't need to do as much maintenance.

anyway, i'm sorry to eat up time on this thread, but because i was well past an hour (i purposefully left and hoped that it would fix itself in an hour) before i wrote to this thread for help.

 

[Deleted member 22229]

i was very perplexed that this time was not needed for my ac68u, but i suppose that because it was running as an AP, it didn't need to do as much maintenance.

Never had any wait time on my AX58U or AC3100. Not sure why this data base issue is there for some and not others. This is clearly a bug Asus needs to fix ASAP. No one should have to wait 1-2 hours after a firmware flash to be able to enter the UI and set up the router. It's unacceptable and in my opinion a deal breaker.

 

[TheMorpN]

Have you tried going back to stock via "rescue", lets say for a day, then gone back?

Tried it last night..no go. The moment I upgrade past 384.19, my router goes into a constant reboot...

I guess I have no choice but to stick with this version.....

 

[Deleted member 22229]

Tried it last night..no go. The moment I upgrade past 384.19, my router goes into a constant reboot...

I guess I have no choice but to stick with this version.....

At this point it has to be a hardware issue corrupt or missing memory or something. May be time for a new router cant stay on older unsecure firmware forever. Good Luck.

 

[John Fitzgerald]

Tried it last night..no go. The moment I upgrade past 384.19, my router goes into a constant reboot...

I guess I have no choice but to stick with this version.....

Last thought, try, with the firmware restoration tool, an older 384 stock code base, say from a year old one. (Late 2019, Early 2020) (If it goes do a GUI factory reset with the box checked next to it and also wiping the JFFS box and hit apply right after then reboot)
Or, if you can remember, or it's printed on the label or box, the firmware that it was factory shipped with.

GT-AC5300 - Support

www.asus.com

If it goes, keep it for 24hrs. then try going to stock newest 386 and keep for another 24hrs, then try to go to Merlin's newest.

 

[RMerlin]

Never had any wait time on my AX58U or AC3100. Not sure why this data base issue is there for some and not others. This is clearly a bug Asus needs to fix ASAP.

It's a ONE TIME maintenance thing that happens when jumping to the new code base, there is absolutely nothing to fix there. Once it's done, it's DONE and doesn't need to happen again.

 

[Deleted member 22229]

It's a ONE TIME maintenance thing that happens when jumping to the new code base, there is absolutely nothing to fix there. Once it's done, it's DONE and doesn't need to happen again.

I was under the impression this happens after every 386 flash. If that's not the case then i suppose it can be dealt with. Thanks for clearing that up.

 

[mmacedo]

View attachment 33004 Mine after updating the node to 384.19 the node is 23 hrs. Ignore the 35d20 that is an old DSL-N55U in media bridge.

I changed my AiMesh Node to AP Mode and the radios uptimes have been more than 3 days without any issues now. I hope Asus fixes the bug and I can return to AiMesh soon.

 

[TheMorpN]

At this point it has to be a hardware issue corrupt or missing memory or something. May be time for a new router cant stay on older unsecure firmware forever. Good Luck.

Last thought, try, with the firmware restoration tool, an older 384 stock code base, say from a year old one. (Late 2019, Early 2020) (If it goes do a GUI factory reset with the box checked next to it and also wiping the JFFS box and hit apply right after then reboot)
Or, if you can remember, or it's printed on the label or box, the firmware that it was factory shipped with.

GT-AC5300 - Support

www.asus.com

If it goes, keep it for 24hrs. then try going to stock newest 386 and keep for another 24hrs, then try to go to Merlin's newest.

OMG.. I bit the bullet and did a complete factory reset again, then did a recovery of a stock firmware from 2019 and left it along for a few hours. Reset and reformatted my jfffs and USB drive and then upgraded to 386.2_2. It has been now running for over 1 hour... I know...I should have waited longer, but I'm in patient

So far it it working and stable. I will need to re-install all my addons, but that can wait.

Thanks again for your help. I guess it must been some corrupt software, but it makes no sense that even after my first recovery, that it would fail...

Anyways, thanks again.

 

[banger]

I changed my AiMesh Node to AP Mode and the radios uptimes have been more than 3 days without any issues now. I hope Asus fixes the bug and I can return to AiMesh soon.
View attachment 33238

I got 6 days using 384.19 on the node. I hope Asus fix the mesh stability now testing with 386.2_2 as router and node.

 

[Suresh]

My AX86U crashed for the first time, 386.2_2. When it rebooted, I see lot of these messages in the log right before it rebooted.

Apr 16 17:05:37 kernel: protocol 0800 is buggy, dev eth7

I have Nvidia Shield TV connected to ethernet port, another ethernet port connected to AppleTV and another one going to network switch.

@RMerlin any suggestions?

 

[slidermike]

My AX86U crashed for the first time, 386.2_2. When it rebooted, I see lot of these messages in the log right before it rebooted.

Apr 16 17:05:37 kernel: protocol 0800 is buggy, dev eth7

I have Nvidia Shield TV connected to ethernet port, another ethernet port connected to AppleTV and another one going to network switch.

@RMerlin any suggestions?

If it was me, I would not worry about 1 crash. I would just note it down and keep an eye out for more issues. If it starts crashing, maybe a pattern will emerge such as every so many days.

 

[csj97229]

Upgraded (dirty) five RT-AC86U devices without incident. I really need more breakages/outages/drama during these upgrades or else my wife will realize she no longer needs to keep me around to keep the internet running smoothly.

Device 1 at home is a simple wireless router. Upgraded from 386.2 to 386.2_2 via WebUI and switched to 'cake' QoS (on Xfinity with lame 6Mb upload). Didn't even take the WiFi down long enough for it to register with the family.

Device 2 at beach house, also a simple wireless router. Upgraded from 386.2 to 386.2_2 via ssh / hnd-write CLI. Device came back up and auto-connected to my VPN server without incident. I assume it's working fine but I haven't gone out there to really test it yet.

Devices 3-5 in a router + 2x AIMesh config at the office of a local non-profit. Mesh devices were running stock Asus but router was on Merlin 384.19. I wasn't sure the best way to go about it so I upgraded both AIMesh devices to 386.2_2 first using the WebUI. Both devices upgraded fine and were still usable in the mesh. Then I upgraded the main router, also via the WebUI. Twiddled my thumbs for an hour (as expected, thanks Asus ) until I finally got access to the WebUI again. Updated Guest network #1 settings to also be shared with the AIMesh devices and rebooted the whole lot once more for good measure. Everything came up working perfectly as far as I could tell (*). Both guest and main network seemed to be accessible via the mesh nodes.

(*) One thing that I didn't have time to re-test or debug is that the bandwidth limits I had placed on the guest network didn't appear to have any effect, at least from the mesh nodes. Could be user error or a known issue though, so I'll have to do some research and check it again when I'm back in the building.

Thanks to everybody involved in making these releases. Great job!

 

[RMerlin]

I was under the impression this happens after every 386 flash. If that's not the case then i suppose it can be dealt with. Thanks for clearing that up.

No, it`s just the first time you jump from 384 to 386. I suspect that Asus implemented database pruning with 386 to prevent the database growing insanely large (and filling up JFFS). People with a lot of logged data (for instance people with lots of clients and who haven`t reset in a long time) will take more time to do that first time cleanup, which is why for some people it can take even hours, and for others (like myself) it takes only a few minutes.

After that, it probably does automated maintenance, so the database never grows large enough to require much time to clean up.

 

[webdriver]

I upgrade to 386.2 recently. When check my log it keep printing this line:
---------------------------------------------------------------------
Apr 16 17:05:44 kernel: protocol 0800 is buggy, dev eth6


What should I look for? Thanks.

 

[anonimo]

Guest 1 works very well! Just use dynamically assigned IP addresses and not reserved or static. And you can use Stubby for DNSSEC.

No rush. I'll wait until it works properly before I upgrade.

 

[Treadler]

I upgrade to 386.2 recently. When check my log it keep printing this line:
---------------------------------------------------------------------
Apr 16 17:05:44 kernel: protocol 0800 is buggy, dev eth6


What should I look for? Thanks.

Post in thread 'AU86U - Merlin 386.1 - System Log errors'
http://www.snbforums.com/threads/au86u-merlin-386-1-system-log-errors.70157/post-661757