What's new

Release Asuswrt-Merlin 386.7 is now available for all models

  • 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!

Status
Not open for further replies.
I can even do that with my Asustor (I tested it a few weeks ago to see how much I could get out of 160 MHz wifi). But I don`t consider a plastic USB dongle to be a reliable long-term solution, as they run rather hot. There`s no excuse for Synology to still be only Gigabit in 2022 IMHO.


Why would it have? I don't expose it to the WAN...

Just the general issue with turn key solutions like consumer NAS’s, the devices try to be all purpose and in turn cause people to lose the data it’s supposed to protect because they are not updated regularly enough by the manufacture and vulnerability’s are discovered when it’s already too late.

Not something you want accessible to WAN. Unfortunately Qnap, and Synology are in the same boat.
 
Just completed a smooth, dirty flash from the previous 386_7 beta to this, the official release of 386_7
Once again; No issues or problems at all. Everything is running perfectly so far. Thanks again @RMerlin
 
I can even do that with my Asustor (I tested it a few weeks ago to see how much I could get out of 160 MHz wifi). But I don`t consider a plastic USB dongle to be a reliable long-term solution, as they run rather hot. There`s no excuse for Synology to still be only Gigabit in 2022 IMHO.


Why would it have? I don't expose it to the WAN...


5Gbe dongle works great warm to the touch, but not worried about it melting like the cheap plastic ones (I replaced two of those that died after a few minutes).

This has a nice metal heat sync for its case. Downside is well it’s 5Gbe link speed is real the usb controller on it has a lot of overhead with the usb protocol so best I’ve got was 318MBps using smb direct.
 
Dirty upgrade of my 3 systems from 386.5_2 in this order:
1. RT-AX56U Aimesh node 1
2. RT-AX56U Aimesh node 2
3. RT-AX86U Aimesh main

all went OK

Thanks RMerlin
 
Hi, do we have to reset/restore JFFS on RT-AX86U after upgrade, just like in the beta? I can't see any mention on the changelog anyhow
 
Hi, do we have to reset/restore JFFS on RT-AX86U after upgrade, just like in the beta? I can't see any mention on the changelog anyhow
Just did a dirty upgrade from 386.5_2 of my AX86U, and JFFS not impacted at all
 
Just updated my RT-AX86U and RT-AX58U without any problems.
No problem with /jffs.

Thank you @RMerlin
 
have to ask if you dare to update my sister's router which is an rt-ax86u, my router will have to wait due to repair of the last time you tried the trial version,

would like to have the green light that it is safe to update it
 
Upgraded my system to 386_7.
AX88U*2.

Sadly, it has few bugs from Alpha/Beta that still not recovered.

Once I just upgraded the FW, Fetching WAN IP takes it a lot if time.
It even caused some kind of reboot or something.

So IPv4 became harder to fetch, Ipv6 is not fetched at all here.
Yesterday, during issues with my ISP it made me reboot my router 4 times in a row, usually would not have to do it once at all because it would fetch IPv4 by itself.

For now, impossible to use, will downgrade currently to 386_5.
Hopefully 386_7.2 will arrive fast with changes to WAN IPv4/IPv6 fetch.
Something with the ASUS sdk changes is made it harded to actually use.

Edit: Rewined to 386_5.2, IPv4 fetched like usual- IPv6 probably did not release address prior to the rewind.
I did notice that the ring uses IPv6 only communication, so if I fail to communicate IPv6 it would not work.

For now I stay 386_5.2 for the stabillity, hopefull 386_7.2 will fix these issues with AX88U.

Thank you for your hard work.
 
Last edited:
Upgraded my system to 386_7.
AX88U*2.

Sadly, it has few bugs from Alpha/Beta that still not recovered.

Once I just upgraded the FW, Fetching WAN IP takes it a lot if time.
It even caused some kind of reboot or something.

So IPv4 became harder to fetch, Ipv6 is not fetched at all here.
Yesterday, during issues with my ISP it made me reboot my router 4 times in a row, usually would not have to do it once at all because it would fetch IPv4 by itself.

For now, impossible to use, will downgrade currently to 386_5.
Hopefully 386_7.2 will arrive fast with changes to WAN IPv4/IPv6 fetch.
Something with the ASUS sdk changes is made it harded to actually use.

