What's new

Asusmerlin version 42 slower than stock 5656

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

viperzxz

Occasional Visitor
Hi guys,

I don't know why, but when using Asus merlin, my maximum WiFi ac connection is 400, if I change firmware to stock 5656, maximum speed goes up to 866, but if I change firmware back to Asus merlin, it clocks down to 400mbps. Maximum speed drops on a Mac and a PC. thoughts?

Sent from my SM-T320 using Tapatalk
 
Hi guys,

I don't know why, but when using Asus merlin, my maximum WiFi ac connection is 400, if I change firmware to stock 5656, maximum speed goes up to 866, but if I change firmware back to Asus merlin, it clocks down to 400mbps. Maximum speed drops on a Mac and a PC. thoughts?

Sent from my SM-T320 using Tapatalk

I cant find stock 5656 to rt-n66u?
 
my router is rtac68u and i am on a mac too. tested both merlin and stock firmware and didn't experience any difference.
 
No Brainer.

Stay stock and wait for the next RMerlin version.:rolleyes:
 
If you want full functionality and stability, better stick to OFW.
Merlin's build not only add features, but also break some OFW function. After all it's not official.
 
Merlin's build not only add features, but also break some OFW function. After all it's not official.

Like specifically what?

AFAIK, I fix more issues than I create when compared to OFW.
 
If you want full functionality and stability, better stick to OFW.
Merlin's build not only add features, but also break some OFW function. After all it's not official.
:) I would most probably toss this router aside if it wasn't for the Merlin's firmware. You gotta be joking.
 
Like specifically what?

AFAIK, I fix more issues than I create when compared to OFW.

Like "PPPoE + ipv6 tunnel + CTF resulting not being able to access ipv6 sites" on AC68.
Now only OFW can handle this.
And it's not a CTF problem, because ASUS using same ctf.ko before and after they fixed "PPPoE + ipv6 tunnel + CTF resulting router reboot" issue, so like their custom service told me, they modified some ipv6 related parts. And I can see there're lots of additional module of ipv6 in Merlin's build and maybe some kernel module related to ipv6 are slightly modified by Merlin, so maybe there added feature and modification does conflict with something ASUS modified. It's known to all especially to coders that added feathers can always potentially introduce some bugs.
And user base on OFW is way much larger than 3rd partys', so the probability of finding bugs in OFW is far greater than in 3rd partys'.
Further more, if one got some problem, he can complain about the OFW to ASUS, like what I did about "PPPoE + ipv6 tunnel + CTF resulting router reboot" issue and with several mail exchange with their custom service, they finally got the bug fixed in 5656. But one can't complain to 3rd party firmware author when something went wrong.
For me, without this problem, I definitely love Merlin's build over OFW, but with this problem presented and I have no right to complain to a voluntary 3rd party FW developer, I can only go back to OFW.
 
Last edited:
:) I would most probably toss this router aside if it wasn't for the Merlin's firmware. You gotta be joking.

Yes, here, it's definitely a joking, because this is a section about Merlin's build, everybody here loves it, it's de facto official here. It's asus OFW that feels like some sort of 3rd party FW.
But it's not true once outside of this place.
 
Last edited:
I love RMerlin too, but i was forced to give up on version 374.42 for AC66U because of slower internet speed on PPoE using Gigabit WAN connection.

Strange thing with these upgrades:
374.40 - arround 750Mbps
374.41 - arround 600-650Mbps
374.42 - under or arround 500Mbps

Please don't let 374.43 go to 400Mbps or under...
 
I have the ac56u router.

With the stock 5656 firmware my cellphone (Galaxy S4) connects at 433 Mbps (1 stream).
With the merlin 42 firmware (latest) it only connects at 200 Mbps.

Also my laptop (N-300) connects at 150 and maybe fluctuates to 163 or so but usually 150. The Stock firmware gets me at 300. This is all in the same room as the router. I am the only one using the 5Ghz band.

I went back to stock. Not sure if it was the firmware or what, but it seems like the firmware. Will try the next version, but will skip 42.
 
Last edited:
Like "PPPoE + ipv6 tunnel + CTF resulting not being able to access ipv6 sites" on AC68.
Now only OFW can handle this.

Ah, right. That one single issue that is affecting you and that I haven't fixed *yet*. Have a look at the changelog sometime to see the number of bugs that were fixed in my firmware before they were fixed in the OFW, before saying that globally, my firmware is less stable and less reliable than OFW.

