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

[zilexa]

Is there still a reason to use this fork, now that Asuswrt-Merlin is rockstable and has been on 378 for a long while?

 

[Gravityz]

If you want a ferrari with the power of a kia and the limitation of using only the right lane, stick with 378.

If you want a ferrari with the power of a ferrari and a choice of which lane to use you want to go eith this fork firmware.

Standard asus firmware maybee solid but it had lots of limitations in range and choice of channels

 

[lepa71]

I wouldn't call Merlin's .55 "ferrari with the power of a kia". It is may be like Toyota or Honda, solid and reliable, but I have issues with .55 version dropping wifi. I don't have this issue with previous Merlin's version.
I believe this fork uses older drivers that don't have limitation as newer drivers used in .55 have.

If you want a ferrari with the power of a kia and the limitation of using only the right lane, stick with 378.

If you want a ferrari with the power of a ferrari and a choice of which lane to use you want to go eith this fork firmware.

Standard asus firmware maybee solid but it had lots of limitations in range and choice of channels

 

[rbird2]

Is there still a reason to use this fork, now that Asuswrt-Merlin is rockstable and has been on 378 for a long while?

This is the first Firmware I have used that has run without requiring a weekly reboot of the router. It's fast and rock solid. That's why I'm using it.

 

[abat119]

Hey John,
Just wondering why you changed the priority percentages in QOS to 5% increments? Also, does it need to add up to 100% total or can I have for example "Highest pirority = 90%" and "Low priority = 40%" etc, adding up to a total of more than 100%? I never really understood this section of QOS...

Anyway, thanks in advance! Firmware working great on my AC66U btw : - )

 

[SuperFly74]

Is v14 better Then v13


Sent from my iPhone using Tapatalk

 

[ika]

Greetings again,

I was lurking silently for a long time since I had no problems. Of course,John (and Merlin) still got my full respect and admiration for their awesome work.

To the point, : I use my dlna server every day since many years. and the playback is very choppy and stops/skips since I updated to v14E1 (from v14). I'm really not in the mood to reset my router to factory defaults, so I would like to know if there is a setting I should try to play with first.

Any help would be greatly appreciated,
Noble regards,
Ika

ps.: I will need to buy a new router for somebody next week and I was wondering if you had time to support the N18u (since you mentioned once that it's on your lists). I see that you still didn't had time to do it, but don't get me wrong please, I'm not complaining at all, just curious if it's still on your list somewhere or you actually tried and dropped the idea. I guess it would need a lot of work, so I understand if you won't do it.

 

[john9527]

Hey John,
Just wondering why you changed the priority percentages in QOS to 5% increments? Also, does it need to add up to 100% total or can I have for example "Highest pirority = 90%" and "Low priority = 40%" etc, adding up to a total of more than 100%? I never really understood this section of QOS...

Anyway, thanks in advance! Firmware working great on my AC66U btw : - )

For the increments.....two reasons
- First, IMO 1% steps implies a level of precision that just isn't there
- Second, when I was investigating/testing how QOS worked, it was just a pain to scroll through that big list every time I wanted to change things around

For your second question, yes, it can add up to more than 100%. I'm definitely not an expert on the various queuing algorithms, but I think of it as targets starting from the highest priority to the lowest. It tries its best to manage things to meet all the targets, but if your line is totally saturated, it will end up essentially allocating the bandwidth based on the relative proportions of the targets. (Any expert here is welcome to jump in!)

 

[john9527]

Is v14 better Then v13


Sent from my iPhone using Tapatalk

Of course

But upgrading depends on what you are using. If you are using VPN Client and also have IPv6 I'd recommend updating to close a DNS leak exposure.
Other than that, there are some fixes (prevent you from entering names in fields that can cause problems, SSID display, USB disk utility, QOS improvements), some general component maintenance, and some new functions (IPv6 DNS caching, dnsmasq/ipset support, change http port, new LED stealth option, enable/disable scripts). As always, depends on your environment and if any of these affect you.

 

[john9527]

Greetings again,

I was lurking silently for a long time since I had no problems. Of course,John (and Merlin) still got my full respect and admiration for their awesome work.

To the point, : I use my dlna server every day since many years. and the playback is very choppy and stops/skips since I updated to v14E1 (from v14). I'm really not in the mood to reset my router to factory defaults, so I would like to know if there is a setting I should try to play with first.

