ASUS Mesh Network - Firmware Question

[GWTechTalk]

I recently moved to a mesh network in my home.

I purchased a new AX6600 (XT8) as the main router and converted my AX92U into a mesh node.

Everything is working great however I have a question I cant seem to find the answer to.

AX92U is no longer receiving firmware updates due to its age, however, it seems there is a newer version available for the new AX6600 (XT8).

My gut says to keep them on the same firmware as the only difference between the two is the AX6600 has a 2.5Gbe WAN port, fewer LAN ports, and the AX6600 is Quad-core vs. the AX92U Dual Core.

AX6600 - 3.0.0.4.386_46061 (Avaiable - Version 9.0.0.4.386.48966 Beta Version or Version 3.0.0.4.386.48706 Official)

AX92U - 3.0.0.4.386_46061

I do not want to go to ASUS Merlin custom firmware due to the lack of support for the AX band in its current state.

My fear is if they put something into the main node that does not translate properly to the mesh node there could be issues. At the networking core there should never be a problem but ASUS does very weird things in their networking coding, especially with their WAN setups.


Let me know your thoughts.

 

[L&LD]

Welcome to the forums @GWTechTalk.

Myself, I would upgrade the firmware to the latest stable release (at least to test).

In your situation, I would wait for the 'matched' version of the firmware for the RT-AX92U before updating anything.

Your second-last sentence makes no sense. Thousands of users are using RMerlin firmware with the AX band working as expected.

 

[OzarkEdge]

I recently moved to a mesh network in my home.

I purchased a new AX6600 (XT8) as the main router and converted my AX92U into a mesh node.

Everything is working great however I have a question I cant seem to find the answer to.

AX92U is no longer receiving firmware updates due to its age, however, it seems there is a newer version available for the new AX6600 (XT8).

My gut says to keep them on the same firmware as the only difference between the two is the AX6600 has a 2.5Gbe WAN port, fewer LAN ports, and the AX6600 is Quad-core vs. the AX92U Dual Core.

AX6600 - 3.0.0.4.386_46061 (Avaiable - Version 9.0.0.4.386.48966 Beta Version or Version 3.0.0.4.386.48706 Official)

AX92U - 3.0.0.4.386_46061

I do not want to go to ASUS Merlin custom firmware due to the lack of support for the AX band in its current state. Let me know your thoughts.

I can't be sure a model will no longer receive firmware updates, even after it is EOL.

I would keep the router current... you can always revert to previous firmware.

OE

 

[GWTechTalk]

Welcome to the forums @GWTechTalk.

Myself, I would upgrade the firmware to the latest stable release (at least to test).

In your situation, I would wait for the 'matched' version of the firmware for the RT-AX92U before updating anything.

Your second-last sentence makes no sense. Thousands of users are using RMerlin firmware with the AX band working as expected.

Thanks for your response. When I checked the merlin site neither of my routers was on the supported list and most states due to the lack of AX band support could be the chip specifically used. I shall do some testing after work.

 

[L&LD]

I didn't check RMerlin support for your models, but the statement about the AX band is most certainly not accurate at all.

 

[raven-au]

I didn't check RMerlin support for your models, but the statement about the AX band is most certainly not accurate at all.

Check out https://gnuton.github.io/asuswrt-merlin.ng/ for a fork of the Merlin firmware for the XT8.
If the AX92U is used as a node its firmware could just stay as stock.

In my experience there can be some hiccups if the firmware gets out of sync. between the devices on
the AiMesh but not often. Clearly you should try and keep them fairly close, as best you can anyway,
but as long as they don't get too far out of sync. you should be ok.

 

[L&LD]

