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

[RMerlin]

I didn't pick up any dnsmasq update in V24 because of that issue (it's still the same 2.76 as it's been since V18). For the V25 beta, it picks up 2.77test3, which is the release before it picked up that RFC, but did fix the truncated UDP response. I also read the tomato posts....

No problem. When I saw you had picked a git snapshot, I wasn't sure if it was the latest or not.

 

[sfx2000]

NEW: haveged: add support version 1.9.1
This ensures a sufficient entropy (supply of random numbers) is available for crypto operations

For haveged - you can perhaps put some blame on me if things there break...

This was an outcome of another discussion/thread regarding entropy in general - folks tested across different platforms, and things looked good...

Should be safe though...

 

[john9527]

No problem. When I saw you had picked a git snapshot, I wasn't sure if it was the latest or not.

No problem here either....appreciate the pointer just in case...

 

[dopefish]

T

@dopefish You're right. It looks like that checkbox doesn't appear on the N66U for EU routers (which possibly explains why I didn't remember it). I think that's because it wasn't part of the original code base and is only enabled by manually setting that NVRAM variable.

    if(country == "EU"){ //display checkbox of DFS channel under 5GHz
        if(based_modelid == "RT-AC68U" || based_modelid == "RT-AC68U_V2" || based_modelid == "DSL-AC68U" || based_modelid == "RT-AC69U"
        || based_modelid == "RT-AC87U"){
            if(document.form.wl_channel.value  == '0' && '<% nvram_get("wl_unit"); %>' == '1')
                $('dfs_checkbox').style.display = "";
        }
    }

It was added into the later firmwares which is why it appears in Merlin's.

    else if(country == "EU"){        //display checkbox of DFS channel under 5GHz
        if(based_modelid == "RT-AC68U" || based_modelid == "RT-AC68A" || based_modelid == "4G-AC68U" || based_modelid == "DSL-AC68U"
        || based_modelid == "RT-AC87U"
        || based_modelid == "RT-AC3200"
        || (based_modelid == "RT-AC66U" && wl1_dfs == "1")        //0: A2 not support, 1: B0 support
        || based_modelid == "RT-N66U"){
                if(document.form.wl_channel.value  == '0' && wl_unit == '1'){
                        document.getElementById('dfs_checkbox').style.display = "";
                        check_DFS_support(document.form.acs_dfs_checkbox);
                }
        }

Personally I wouldn't use the Auto setting anyway. Just set it to something like channel 100 and see how it works out.

Wow, nice find. Thank you very much!

And thank you John, i will try Update-25B7 this weekend.

 

[ml70]

This used to work in Merlin releases? No idea what's going on here.
Dear lord save me from needing to write tc rules.

min@AC66:/jffs/scripts $ iptables -t mangle -A QOSO -p udp -m length
iptables v1.3.8: length: You must specify `--length'

admin@AC66:/jffs/scripts $ iptables -t mangle -A QOSO -p udp -m length --length
iptables v1.3.8: Unknown arg `--length'

admin@AC66:/jffs/scripts $ iptables -t mangle -A QOSO -p udp -m length --length 1:64
iptables: No chain/target/match by that name

admin@AC66:/jffs/scripts $ iptables -t mangle -A QOSO -p udp -m length --length 1:64 -j CONNMARK --set-return 0x101/0x1ff
iptables: No chain/target/match by that name

 

[ColinTaylor]

admin@AC66:/jffs/scripts $ iptables -t mangle -A QOSO -p udp -m length --length 1:64
iptables: No chain/target/match by that name

Works for me. Are you sure your QOSO chain exists?

admin@RT-AC68U:/# iptables -t mangle -A QOSO -p udp -m length --length 1:64

 

[slobodan]

I didn't pick up any dnsmasq update in V24 because of that issue (it's still the same 2.76 as it's been since V18). For the V25 beta, it picks up 2.77test3, which is the release before it picked up that RFC, but did fix the truncated UDP response. I also read the tomato posts....

Actually V25B7 works perfectly on my RT-N16, but it leads to dnsmasq crashing often on RT-AC56U, which does not happen in V24E3. AC56U has CTF + FA enabled. I have ab-solution installed.

 

[Gravityz]

Hi Colin,

I have read somewhere that that is the way Asus implemented the EU setting in the first placve to get rid of all those country settings.
Are you telling me now you can select EU and then a specific country in the EU( in your case 13 DE)
If that is the case they might have changed the setting but i tested it a couple of years ago and setting it to EU gave me very bad range(worse then my old router which also was supposed to give out 100mW.

Anyway 100mW with the stock firmware also gives bad range as compared to 100mW fork firmware

How are you determining the power level? I have an EU router which has a region setting of EU/13 (DE) which gives 100mW.

 

[ColinTaylor]

I have read somewhere that that is the way Asus implemented the EU setting in the first placve to get rid of all those country settings.
Are you telling me now you can select EU and then a specific country in the EU( in your case 13 DE)

I was just curious as to where the 50mW figure came from because I've never seen anybody mention it before and as far as I can see it doesn't appear in the source code.

My router was bought in the UK but the regional setting in the CFE says EU/13 which is Germany. That makes sense because the power and channel allocations are the same for most EU countries on 2.4GHz. The web interface also says "The maximum value is 100mW and the real transmission power will be dynamically adjusted to meet regional regulations. (EU/13)". This seems to also be confirmed by the wireless driver.

admin@RT-AC68U:/# wl -i eth1 country
DE (EU/13) GERMANY
admin@RT-AC68U:/# wl -i eth1 txpwr_target_max
Maximum Tx Power Target (chanspec:0x1803):      15.50  15.50  15.50

15.5dBm = 35.48mW x 3 (for 3 antennas) = 106.44mW

EDIT: I think I've found your reference to 50mW. If was an earlier limit on the 5GHz non-DFS channels for US routers. https://www.smallnetbuilder.com/wir...s/32431-is-your-routers-transmit-power-juiced

 

[ml70]

Works for me. Are you sure your QOSO chain exists?

It's right there. Something very weird now. Unfortunately can't reboot this thing right now, but there's nothing else that seems to be wrong. Only that -m length --length doesn't play ball. Same result with -A PREROUTING. -I doesn't work either. Use something else than length and everything works as normal.

Using
-m tcp --tcp-flags
-m iprange --src-range/--dst-range
-m multiport --dports/--sports
-m state --state
-m icmp --icmp-type
without any issues. Only importing length rules shows this weirdness. The same command line immediately works when trying out some other -m rule.

admin@AC66:/jffs/scripts $ iptables -nvL QOSO -t mangle
Chain QOSO (2 references)
 pkts bytes target     prot opt in     out     source               destination
 192M  137G CONNMARK   all  --  *      *       0.0.0.0/0            0.0.0.0/0           ctstate RELATED,ESTABLISHED CONNMARK restore mask 0x1ff

Also some weirdness with -m hashlimit, it's there and almost works, but

admin@AC66:/jffs/scripts $ iptables -t filter -A FORWARD -p icmp -m hashlimit --hashlimit 1/sec --hashlimit-mode srcip --hashlimit-name icmp
iptables: No chain/target/match by that name

So this is an AC66U with 23E4j9527.

 

[ColinTaylor]

This used to work in Merlin releases?

Has this ever worked on John's fork or were you previously using Merlin's?

 

[rcinterstate76]

In order to do the full support for DNSCrypt, I had to backport a kernel patch that would allow this (this is only supported on the ARM routers).

Hi, I got a RT-N66U model and I'm interested testing DNSCrypt feature on your firmware but it seems it only supports ARM models, is there any special reason? Can't the same kernel patch be also applied to MIPS models?


Thank you in advance.

 

[slobodan]

Hi, I got a RT-N66U model and I'm interested testing DNSCrypt feature on your firmware but it seems it only supports ARM models, is there any special reason? Can't the same kernel patch be also applied to MIPS models?


Thank you in advance.

dnscrypt exists in both ARM and MIPS builds. Even the RT-N16 has it, so RT-N66U has it, too.

 

[john9527]

Hi, I got a RT-N66U model and I'm interested testing DNSCrypt feature on your firmware but it seems it only supports ARM models, is there any special reason? Can't the same kernel patch be also applied to MIPS models?


Thank you in advance.

DNSCrypt is supported on both the MIPS and ARM routers.
The kernel patch that is extra on the ARM routers allows some additional options when you are running an OpenVPN client. For example, being able to use the VPN DNS servers for the VPN clients, and the DNSCrypt servers for the non-VPN clients. On the MIPS routers, you can't do this.

 

[john9527]

It's right there. Something very weird now. Unfortunately can't reboot this thing right now, but there's nothing else that seems to be wrong. Only that -m length --length doesn't play ball. Same result with -A PREROUTING. -I doesn't work either. Use something else than length and everything works as normal.

There are different versions of ipset and iptables between the MIPS and ARM based routers. It's possible 'length' isn't supported on the MIPS routers. I'll won't be able to double check until next week.
EDIT: Merlin's lastest and this fork use the same ipset/iptables as far as I know....but I'll also check if ASUS slipped in any updates.

 

[octopus]

@john9527
Just tested and not working (25B7), used "Ability to enable DFS channels for N66U EU routers" "nvram set wl_dfs_enable=1"
If it suppose to show a DFS checkbox, there isn't any.
Octopus

Any thought about this?

 

[john9527]

@john9527
Just tested and not working (25B7), used "Ability to enable DFS channels for N66U EU routers" "nvram set wl_dfs_enable=1"
If it suppose to show a DFS checkbox, there isn't any.
Octopus

It should be there.....for EU routers, with the main channel selection set to 'Auto'. It will be next week before I can double check it on the hardware.

 

[ml70]

Has this ever worked on John's fork or were you previously using Merlin's?

I've gone double full circle Merlin->John->Merlin->John but I believe the length rules are only from the days of Merlin. Wouldn't expect iptables to differ.

I'll won't be able to double check until next week.
EDIT: Merlin's lastest and this fork use the same ipset/iptables as far as I know....but I'll also check if ASUS slipped in any updates.

I'll be very grateful if you can check on -m length and -m hashlimit, would need them both. Well length can be done with tc filters but it's a rather morbid choice, i reckon it'll be a full day misspent.

 

[john9527]

I'll be very grateful if you can check on -m length and -m hashlimit, would need them both. Well length can be done with tc filters but it's a rather morbid choice, i reckon it'll be a full day misspent.

I looked at the build config, and both should be there, but they aren't automatically loaded. If you insmod xt_length and xt_hashlimit it should work.

 

[octopus]

It should be there.....for EU routers, with the main channel selection set to 'Auto'. It will be next week before I can double check it on the hardware.

@john9527
That would be fine. I get the checkbox when I use AUTO and when clicked DFS checkbox and apply I don't se and dfs channels.