[Beta] Asuswrt-Merlin 384.14 Beta is now available

RMerlin · Nov 30, 2019

We'll probably have to forget about the new RT-AX88U SDK in 384.14. Adaptive QoS does look broken with the new SDK. First reply from Asus was that it seemed to be fine on their end, so I sent them more test results. Hopefully they can eventually track it down.

I might publish a separate test build on Onedrive (with the fixed System page among other things) for those who don't care about Adaptive QoS but want the OFDMA/WPA3 support, but an official release will have to wait until a fix is available.

Frankflash · Nov 30, 2019

sloppy from Asus they are a bit like micosoft fix things and brake things along the way

Treadler · Nov 30, 2019

RMerlin said:
We'll probably have to forget about the new RT-AX88U SDK in 384.14. Adaptive QoS does look broken with the new SDK. First reply from Asus was that it seemed to be fine on their end, so I sent them more test results. Hopefully they can eventually track it down.

I might publish a separate test build on Onedrive (with the fixed System page among other things) for those who don't care about Adaptive QoS but want the OFDMA/WPA3 support, but an official release will have to wait until a fix is available.

Great news, really appreciated. (I for one, don’t use Qos).

RMerlin · Nov 30, 2019

Frankflash said:
sloppy from Asus they are a bit like micosoft fix things and brake things along the way

In this case, it's not something that's easy to catch. The bug was most likely introduced with the new Broadcom SDK, not in Asus's own code. Could be an incompatibility issue, or could be that Trend Micro might need to recompile their engine against the new SDK... Hard to tell.

The only reason why we picked it up is because my firmware exposes some low-level stats through the Classification page, making it more visible.

Swistheater · Nov 30, 2019

RMerlin said:
In this case, it's not something that's easy to catch. The bug was most likely introduced with the new Broadcom SDK, not in Asus's own code. Could be an incompatibility issue, or could be that Trend Micro might need to recompile their engine against the new SDK... Hard to tell.

The only reason why we picked it up is because my firmware exposes some low-level stats through the Classification page, making it more visible.

I have pin pointed a flaw in stubby as i was using the stubby dnssec with the stubby.yml.add, but with the new firmware update to beta2 for RT-AC5300, it breaks the IPV6, so i switched to just using dnsmasq dnssec and the IPV6 connection issue goes away, Has anything changed recently with directories related to stubby?

HeadBanger · Nov 30, 2019

Treadler said:
Great news, really appreciated. (I for one, don’t use Qos).

Same here.
Thanks Merlin

HB

FTC · Nov 30, 2019

RMerlin said:
I might publish a separate test build on Onedrive (with the fixed System page among other things) for those who don't care about Adaptive QoS but want the OFDMA/WPA3 support, but an official release will have to wait until a fix is available.

Thanks a lot Eric for all your efforts to keep this firmware as in sync as possible with the latest official code. Count on my feedback for that separate build also, since I am in that boat also (not using QoS).

Hawk · Nov 30, 2019

Eric, it would be great if you could post separate build as you mentioned. I have symmetrical gigabit and really don't need QOS.

I was just loud thinking since router security assessment is powered by Trend Micro and it is broken when wpa3 and wpa2 is used together. It may be possible that section is also affecting adaptive QOS, requiring Trend Micro to recompile for new SDK.

Adamm · Nov 30, 2019

I noticed some new... interesting IPTables entries.

Code:

Chain OUTPUT (policy ACCEPT 7180 packets, 6572K bytes)
 pkts bytes target     prot opt in     out     source               destination
 4169  326K OUTPUT_DNS  udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:53 u32 "0x0>>0x16&0x3c@0x8>>0xf&0x1=0x0"
   14  1611 OUTPUT_DNS  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:53 u32 "0x0>>0x16&0x3c@0xc>>0x1a&0x3c@0x8>>0xf&0x1=0x0"