Yes, see post 2 above. (I think we're saying the same thing).

 

[GWTechTalk]

Check out https://gnuton.github.io/asuswrt-merlin.ng/ for a fork of the Merlin firmware for the XT8.
If the AX92U is used as a node its firmware could just stay as stock.

In my experience there can be some hiccups if the firmware gets out of sync. between the devices on
the AiMesh but not often. Clearly you should try and keep them fairly close, as best you can anyway,
but as long as they don't get too far out of sync. you should be ok.

I read through all the documentation and I didn't find anything specifically showing Merlin is better than stock. Merlin just seems to be slimmed down and user-configurable whereas ASUS stock is packed full of third-party software and no GUI modification, SSH / CLI still works fine.

The documentation says that merlin is more efficient or stable but not much to back that up. Four years ago I archived my last Linksys (Open / DDWrt) router and then switch to TP-link. TP-Link was a monumental pile of overheating garbage so I returned it and went to ASUS. Other than a fun networking project I don't see a reason to switch to Merlin. The only reason I might want to is if I can move my pi-hole from my pi4B to the main router to improve throughput. I don't have a need for external VPNs, port bonding, subnets (Although with so many IOT I should), or SSL certificate implementations.

I really only use ASUS now for its ease of use, parental controls/wifi scheduling, and specific features.

The new router model allows me to have a 2.5Gbe interface to my FIOS ONT so if in the future I decide the price of 2000/2000 Mbps is worth it, Frontier can just flip a switch, and its game on.

It's very surprising that even with 4 cores the QoS can only achieve a 300Mbit TP. It's nice to have the AX backhaul which they call mesh but let's be honest that's a gimmick. Wifi bridges have been a thing for a while but have not been used because of bandwidth limitations. I remember when I had 2 WRT54GL in the wireless bridge just because I could.

 

[L&LD]

Your reading is not lined up with your conclusions about how superior RMerlin-based firmware is on supported models.

Asus has a team of developers and brings new firmware to life.

RMerlin takes that firmware (if/when the GPL is released) and goes over it with a fine-toothed comb.

He releases it as an Alpha, and a Beta, and has multiple iterations as needed of each, depending on feedback from testing within this community/forums.

With the known bugs worked out (i.e. in most cases, Asus' bugs), a new RMerlin release becomes available.

And, after all that, you really think RMerlin isn't better than stock?

And, that isn't even counting the features, options, and scripts that RMerlin, amtm, and many other developers, expose.

Nor counting the updated and more secure bits and blobs of code that other manufacturers haven't updated in a decade.

Nor taking into account the further tweaking/fixing that @GNUton puts into his version of the RMerlin fork.


Sometimes, you need to take a step back to see the forest from the trees.

And sometimes, you need to leap on faith before logic shuts off a possible solution too.

 

[GWTechTalk]

Your reading is not lined up with your conclusions about how superior RMerlin-based firmware is on supported models.

Asus has a team of developers and brings new firmware to life.

RMerlin takes that firmware (if/when the GPL is released) and goes over it with a fine-toothed comb.

He releases it as an Alpha, and a Beta, and has multiple iterations as needed of each, depending on feedback from testing within this community/forums.

With the known bugs worked out (i.e. in most cases, Asus' bugs), a new RMerlin release becomes available.

And, after all that, you really think RMerlin isn't better than stock?

And, that isn't even counting the features, options, and scripts that RMerlin, amtm, and many other developers, expose.

Nor counting the updated and more secure bits and blobs of code that other manufacturers haven't updated in a decade.

Nor taking into account the further tweaking/fixing that @GNUton puts into his version of the RMerlin fork.


Sometimes, you need to take a step back to see the forest from the trees.

And sometimes, you need to leap on faith before logic shuts off a possible solution too.

I understand what your putting down. However, my observation was just that Merlin doesn't seem to list what they fixed or made better. They simply say it's better, which very well may be true. I'm not trying to dog anyone just trying to get actual statistics or examples of where Merlin was more stable, and better performing. etc... How is Merlin or @GNUton measuring this or coming to this conclusion?

It's one thing to say something is better and another to prove it.

Of course, I intend to test it for myself.

 

[L&LD]

To 'prove it', you need to compare the versions of the components RMerlin issues, with what Asus (or other manufacturers) deem 'good enough'. How good are you at reading source code?

I used to change back to stock Asus firmware to compare what the then-latest RMerlin firmware offered. Needless to say, I stopped doing that. Too many benefits that far outweigh any temporarily small performance gain stock firmware enjoys once in a blue moon.

A (better) search or two will bring many posts of the benefits of RMerlin firmware.

 

[GWTechTalk]

I can read source code to an extent. Do they have a living changelog per version?

EG. Repaired syntax of code string to enable more efficient completion of task A
EG. Removed section A to make the communication stream more compact and efficient under task A
EG. Added support for chipset model BCMXXX
EG. Added / Replaced third-party feature XXX with Linux configurable genic package example.xtz

 

[Smokey613]

The reason I run Merlin is the ability to run 3rd party scripts that allow me to do things the factory firmware does not. The two biggest for me are VPN Director and the new @Ranger802004 Dual-WAN failover script.

I know my post is a little off-topic but I felt compelled to add my support for Merlin.

 

[L&LD]

I can read source code too. Understand next to zero though.

Explaining the magic and giving supporting evidence of why it is better magic is more work than its worth. Those examples you seek may be partially exposed on each version's changelog. The rest may be inferred from the RMerlin website itself.

Source Code | Asuswrt-Merlin


I have given you the general idea of why RMerlin is superior.

The only way to get the definitive answers you seek is to use it, compare it to stock on the things you're concerned about and then ideally, reporting those things to us too.

 

[Ranger802004]

As far as documentation or information on what is actually changed, Google is your friend.

Features of Merlin:

Features | Asuswrt-Merlin

www.asuswrt-merlin.net

Changelog:

Changelog (388.x) | Asuswrt-Merlin

www.asuswrt-merlin.net

 

[Tech9]

My gut says to keep them on the same firmware as the only difference between the two is the AX6600 has a 2.5Gbe WAN port, fewer LAN ports, and the AX6600 is Quad-core vs. the AX92U Dual Core.

You are on the right track, but there are some details:
- both router have different hardware and the firmware is different too, just the release number is the same
- XT8 has quad-core CPU, but the dual-core in AX92U is actually faster, different type CPU cores
- I would keep the routers on stock Asuswrt, based on your basic requirements plus AiMesh setup
- I would keep them both on the same GPL base firmware, in this case Asuswrt 46061

I didn't find anything specifically showing Merlin is better than stock.

Asuswrt-Merlin is built on top of stock Asuswrt code base. The same GPL Asuswrt and Asuswrt-Merlin have the same LAN and WLAN performance. Hardware drivers are the same version and closed source, can't be changed. All TrendMicro components and Asus AiMesh are also closed source and can't be changed. Asuswrt-Merlin offers more configuration options plus custom scripts ecosystem. What is better is subjective and depends on what do you need and expect. In your case stock Asuswrt is what do you need. If you change your requirements later on, going from stock Asuswrt to Asuswrt-Merlin and back is not an issue. This firmware is not some hackish version, but built with Asus cooperation and approval. Asuswrt-Merlin gets upstream Asuswrt fixes, some Asuswrt-Merlin features arrive to stock Asuswrt. Keep in mind setting up AiMesh in Asuswrt-Merlin may require extra steps. Wireless node discovery may not work as described in Asus documents. This is one of the reasons I recommend stock Asuswrt over Asuswrt-Merlin in you specific case.