What's new

[Fork] Asuswrt-Merlin 374.43 LTS releases (Archive)

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

Exactly :) and it rock solid
I'll second and have to say on the AC66 (MIPS) performance is definitely better than any of the later builds. I went up through Merlin 378.54_1 and while I liked the UI changes of the latter builds the wifi performance and throughput of the 374 code base seems to be better at least on the older AC66 and that is more important to me. (not that the 376/378 was horrible but definitely noticeable difference) Nice to get the security and bug fixes and still be able to keep the performance!
 
To make sure I'm understanding this correctly, this fork doesn't offer new features/functionality over what is found in asuswrt-merlin. Rather, this fork is intended to fix bugs and keep up-to-date the older 374 code base for those feel later code bases negatively affected performance.

Is that correct-ish?
That's the main reason along with keeping up with the major security updates....but you do also get some of the features in the newer codes as well as some unique features in response to user requests.

For example....

OpenVPN policy based routing, custom DDNS scripting and status checks and multiple DNS management have been backported from the newer releases.

Turning off JFFS syslog, setting the cron logging level, no DLNA scan on reboot and syslog entries for gui login/logout have been added by user request.

Those are just the ones that immediately came to mind...
 
John has also done some things which merlin took on afterwards, such as backporting openssl 1.0.2 and fixing the cache performance issue on the newer models. He spends a lot of time trying to make us all happy and I thank him for it.
 
Hi @john9527

I have installed your last version to test the DSCP fix on my RT-N16 since my isp causes the same issue as Comcast (MEO isp from Portugal)

The fix have not worked for me , and disabling WMM is not doing the trick either with build 374.43_2-13E1j9527.

The tomato fix Works very well in tomato firmware and is implemented on they're last firmware , but since i rly like the ASUSWRT i hope you will fix it to.

In the original ASUSWRT disabling WMM does the trick on my RT-N16


thanks for all your work, and if you need a Lab rat for this issue, I'm here to do any test you need .
 
Hi @john9527

I have installed your last version to test the DSCP fix on my RT-N16 since my isp causes the same issue as Comcast (MEO isp from Portugal)

The fix have not worked for me , and disabling WMM is not doing the trick either with build 374.43_2-13E1j9527.

The tomato fix Works very well in tomato firmware and is implemented on they're last firmware , but since i rly like the ASUSWRT i hope you will fix it to.

In the original ASUSWRT disabling WMM does the trick on my RT-N16


thanks for all your work, and if you need a Lab rat for this issue, I'm here to do any test you need .
I checked on my 68R and everything looks like it gets enabled correctly. So I'll need some help from you to collect data on the N16 with the fix enabled....

telnet/ssh to the router.....

First, make sure the nvram is set correctly (this should return 1)
nvram get DSCP_fix_enable

next check the rules by entering
iptables -t mangle -L -v

you should see something like this right at the beginning....the key line is the line containing DSCP, showing it's active and processing packets. If this is correct, it would indicate that the fix is active and working.
Code:
Chain PREROUTING (policy ACCEPT 17M packets, 17G bytes)
pkts bytes target     prot opt in     out     source               destination
6519K 8402M CONNMARK   all  --  eth0   any     anywhere             anywhere             CONNMARK restore mask 0x7
    0     0 MARK       all  --  !eth0  any     anywhere             ip70-xxx-xxx-xxx.tc.ph.cox.net  MARK set 0xb400
6519K 8402M DSCP       all  --  eth0   any     anywhere             anywhere             DSCP set 0x00

if the above check fails (or just for completeness),

check that the DSCP module is available and loaded (should return a single line containing dscp)
lsmod | grep dscp

and finally that the correct module is available (again, should return a single line)
modprobe -l | grep dscp
 
About the "Comcast fix", is there a way to check if my Comcast setup is affected by the issue? Also, does this firmware auto-detect for the issue and set DSCP_fix_enable automatically or is DSCP_fix_enable set by default?

I also remember reading on one of these pages that some features were disabled on N16 routers. I can't seem to find that page now. Is that true or am I mixing things up?
 
