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

[namtih]

As this fork is using an older ASUS code base, does it already support bigger USB3.0 devices with 5TB space?

 

[john9527]

As this fork is using an older ASUS code base, does it already support bigger USB3.0 devices with 5TB space?

A couple of things....all leading to an answer of 'don't know, you'll have to try it or hope someone else can verify it'. I know people have used 3TB drives successfully.

Per ASUS, the maximum supported partition size for all router is 4TB for the ARM routers http://event.asus.com/2009/networks/disksupport/

Most of the problems with the larger drives are due to running out of memory on NTFS format drives. This fork uses the Paragon driver vs the Tuxera driver used on the later levels. Anecdotally, it seems to handle the larger drives better.

Some people have reported that formatting the drives with a larger cluster size can help.

 

[john9527]

@john9527

Small (hopefully) feature request:
Would you be able to add 'Google' to the options under "WAN - DDNS"?

thx

Believe it or not, this is tougher than you would think. But you can support Google DDNS with the Custom script option. See the wiki which has an example script for Google.
https://github.com/RMerl/asuswrt-merlin/wiki/Custom-DDNS

 

[namtih]

Thanks for your opinion John.
I think I will give it a try over the christmas holidays. But I will test the USB connection immediately after the firmware flash before doing the configuration part of the router.

 

[john9527]

A teaser for the next beta refresh coming soon ....thanks to @RMerlin for the 'howto' in his latest builds.

 

[RMerlin]

A teaser for the next beta refresh coming soon ....thanks to @RMerlin for the 'howto' in his latest builds.

View attachment 7932

I Ajaxified it a few days ago, make sure you pick up that commit too The changes are fairly trivial overall to make it auto-refresh.

 

[john9527]

I Ajaxified it a few days ago, make sure you pick up that commit too The changes are fairly trivial overall to make it auto-refresh.

One step at a time.....my todo list seems to be getting bigger instead of smaller .....so much to do, so little time.

 

[RMerlin]

One step at a time.....my todo list seems to be getting bigger instead of smaller .....so much to do, so little time.

I know the feeling only too well... The lack of new GPL from Asus these past months finally allowed me to get through the biggest items on that ToDO list (the charts and the update checking were on that list for a long time).

I'm still increasingly scared at what I might be facing once they drop those 6+ months of code changes on top of us...

 

[john9527]

BETA RELEASE: Update-22B4
6-December-2016
Merlin fork 374.43_2-22B4j9527
Download http://bit.ly/1UGjcOX
============================

Beta has been refreshed to V22B6
http://www.snbforums.com/threads/fo...leases-v20e9-v22b6.18914/page-241#post-295739

 

[thelonelycoder]

A tad off topic, but it may be of interest to @john9527 and users of this fork:
The complaints by some about wget or ping errors when installing pixelserv-tls (ps) through AB-Solution 3 are caused by a slow registering of the virtual interface with the following command structure in the addon script:

ifconfig br0:absolution 10.255.255.254 up

(this is only a testrun of the functionality and is destroyed when successful)

Adding a 2 second sleep command after creation of the interface produced no further errors when installing.
I must assume this is fork related, I never had this error in @RMerlin's or @hggomes firmware (latest and previous versions).
The release of the updated addon is planned for sometime this week.

 

[john9527]

Adding a 2 second sleep command after creation of the interface produced no further errors when installing.
I must assume this is fork related, I never had this error in @RMerlin's or @hggomes firmware (latest and previous versions).

No idea why that would be the case.....I think that function should be identical as part of the kernel.

 

[thelonelycoder]

No idea why that would be the case.....I think that function should be identical as part of the kernel.

OR the ping version has a shorter default timeout, have not tested that. Does not matter, the code is changed and it works now.
I commented it with:

# a pause, held in memory of slow processing merlin forks...

...

 

[john9527]

@thelonelycoder - what's the short sequence/check that's failing?

 

[thelonelycoder]

@thelonelycoder - what's the short sequence/check that's failing?

