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

[fatspirit]

@fatspirit look here.

https://onedrive.live.com/?authkey=!AKXdaMzjqVKbGsc&id=9332FC159A7E129!1117&cid=09332FC159A7E129

The troll above was talking about original Merlin's builds. I guess

 

[joe a]

The troll above was talking about original Merlin's builds. I guess

The below link (same as from L&LD) is for new Meriln LTS builds. Is that what you're looking for?
https://onedrive.live.com/?authkey=!AKXdaMzjqVKbGsc&id=9332FC159A7E129!1117&cid=09332FC159A7E129

 

[fatspirit]

The below link (same as from L&LD) is for new Meriln LTS builds. Is that what you're looking for?
https://onedrive.live.com/?authkey=!AKXdaMzjqVKbGsc&id=9332FC159A7E129!1117&cid=09332FC159A7E129

It's John's fork, not an original Merlin's builds, since support for RT-AC66U by Merlin has been dropped.

 

[Swingtop]

You know you are going to get slammed because you know that information is false.

@Meshhh as it's been mentioned above, John is providing new builds on his development folder, however he is not publishing them here or on his github.

Prove that it is John doing this. I stopped updating because I am no longer certain where these builds come from.

 

[alfie]

Prove that it is John doing this. I stopped updating because I am no longer certain where these builds come from.

https://github.com/john9527/asuswrt-merlin look for the update

 

[jrmwvu04]

Prove that it is John doing this. I stopped updating because I am no longer certain where these builds come from.

The code is on his github and the downloads are on his onedrive, the way it has always been. The only difference is that he avoids the stress of posting here and fielding complaints. The change logs make it pretty clear that he still reads here though.

 

[RMerlin]

You could also review the commits, and build your own firmware image if you didn't trust the Onedrive downloads.

 

[ASecondChance]

@fatspirit look here.

https://onedrive.live.com/?authkey=!AKXdaMzjqVKbGsc&id=9332FC159A7E129!1117&cid=09332FC159A7E129

can i upgrade from firmware 39E3 to that one?

 

[L&LD]

can i upgrade from firmware 39E3 to that one?

Yes, I updated an RT-AC66U with no issues.

 

[underdose]

Prove that it is John doing this. I stopped updating because I am no longer certain where these builds come from.

Here's your proof from John himself: https://www.snbforums.com/threads/f...lts-releases-v39e3.18914/page-465#post-482576

 

[Deleted member 27741]

Hey dudes- I am having issues with an ip address range with the bandwidth limiter on John's firmware. Single ip address or MAC works fine.

So, a rule like this:
192.168.48.2-192.168.48.254

does not work at all.
Any suggestions? Am I putting in the ip address range wrong?

 

[ColinTaylor]

So, a rule like this:
192.168.48.2-192.168.48.254

It doesn't look like that's a valid format:

EDIT: Tested. The format is acceptable.

 

[Deleted member 27741]

Looks like it's all or nothing then?
I say this because I would like to limit bandwidth of all but one ip address, but 192.168.48.* won't let me do that.
My rules would look like-
192.168.48.254 - allow high bandwidth
192.168.48.2-253 - allow little bandwidth
Is there a way to do that?
Update- the * is not working anyhow, so one bandwidth rule that severely limits everything
192.168.48.* - allow only 1 kb/s
does nothing.
I was hoping I could get away with a rule list like this (assuming it might work like iptables)-
(mac address) - allow high bandwidth
192.168.48.* - allow little bandwidth
but tried (for testing) just the 192.168.48.* rule alone and it did nothing at all.

 

[ColinTaylor]

@000111 Well I've just tested this myself and a) it accepted the format you're using, and b) the limiting is working as desired.

Is your main LAN 192.168.48.x ?

EDIT: Perhaps the MIPS version of iptables doesn't support the necessary syntax. Can you post the output of the following command when using your original rules:

iptables-save -t mangle

 

[Deleted member 27741]

No, the LAN is 10.148.42.x, I usually put 192.168.48.x in for posterity.
rules-
(mac address of 10.148.42.254) - allow 8000 kb/s down 2000 kb/s up
10.148.42.2-10.148.42.253 - allow 1 kb/s down and 1 kb/s up
More useless info- DHCP pool is set for 10.148.42.2-10.148.42.239 (to separate vpn addresses from DHCP), but I don't think that should matter.


Also potentially of note I'm using version 41E9. I did think this used to work on prior versions, but my testing could have been off.

 

[ColinTaylor]

@000111 Disable any VPNs while testing.

 

[Deleted member 27741]

No vpns are or were connected for testing, although they were running.
Retested with vpn servers all disabled- seems to work.
Of special note here is that I DO USE the pptp and openvpn vpn servers.
Weird.
I guess I can get it to work by disabling all vpn servers (not just having them unconnected). If there is a better way you can think of I would be most appreciative of your continued assistance.
Maybe this is the root of my QOS issues all along, vpns being enabled? eek.

 

[Dent]

Is there a site where I can download the "L" version of the development builds such as a 41L9 version instead of the 41E9 version? I use the "L" builds on my N66U due to the greater transmit power that is available with the legacy wireless drivers.

 

[silicon101]

Finally found time to glue gun the failed power button and really appreciate this firmware. As I admit to being new to this, I noticed the last Asus firmware was 382.51641 (11/2019) and latest Merlin is 384.x and John's fork is 374.x. Not that a build number is important but just curious, is it staying at 374 as that was the last Merlin release? Are updates from last official Asus build and/or Merlin builds included in this fork? My questions are NOT complaining just a new guy interested in learning. John if you are still reading this forum thank you for all your time.

 

[ColinTaylor]

@silicon101 See post #1.