Any help would be greatly appreciated,
Noble regards,
Ika

ps.: I will need to buy a new router for somebody next week and I was wondering if you had time to support the N18u (since you mentioned once that it's on your lists). I see that you still didn't had time to do it, but don't get me wrong please, I'm not complaining at all, just curious if it's still on your list somewhere or you actually tried and dropped the idea. I guess it would need a lot of work, so I understand if you won't do it.

Sorry, this is another case of nothing changed that should affect minidlna. About the only thing I can think of, is that since it caused a reboot, the default is to initiate a rebuild of the dlna db (You can turn this off on the dlna setup page as an option on the fork). If you have a large amount of files, it can take a while and possibly affect playback. Or if there is a corrupted file, it could cause problems. I just checked playing a movie from my USB drive thru the Roku Media Player, and it worked fine.

As far as the N18, sorry, but I never got back to it, and don't think it's going to be something I end up doing.

 

[Nullity]

For the increments.....two reasons
- First, IMO 1% steps implies a level of precision that just isn't there
- Second, when I was investigating/testing how QOS worked, it was just a pain to scroll through that big list every time I wanted to change things around

For your second question, yes, it can add up to more than 100%. I'm definitely not an expert on the various queuing algorithms, but I think of it as targets starting from the highest priority to the lowest. It tries its best to manage things to meet all the targets, but if your line is totally saturated, it will end up essentially allocating the bandwidth based on the relative proportions of the targets. (Any expert here is welcome to jump in!)

Generally, QoS is an effective tool for connections that are ~80%+ utilized and above. Queueing delay quickly grows toward infinity after 80%, as shown in the attached image (cite). I mention this to clarify that the AsusWRT QoS values will have little impact until link saturation. QoS is a worst-case scenerio.

Like you said John, the percentages most likely define ratios. The available bandwidth will then be proportionally shared among the different, active queues until the algorithm hits the configured global QoS bitrate. A setup with only 2 queues, set to 10% & 20%, is practically the same as 2 queues set to, 1% & 2%.
https://en.m.wikipedia.org/wiki/Network_scheduler for those interested in the different algos.


Or solve bufferbloat the proper way and buy more bandwidth...

 

[kvic]

Interesting..I turned on QoS (I chose traditional) and re-ran dlsreport's buffer bloat test. The buffer bloat seen in upload is gone. Found a good reason to keep QoS...how is the traditional QoS implemented in asuswrt?

As a side note, the slow climb to near line speed still there during upload (which is not seen in download). I think this could be something where a firmware could improve..

 

[hggomes]

Hi John, you are missing a small part of code on HTTP port:

Changing HTTPS port will redirect you to the correct NEW HTTPS port, changing HTTP port will not redirect you to the NEW HTTP port, but to the OLD one.

 

[john9527]

Hi John, you are missing a small part of code on HTTP port:

Changing HTTPS port will redirect you to the correct NEW HTTPS port, changing HTTP port will not redirect you to the NEW HTTP port, but to the OLD one.

Can you give me an example of what you mean? I'm currently running on port 8080, and everything seems to be working fine.

 

[hggomes]

Yes it works fine, but not the HTTP redirection after changing the port, for best understanding to this:

1. Login on your HTTPS port and change the port (example port 8044), you will see after APPLY the browser will try to connect the new 8044 port and ask for username and password, this is the correct procedure.
2. Login now on your HTTP port and change the port (example port 81), you will see after this it will try to connect the current port not the new one, you will have to change it manually to 81.

Unfortunalelly i cant test your FW because i dont have a compatible model by now, but looking at the code it will not work.

 

[slobodan]

He means: you can change the HTTPS port of the router webGUI, but you can't change its HTTP port.

 

[hggomes]

It should work, but does not redirect automatically to the new port.

 

[john9527]

I get the popup that the 'address or port number has changed' ...which it has. You close that window and then logon with with the new port info. I must be missing something, since it seems to be working as I would expect.

 

[hggomes]

Maybe the behaviour on old 374 code is different then, on 378 it doesnt popup any info after changing the port, it simply redirects you to the webui new port, you never have to login with the new port info, its done automatically.

 

[john9527]

I'd guess it is different since this still uses the http logon vs the token based logon in 378. Probably something else needs to be updated on the new code.