Edit: Rewined to 386_5.2, IPv4 fetched like usual- IPv6 probably did not release address prior to the rewind.
I did notice that the ring uses IPv6 only communication, so if I fail to communicate IPv6 it would not work.

For now I stay 386_5.2 for the stabillity, hopefull 386_7.2 will fix these issues with AX88U.

Thank you for your hard work.
You are giving very little information, e.g., from which version are you coming from? Was a reset completed, what type of reset? Manual rebuild completed, load of a backup/configuration file, reset of the JFFS partition? Wan/LAN, Professional settings, etc., that you are using and or tried? What have you completed from a trouble shooting perspective? Are you running an AiMesh setup? Nobody here has a crystal ball, a more informative answer can only be obtained from this forum, giving people the right information to work with, to formulate and answer/help with your issue/s. Where is the backup/proof, of your complaints? Supply a snippet of your router log for review by the many guru's that are here within this forum. The output and help provided to you will/maybe, help others within this forum, for I am sure a possible solution and or maybe, identify a genuine bug within the firmware.

Is it me, or just, do some people forget/not understand, how lucky we are to have the ability/use, a Merlin provided, alternative ASUS router firmware, an individual, generously sharing his own time, to provide us, a better ASUS router fit/experience, to proper our requirements/wish list/development/features. Which, may I remind people, we can all contribute, in its (firmware), development from Merlin.

My apologies to the forum, rant finished.
 
Last edited:
I just completed a dirty upgrade on my RT-AC88U from 386.5_2 to 386.7_0. All went smoothly (thankyou!) but when I checked the WiFi channels after the upgrade, the professional 'Region' setting had changed from 'Australia' to blank. I changed the Region to Australia, saved the settings and the router rebooted as normal. However, after reboot with the Region now showing as Australia I now have only 5GHz channels 36-48 and 149-165 available for selection, whereas previously I had all of the Australian regulatory approved channels available, ie. 32-48, 50-68 (DFS), 96-116 (DFS), 132-144 (DFS) and 149-165.

I'm seeing the correct list of 2.4GHz channels being available for selection, ie. 1-13, so the problem appears to be confined to the 5GHz channel selection.

Is doing a full reset likely to fix the issue? Or is this a bug in 386.7_0?

Thanks for all your excellent work on the Merlin project - very much appreciated!
 
You are giving very little information, e.g., from which version are you coming from? Was a reset completed? Manual rebuild completed? Wan/LAN, Professional settings, etc., that you are using and or tried? What have you completed from a trouble shooting perspective? Are you running an AiMesh setup? Nobody here has a crystal ball, a more informative description/answer to an issue, can only be obtained from this forum, giving people the right information to work with, to formulate and answer/help with your issue/s. Where is the backup/proof, of your complaints? Supply a snippet of your router log. The output and help provided to you and by you, will/maybe, only help others within this forum.

It was dirty upgrade- 386_5.2 - 386.7Alpha- 386.7 b1- 386.7 b2 - 386.7 Release.
On the early stages of Alpha/Beta I had those issues mentioned..
Merlin mentioned SDK changes were made by ASUS , not sure if it is related (or not) and if it could cause such issues to IPv4/v6.

Maybe will have some time to make a proper backup and full factory and upgrade.
 
Updated from 386.7_Beta2 to 386.7

All apparently running OK but every few minutes I'm getting the following message in syslog that I've never seen before, not even in 386.7_Beta2.

Code:
kernel: CFG80211-ERROR) wl_cfg80211_sta_info : GET STA INFO failed, -21
 
It was dirty upgrade- 386_5.2 - 386.7Alpha- 386.7 b1- 386.7 b2 - 386.7 Release.
On the early stages of Alpha/Beta I had those issues mentioned..
Merlin mentioned SDK changes were made by ASUS , not sure if it is related (or not) and if it could cause such issues to IPv4/v6.

Maybe will have some time to make a proper backup and full factory and upgrade.
I would suggest a full reset and manual rebuild on this version and see if your problem/s still exist. At least then, you have a fresh start to identify issues., if any.
 
Last edited:
Status
Not open for further replies.

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