About the "Comcast fix", is there a way to check if my Comcast setup is affected by the issue? Also, does this firmware auto-detect for the issue and set DSCP_fix_enable automatically or is DSCP_fix_enable set by default?
The fix is not automatically enabled, it is an option on the firewall tab in the fork. Right now there isn't any way to determine if you are affected, except to enable the fix and do a download test from a wireless client. (It is coded that way to try and keep the fix as 'lightweight' as possible.)

I also remember reading on one of these pages that some features were disabled on N16 routers. I can't seem to find that page now. Is that true or am I mixing things up?
I know the OpenVPN Server and Client aren't supported. I'd have to dig a bit more to double check any others.
 
I checked on my 68R and everything looks like it gets enabled correctly. So I'll need some help from you to collect data on the N16 with the fix enabled....

telnet/ssh to the router.....

First, make sure the nvram is set correctly (this should return 1)
nvram get DSCP_fix_enable

next check the rules by entering
iptables -t mangle -L -v

you should see something like this right at the beginning....the key line is the line containing DSCP, showing it's active and processing packets. If this is correct, it would indicate that the fix is active and working.
Code:
Chain PREROUTING (policy ACCEPT 17M packets, 17G bytes)
pkts bytes target     prot opt in     out     source               destination
6519K 8402M CONNMARK   all  --  eth0   any     anywhere             anywhere             CONNMARK restore mask 0x7
    0     0 MARK       all  --  !eth0  any     anywhere             ip70-xxx-xxx-xxx.tc.ph.cox.net  MARK set 0xb400
6519K 8402M DSCP       all  --  eth0   any     anywhere             anywhere             DSCP set 0x00

if the above check fails (or just for completeness),

check that the DSCP module is available and loaded (should return a single line containing dscp)
lsmod | grep dscp

and finally that the correct module is available (again, should return a single line)
modprobe -l | grep dscp
hi

I have figuredout my problem, the symptom was exactly the same of the DSCP bug , so a assumed that my isp had messed up the DSCP.

But in the end i was causing the problem, i was Short on sapace on my desk so i placed my RT-N16 on top of a CRT Television, MY bad :( , and this make the router to have that behavior.

thanks for you fast help and sorry i made you waste your time.
 
Last edited:
Hi John, I've just been using the network services filter.

I noticed that when I enter "<" or ">" as either of the port ranges it is being interpreted as "<=" and ">=".

i.e, "<100" is translated to "1:100" and ">100" becomes "100:65535".

Maybe it's always done this. Anyway, I thought I'd let you know.
 
Hi John, I've just been using the network services filter.

I noticed that when I enter "<" or ">" as either of the port ranges it is being interpreted as "<=" and ">=".

i.e, "<100" is translated to "1:100" and ">100" becomes "100:65535".

Maybe it's always done this. Anyway, I thought I'd let you know.

Yes...always been that way since the code was originally written in 2011.11
At this point I'm not inclined to touch it and change a long standing implementation (and break people who may have already have it set up)
 
Thanks for the update John :) I just updated my rt-n66u from ver 7 to ver 13E1. Done a factory reset and reconfigured everything manually.

Two problems I ran into:

1) The TCP connection limit didnt stay at 300,000 like it should. I entered the value manually instead.
2) Under WAN --> Internet connection, I changed the option of 'Redirect to error page' from "none" to "link or wan down", however when I clicked apply the change wouldnt commit? I am using IE 9. To overcome this I used an ipad (safari) and changed the setting there where it then commited correctly and applied my change.

Something I did notice though is now under Wireless --> Professional (5Ghz) the 'Regulation mode' option does not have an "off" option, instead you have to choose between "80211 d" or "80211 d+h". I dont mind this, just something I happened to see

Everythings working well anyway (so far...) Thanks again John and Merlin :)
 
Thanks for the update John :) I just updated my rt-n66u from ver 7 to ver 13E1. Done a factory reset and reconfigured everything manually.

Two problems I ran into:

1) The TCP connection limit didnt stay at 300,000 like it should. I entered the value manually instead.
Sigh....yes, it turns out I only had 1/2 a fix (now I know why Asus didn't make it changeable originally :oops:). I promise it will be really, REALLY be fixed in the next release...along with a fix that will correct it for those that didn't notice it was changed incorrectly by the factory reset .
2) Under WAN --> Internet connection, I changed the option of 'Redirect to error page' from "none" to "link or wan down", however when I clicked apply the change wouldnt commit? I am using IE 9. To overcome this I used an ipad (safari) and changed the setting there where it then commited correctly and applied my change.
Couldn't recreate it under IE10. One thing that always catches me though on those pulldowns, if you leave the mouse pointer in the pulldown field after making a change, and try to scroll, it will scroll the values in the pulldown first. (not unique to the ASUS gui, also happens on this site for example) Maybe?
Something I did notice though is now under Wireless --> Professional (5Ghz) the 'Regulation mode' option does not have an "off" option, instead you have to choose between "80211 d" or "80211 d+h". I dont mind this, just something I happened to see
I think you meant 802.11h or 802.11d+h. That change went in a while ago for EU routers. Trying to walk the fine line here....out-of-the-box, the code will enforce the right regulatory requirements. What people may change afterwards.....

Everythings working well anyway (so far...) Thanks again John and Merlin :)
 
On my RT-AC68U, I currently have the latest Asus stock fw 378.

When installing John's fork fw, is it recommended to do something prior (ie factory reset or downgrade to a different version of asus stock fw, etc)?

I just want to make sure that I do this properly. Thanks.
 
On my RT-AC68U, I currently have the latest Asus stock fw 378.

When installing John's fork fw, is it recommended to do something prior (ie factory reset or downgrade to a different version of asus stock fw, etc)?
Hi,

Always the same procedure: :rolleyes:
1) Remove USB devices and reboot (to avoid memory shortage during update or downgrade)
2) Install the chosen firmware version
3) Do a factory reset (always AFTER the installation)! ;)
4) Re-configure your router with the new firmware
5) Be happy with the new firmware! :p

With kind regards
Joe :cool:

PS.: Professionals add the following topics to the list:
0) Backup the current settings (via Firmware GUI and via the User NVRAM Save/Restore Utility)
4a-1) Restore the user setting with the User NVRAM Save/Restore Utility (no need to re-type all the settings manually)
4a-2) If you go back to the previous installed version, just restore the settings via the GUI - no need for the usage of the User NVRAM Save/Restore Utility
5a) Be more happy as it was less work to switch firmware!
 
This firmware has made a huge improvement in my wireless range and performance. Getting full 4 bars in parts of my home where I would previously see 2-3 bars. Thanks to the OP for this great file.
 
This firmware has made a huge improvement in my wireless range and performance. Getting full 4 bars in parts of my home where I would previously see 2-3 bars. Thanks to the OP for this great file.

There is NO doubt this Merlin fork by John is a true winner all the way around. Thanks again John !!! :)
 
  • Like
Reactions: jk1
I assume that this fork does not apply to the ASUS AC51U?
 
Sigh....yes, it turns out I only had 1/2 a fix (now I know why Asus didn't make it changeable originally :oops:). I promise it will be really, REALLY be fixed in the next release...along with a fix that will correct it for those that didn't notice it was changed incorrectly by the factory reset .

Ok thanks for that John!

Couldn't recreate it under IE10. One thing that always catches me though on those pulldowns, if you leave the mouse pointer in the pulldown field after making a change, and try to scroll, it will scroll the values in the pulldown first. (not unique to the ASUS gui, also happens on this site for example) Maybe?

I'll give that a go! Something to remember for next time, thanks :)

I think you meant 802.11h or 802.11d+h. That change went in a while ago for EU routers. Trying to walk the fine line here....out-of-the-box, the code will enforce the right regulatory requirements. What people may change afterwards.....

Yes sorry, I forgot to add the decimal point :oops:. Ahh ok. Thanks for the explanation. I've just kept it as 802.11d+h and everything's working we'll, so I'm happy :)
 

Latest threads

Sign Up For SNBForums Daily Digest

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