(BTW: Asus's OFW automatically disables CTF if you use a 6in4 tunnel on some router models.)

And user base on OFW is way much larger than 3rd partys', so the probability of finding bugs in OFW is far greater than in 3rd partys'.

This might apply in the case of a third party firmware that is totally built from the ground up like DD-WRT and Tomato, but in this case it does not apply since this FW is actually based on the OFW codebase. That means issues found and fixed in the OFW also get integrated into my firmware, generally within the following two weeks. So, it's not as if the two code bases were totally different.

And quite a few issues in the OFW were actually found and fixed by this community using my FW before the fix got integrated in stock. Things like non-working Parental Control, the random crashing issues when CTF was enabled on MIPS routers, networkmap randomly missing clients, non-working NAT loopback with CTF enabled - all of these issues were fixed by this community before they got fixed in the OFW.
 
BTW, I do know how Asus fixed it - I just had other priorities these past few weeks like trying to track down the traffic monitor issue which affects a larger userbase. Asus's fix is to mark those packets, which has the effect of making them bypass CTF:

Code:
> #ifdef RTCONFIG_IPV6
> 		if (get_ipv6_service() == IPV6_6IN4) {
> 			eval("ip6tables", "-t", "mangle", "-A", "FORWARD",
> 			     "-m", "state", "--state", "NEW", "-j", "MARK", "--set-mark", "0x01");
> 		}
> #endif

I just didn't have time yet to verify whether that patch wasn't correctly merged in, or if it was merged in the wrong location of the firewall code.
 
BTW, I do know how Asus fixed it - I just had other priorities these past few weeks like trying to track down the traffic monitor issue which affects a larger userbase. Asus's fix is to mark those packets, which has the effect of making them bypass CTF:

I just didn't have time yet to verify whether that patch wasn't correctly merged in, or if it was merged in the wrong location of the firewall code.

Thanks for the reply and time. Now put "ip6tables -t mangle -A FORWARD -m state --state NEW -j MARK --set-mark 0x01" in wanup and got a temporary workaround.
It's a good FW, and I like it.
Maybe some expressions like "Merlin's build not only add features but also break some function of OFW" is somewhat misleading and unfair for the developer, provoking the indignation of developer. It should've been "It may sometimes break", which is normal and conceivable considering this is developed by one man, and didn't go through some rigid QA process before its airing. So just want to tell what I experienced and thus there's some cases, if there's any, this FW may break something, which is rare for the developer but 100% incidence from the perspective of user having such problem, and if OFW works well without the problem, then maybe one should stay on that for a while and try the next release.
 
Last edited:
The problem was that the firmware uses two different functions to setup mangle settings. One of them is called if load balancing is enabled, the other one is called for other cases (no dual wan, or dual wan set to failover mode). The fix had only been applied to the first function but not the second. That's why it was working for some people (those who had Dualwan set to LB mode) and not for others.

The fix has been pushed to Github.
 
The problem was that the firmware uses two different functions to setup mangle settings. One of them is called if load balancing is enabled, the other one is called for other cases (no dual wan, or dual wan set to failover mode). The fix had only been applied to the first function but not the second. That's why it was working for some people (those who had Dualwan set to LB mode) and not for others.

The fix has been pushed to Github.

Is this fix related to what I reported?

Forgot to add, my router is ac56u.

Sent from my SM-T320 using Tapatalk
 
It should've been "It may sometimes break", which is normal and conceivable considering this is developed by one man, and didn't go through some rigid QA process before its airing.

I agree with you there. I certainly don't have the resources Asus's development team has. I might be able to focus on some particular issues because I don't have any project schedule to meet, so I can devote as much time as I want to these, but in general they are better positioned to debug and test a lot of the more advanced features which they develop.

This is one of the main reasons why I try to stay as close as possible to their code base, so I can always merge their own fixes in as they release new firmwares.
 
Is this fix related to what I reported?

Forgot to add, my router is ac56u.

Sent from my SM-T320 using Tapatalk

No, different issue (sorry for the thread hijack).

I haven't tested wifi on the AC56 recently, but from what I remember I'm using the same driver Asus is using in 5656, so I would expect the same performance. Try the usual debugging steps: setting a static channel, re-creating the wireless profile on your computer, etc...

Two additional settings that has made a different for other users were Beamforming (try disabling them both), and the 802.11d+h setting (this one especially impacts Apple devices).

I'll try to check next weekend in case the wireless driver found in Asus's GPL might not be the same they are using in the released firmware itself - it has happened in the past.
 
I love RMerlin too, but i was forced to give up on version 374.42 for AC66U because of slower internet speed on PPoE using Gigabit WAN connection.

Strange thing with these upgrades:
374.40 - arround 750Mbps
374.41 - arround 600-650Mbps
374.42 - under or arround 500Mbps

Please don't let 374.43 go to 400Mbps or under...

Your ISP is pushing 750 Mbps over PPPoE? :eek: Talk about a waste...

You might be using features that forces part of that traffic to not go through CTF, which is essential for WAN speeds beyond 150 Mbps on the RT-AC66U. Make sure you disable unnecessary features such as VPN servers, IPTraffic (which would force HW acceleration to be disabled) and IPv6 tunneling (Asus disables HW acceleration when using 6in4 tunnels on the N66 and AC66).

It might also be worth upgrading to a router with a faster CPU, such as either the RT-AC56 or AC68 to better handle such WAN speeds.
 

Sign Up For SNBForums Daily Digest

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