43393   20M OUTPUT_IP  all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain OUTPUT_DNS (2 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 logdrop_dns  all  --  *      *       0.0.0.0/0            0.0.0.0/0            STRING match  "|10706f697579747975696f706b6a666e6603636f6d00|" ALGO name bm TO 65535 ICASE
    0     0 logdrop_dns  all  --  *      *       0.0.0.0/0            0.0.0.0/0            STRING match  "|0d72666a656a6e666a6e65666a6503636f6d00|" ALGO name bm TO 65535 ICASE
    0     0 logdrop_dns  all  --  *      *       0.0.0.0/0            0.0.0.0/0            STRING match  "|1131306166646d617361787373736171726b03636f6d00|" ALGO name bm TO 65535 ICASE
    0     0 logdrop_dns  all  --  *      *       0.0.0.0/0            0.0.0.0/0            STRING match  "|0f376d667364666173646d6b676d726b03636f6d00|" ALGO name bm TO 65535 ICASE
    0     0 logdrop_dns  all  --  *      *       0.0.0.0/0            0.0.0.0/0            STRING match  "|0d386d617361787373736171726b03636f6d00|" ALGO name bm TO 65535 ICASE
    0     0 logdrop_dns  all  --  *      *       0.0.0.0/0            0.0.0.0/0            STRING match  "|0f3966646d617361787373736171726b03636f6d00|" ALGO name bm TO 65535 ICASE
    0     0 logdrop_dns  all  --  *      *       0.0.0.0/0            0.0.0.0/0            STRING match  "|1265666274686d6f6975796b6d6b6a6b6a677403636f6d00|" ALGO name bm TO 65535 ICASE
    0     0 logdrop_dns  all  --  *      *       0.0.0.0/0            0.0.0.0/0            STRING match  "|086861636b7563647403636f6d00|" ALGO name bm TO 65535 ICASE
    0     0 logdrop_dns  all  --  *      *       0.0.0.0/0            0.0.0.0/0            STRING match  "|076c696e77756469056633333232036e657400|" ALGO name bm TO 65535 ICASE
    0     0 logdrop_dns  all  --  *      *       0.0.0.0/0            0.0.0.0/0            STRING match  "|0f6c6b6a68676664736174727975696f03636f6d00|" ALGO name bm TO 65535 ICASE
    0     0 logdrop_dns  all  --  *      *       0.0.0.0/0            0.0.0.0/0            STRING match  "|0b6d6e627663787a7a7a313203636f6d00|" ALGO name bm TO 65535 ICASE
    0     0 logdrop_dns  all  --  *      *       0.0.0.0/0            0.0.0.0/0            STRING match  "|077131313133333303746f7000|" ALGO name bm TO 65535 ICASE
    0     0 logdrop_dns  all  --  *      *       0.0.0.0/0            0.0.0.0/0            STRING match  "|057371353230056633333232036e657400|" ALGO name bm TO 65535 ICASE
    0     0 logdrop_dns  all  --  *      *       0.0.0.0/0            0.0.0.0/0            STRING match  "|077563746b6f6e6503636f6d00|" ALGO name bm TO 65535 ICASE
    0     0 logdrop_dns  all  --  *      *       0.0.0.0/0            0.0.0.0/0            STRING match  "|0e7a786376626d6e6e666a6a66777103636f6d00|" ALGO name bm TO 65535 ICASE
    0     0 logdrop_dns  all  --  *      *       0.0.0.0/0            0.0.0.0/0            STRING match  "|0a65756d6d6167766e627003636f6d00|" ALGO name bm TO 65535 ICASE


Chain OUTPUT_IP (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 logdrop_ip  all  --  *      *       0.0.0.0/0            193.201.224.0/24

Chain default_block (0 references)
 pkts bytes target     prot opt in     out     source               destination

Chain logdrop_dns (16 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            LOG flags 7 level 4 prefix "DROP_DNS "
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain logdrop_ip (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            LOG flags 7 level 4 prefix "DROP_IP "
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0

I wonder what Asus is planning (an improvement with built-in DNS/IP blocking?), also strange why only one random IP range from Ukraine is blocked by default linked to some "DDoSMan" malware.

https://otx.alienvault.com/indicator/ip/193.201.224.0

dave14305 · Nov 30, 2019

Swistheater said:
I have pin pointed a flaw in stubby as i was using the stubby dnssec with the stubby.yml.add, but with the new firmware update to beta2 for RT-AC5300, it breaks the IPV6, so i switched to just using dnsmasq dnssec and the IPV6 connection issue goes away, Has anything changed recently with directories related to stubby?

Using a .add file for DNSSEC might be unreliable since you aren’t able to validate ntp sync before turning on DNSSEC like the firmware does. Has your time been syncing reliably in the new beta?

dave14305 · Nov 30, 2019

Adamm said:

I noticed some new... interesting IPTables entries.

Code:

Chain OUTPUT (policy ACCEPT 7180 packets, 6572K bytes)
 pkts bytes target     prot opt in     out     source               destination
 4169  326K OUTPUT_DNS  udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:53 u32 "0x0>>0x16&0x3c@0x8>>0xf&0x1=0x0"
   14  1611 OUTPUT_DNS  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:53 u32 "0x0>>0x16&0x3c@0xc>>0x1a&0x3c@0x8>>0xf&0x1=0x0"
43393   20M OUTPUT_IP  all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain OUTPUT_DNS (2 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 logdrop_dns  all  --  *      *       0.0.0.0/0            0.0.0.0/0            STRING match  "|10706f697579747975696f706b6a666e6603636f6d00|" ALGO name bm TO 65535 ICASE
    0     0 logdrop_dns  all  --  *      *       0.0.0.0/0            0.0.0.0/0            STRING match  "|0d72666a656a6e666a6e65666a6503636f6d00|" ALGO name bm TO 65535 ICASE
    0     0 logdrop_dns  all  --  *      *       0.0.0.0/0            0.0.0.0/0            STRING match  "|1131306166646d617361787373736171726b03636f6d00|" ALGO name bm TO 65535 ICASE
    0     0 logdrop_dns  all  --  *      *       0.0.0.0/0            0.0.0.0/0            STRING match  "|0f376d667364666173646d6b676d726b03636f6d00|" ALGO name bm TO 65535 ICASE
    0     0 logdrop_dns  all  --  *      *       0.0.0.0/0            0.0.0.0/0            STRING match  "|0d386d617361787373736171726b03636f6d00|" ALGO name bm TO 65535 ICASE
    0     0 logdrop_dns  all  --  *      *       0.0.0.0/0            0.0.0.0/0            STRING match  "|0f3966646d617361787373736171726b03636f6d00|" ALGO name bm TO 65535 ICASE
    0     0 logdrop_dns  all  --  *      *       0.0.0.0/0            0.0.0.0/0            STRING match  "|1265666274686d6f6975796b6d6b6a6b6a677403636f6d00|" ALGO name bm TO 65535 ICASE
    0     0 logdrop_dns  all  --  *      *       0.0.0.0/0            0.0.0.0/0            STRING match  "|086861636b7563647403636f6d00|" ALGO name bm TO 65535 ICASE
    0     0 logdrop_dns  all  --  *      *       0.0.0.0/0            0.0.0.0/0            STRING match  "|076c696e77756469056633333232036e657400|" ALGO name bm TO 65535 ICASE
    0     0 logdrop_dns  all  --  *      *       0.0.0.0/0            0.0.0.0/0            STRING match  "|0f6c6b6a68676664736174727975696f03636f6d00|" ALGO name bm TO 65535 ICASE
    0     0 logdrop_dns  all  --  *      *       0.0.0.0/0            0.0.0.0/0            STRING match  "|0b6d6e627663787a7a7a313203636f6d00|" ALGO name bm TO 65535 ICASE
    0     0 logdrop_dns  all  --  *      *       0.0.0.0/0            0.0.0.0/0            STRING match  "|077131313133333303746f7000|" ALGO name bm TO 65535 ICASE
    0     0 logdrop_dns  all  --  *      *       0.0.0.0/0            0.0.0.0/0            STRING match  "|057371353230056633333232036e657400|" ALGO name bm TO 65535 ICASE
    0     0 logdrop_dns  all  --  *      *       0.0.0.0/0            0.0.0.0/0            STRING match  "|077563746b6f6e6503636f6d00|" ALGO name bm TO 65535 ICASE
    0     0 logdrop_dns  all  --  *      *       0.0.0.0/0            0.0.0.0/0            STRING match  "|0e7a786376626d6e6e666a6a66777103636f6d00|" ALGO name bm TO 65535 ICASE
    0     0 logdrop_dns  all  --  *      *       0.0.0.0/0            0.0.0.0/0            STRING match  "|0a65756d6d6167766e627003636f6d00|" ALGO name bm TO 65535 ICASE


Chain OUTPUT_IP (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 logdrop_ip  all  --  *      *       0.0.0.0/0            193.201.224.0/24

Chain default_block (0 references)
 pkts bytes target     prot opt in     out     source               destination

Chain logdrop_dns (16 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            LOG flags 7 level 4 prefix "DROP_DNS "
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain logdrop_ip (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            LOG flags 7 level 4 prefix "DROP_IP "
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0

I wonder what Asus is planning (an improvement with built-in DNS/IP blocking?), also strange why only one random IP range from Ukraine is blocked by default linked to some "DDoSMan" malware.

https://otx.alienvault.com/indicator/ip/193.201.224.0

Merlin’s statement on the topic:
Iptables, routes and ip a

bluzfanmr1 · Nov 30, 2019

IAAI said:
Is there is a way to test that other than 1.1.1.1/help

https://www.snbforums.com/threads/r...-384-11-is-available.56501/page-6#post-488904

RMerlin · Nov 30, 2019

Swistheater said:
Has anything changed recently with directories related to stubby?

Nothing should have changed related to stubby.

Swistheater · Nov 30, 2019

dave14305 said:
Using a .add file for DNSSEC might be unreliable since you aren’t able to validate ntp sync before turning on DNSSEC like the firmware does. Has your time been syncing reliably in the new beta?

yes the time has been syncing reliably.
I might go ahead and append it with an if statement inside stubby.postconf that checks for time sync then to test your theory.

kernol · Nov 30, 2019

RMerlin said:
Asus confirmed that Adaptive QoS was working correctly, so I'll have to check to see if something failed to be properly merged on my end.

FreshJR adaptive QOS working perfectly on my RT--AC86U with 384.14_beta2

skeal · Nov 30, 2019

kernol said:
FreshJR adaptive QOS working perfectly on my RT--AC86U with 384.14_beta2

View attachment 20061

As it should. The build you have doesn't have the adaptive QOS issue. The two Test versions of the Beta2 are the ones that have the problem. So far Test builds are only available for the AX88U and the AC5300. Eric has said that further development of 384.14 isn't likely to include the QOS changes. He will have to deal with them in future builds IE: 384.15.

Swistheater · Nov 30, 2019

dave14305 said:
Using a .add file for DNSSEC might be unreliable since you aren’t able to validate ntp sync before turning on DNSSEC like the firmware does. Has your time been syncing reliably in the new beta?

So after testing with a stubby.postconf that checks on NTP sync, still the same issue is back, No ipv6 connectivity.

*EDIT*

new find has led me to determine that it is actually the use of

Code:

tls_min_version: GETDNS_TLS1_2
tls_cipher_list: "EECDH+AESGCM:EECDH+CHACHA20"
tls_max_version: GETDNS_TLS1_3
tls_ciphersuites: "TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256"

style settings
I had mine set to
tls_min_version: GETDNS_TLS1_3
also tested with other settings as well
specifying both tls_1_2 as min and
tls_1_3 as max
All possible combinations cause IPV6 connectivity to fail. You will still get your DHCP handouts for IPV6 but no internet connectivity.

TheOldMan · Nov 30, 2019

Day 6 on self-compiled 384.14_b2. Working well like it should.

WuTang LAN · Nov 30, 2019

TheOldMan said:
Day 6 on self-compiled 384.14_b2. Working well like it should.

As is tradition.

dave14305 · Nov 30, 2019

Swistheater said:
So after testing with a stubby.postconf that checks on NTP sync, still the same issue is back, No ipv6 connectivity.

*EDIT*

new find has led me to determine that it is actually the use of

Code:

tls_min_version: GETDNS_TLS1_2 tls_cipher_list: "EECDH+AESGCM:EECDH+CHACHA20" tls_max_version: GETDNS_TLS1_3 tls_ciphersuites: "TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256"

style settings
I had mine set to
tls_min_version: GETDNS_TLS1_3
also tested with other settings as well
specifying both tls_1_2 as min and
tls_1_3 as max
All possible combinations cause IPV6 connectivity to fail. You will still get your DHCP handouts for IPV6 but no internet connectivity.

Cloudflare in particular has given many people issues lately if they had min TLS set for 1.3. This included John’s fork users and straggling users of the original Stubby installer script.

Thread starter	Title	Forum	Replies	Date
	Beta Asuswrt-Merlin 386.13 beta is now available for AC models	Asuswrt-Merlin	32	Mar 28, 2024
	Beta Asuswrt-Merlin 3004.388.6 Beta is now available	Asuswrt-Merlin	279	Jan 5, 2024
	Beta Asuswrt-Merlin 3004.388.5-beta is now available	Asuswrt-Merlin	58	Nov 26, 2023
	Beta Asuswrt-Merlin 386.12 Beta is now available for AC models	Asuswrt-Merlin	21	Aug 28, 2023
	Beta Asuswrt-Merlin 3004.388.4 beta is now available	Asuswrt-Merlin	598	Jul 26, 2023
S	Anyone else having issues trying to flash the newest merlin (stable or beta) to the GT-0AXE11000?	Asuswrt-Merlin	4	Dec 1, 2023
K	Asus-Merlin beta release for 9.0.0.x.y.z official beta releases? (like for GT-AXE16000)	Asuswrt-Merlin	4	May 23, 2023
H	Solved xbox one not able to sign in when connected through router running asuswrt-merlin on an rt-ac5300.	Asuswrt-Merlin	5	Apr 12, 2024
	Release Asuswrt-Merlin 386.13 is now available for AC models	Asuswrt-Merlin	38	Apr 7, 2024
	asuswrt-merlin.net Website Site Down?	Asuswrt-Merlin	18	Mar 27, 2024

[Beta] Asuswrt-Merlin 384.14 Beta is now available

Asuswrt-Merlin dev

Senior Member

Very Senior Member

Asuswrt-Merlin dev

Very Senior Member

Regular Contributor

Senior Member

Very Senior Member

Part of the Furniture

Part of the Furniture

Part of the Furniture

Senior Member

Asuswrt-Merlin dev

Very Senior Member

Very Senior Member

Part of the Furniture

Very Senior Member

Senior Member

Regular Contributor

Part of the Furniture

Similar threads

Similar threads

Sign Up For SNBForums Daily Digest