Here's the snippet of one of the tests, there are more when the actual interface is used.

    echo -e " checking your system\n"
    brup_ping(){
    echo -e " testing if 'ifconfig br0 up' works on your system"
    echo -e " (might take a few seconds to complete)"
    if ! ping -c 1 172.31.255.254 >/dev/null; then
        brup_test 172.31.255.254
    elif ! ping -c 1 10.255.255.254 >/dev/null; then
        brup_test 10.255.255.254
    elif ! ping -c 1 192.168.255.254 >/dev/null; then
        brup_test 192.168.255.254
    fi
    }
    brup_test(){
    ifconfig br0:absolution $1 up
    # a pause, held in memory of slow processing merlin forks...
    sleep 2
    if ping -c 2 $1 >/dev/null; then
        echo -e " this appears to be working, continuing\n"
        ifconfig br0:absolution $1 down
    else
        lastError=" Check your routers firmware version.\n It may not support the command:"
        lastErrorAdd=" ifconfig br0:<service name> <IP address> up"
        show_menu
    fi
    }
    brup_ping

In short:
1. Find an unused IP to test br0 up
2. Bring the unused IP up as virtual interface (ifconfig br0:absolution $1 up)
3. ping it, should be successful (ping -c 2 $1)
4. Down virtual interface

 

[jrmwvu04]

Pushed a refresh to the beta....anybody tried the new QoS implementation?

Just got done setting it up and playing around. Great stuff. I've been using Bandwidth Limiting for a while now, and I was quite eager to try out your new QoS. Pretty excellent results to this point with immediate impressions and inorganic benchmarks. Will drive it for a while and report back later.

 

[john9527]

Here's the snippet of one of the tests, there are more when the actual interface is used.

Don't know what to say......ran it 10X after commenting out the sleep and it was successful every time.

admin@AC68P-06650:/jffs/tmp# time ./test.sh
+ echo -e  checking your system\n
 checking your system

+ brup_ping
+ echo -e  testing if 'ifconfig br0 up' works on your system
 testing if 'ifconfig br0 up' works on your system
+ echo -e  (might take a few seconds to complete)
 (might take a few seconds to complete)
+ ping -c 1 172.31.255.254
+ brup_test 172.31.255.254
+ ifconfig br0:absolution 172.31.255.254 up
+ ping -c 2 172.31.255.254
+ echo -e  this appears to be working, continuing\n
 this appears to be working, continuing

+ ifconfig br0:absolution 172.31.255.254 down
+ exit
real    0m 11.04s
user    0m 0.01s
sys     0m 0.03s

All the real time is in the first test ping waiting to time out.

 

[thelonelycoder]

Don't know what to say......ran it 10X after commenting out the sleep and it was successful every time.

This was tested on a 66U, MIPS, don't know if that makes a difference.

 

[john9527]

This was tested on a 66U, MIPS, don't know if that makes a difference.

I couldn't resist a Newegg refurb sale, so now have an N66
just test there as well 10X successful (it's not connected to the wan though)

admin@RT-N66R-2628:/jffs/tmp# ./test.sh
+ echo -e  checking your system\n
 checking your system

+ brup_ping
+ echo -e  testing if 'ifconfig br0 up' works on your system
 testing if 'ifconfig br0 up' works on your system
+ echo -e  (might take a few seconds to complete)
 (might take a few seconds to complete)
+ ping -c 1 172.31.255.254
ping: sendto: Network is unreachable
+ brup_test 172.31.255.254
+ ifconfig br0:absolution 172.31.255.254 up
+ ping -c 2 172.31.255.254
+ echo -e  this appears to be working, continuing\n
 this appears to be working, continuing

+ ifconfig br0:absolution 172.31.255.254 down
+ exit

 

[RMerlin]

must assume this is fork related, I never had this error in @RMerlin's or @hggomes firmware (latest and previous versions).

Did you test all those firmware on the same architecture (MIPS or ARM)? I can't think of anything that could make a difference between our forks, aside from when comparing different architectures.

 

[RMerlin]

anybody tried the new QoS implementation?

Did you make use of IFB? I see the screenshots shows both ingress and egress stats.