Release Asuswrt-Merlin 386.2 is now available

[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.

 

[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.

 

[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

 

[ChickenMilk]

Been using Asuswrt-Merlin and lurking this forum for a few years now with no issues but...
Since trying to update to any of the 386 Code bases on my AC3100, my port forwarding no longer works. I have Skynet and Diversion installed on my router. When checking the GUI, all my port forwarding rules are still there. Going back to 384.19 restores the Port Forwarding back to normal. Is anyone else having this issue or can offer any advice?

 

[SomeWhereOverTheRainBow]

Been using Asuswrt-Merlin and lurking this forum for a few years now with no issues but...
Since trying to update to any of the 386 Code bases on my AC3100, my port forwarding no longer works. I have Skynet and Diversion installed on my router. When checking the GUI, all my port forwarding rules are still there. Going back to 384.19 restores the Port Forwarding back to normal. Is anyone else having this issue or can offer any advice?

check your nvram usage on the tools/sysinfo-tab while using the new firmware version.

 

[davidh44]

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 imagine some people are power cycling their routers when unable to access the GUI after 384->386 as they didn't read the readme. Does the maintenance pick up where it left off if a power cycle interrupted it?

I wonder if that's why some people are getting the "Invalid firmware file" error when trying to update from 386.1 to a newer 386 firmware.

 

[Mine Ong]

pardon the naïve question: I am currently on Merlin 386.1, having switched from Asus official firmware for tighter integration (using Diversion on USB attached to the router instead of running pi-hole on a separate SBC). All my routers (Aimesh router + nodes) are on 386.1.

Can I do a dirty flash on 1) Aimesh router, and 2) nodes? In the past, I have always erased nvram and start from scratch, but I would like to avoid it this time. Will my scripts (Diversion, etc) and settings (static DHCP tables, etc) continue to function after dirty flash?

regards,