[Release] Asuswrt-Merlin 384.11 is available

[Mutzli]

I flashed this morning from 384.10_2.

I can't get the tcpdump command to display any output:

tcpdump -i eth0 -p port 853 -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes

No packets displayed.

The Network Tools -> Netstat: TCP Packets option works:

tcp        0      0 88.123.234.255:53696   1.0.0.1:853             TIME_WAIT   -
tcp        0      0 88.123.234.255:45304   1.1.1.1:853             ESTABLISHED 19284/stubby

Here is another validation:

netstat -lnpt | grep -E '^Active|^Proto|/stubby'

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.1.1:53            0.0.0.0:*               LISTEN      19284/stubby

Try: tcpdump -ni eth0 -p port 53 or port 853

 

[vibroverbus]

So 384.11 upgraded smooth as silk but seems like DoT misses AC3200's eh? I presume this is linked to us being stuck on the old blobs?

NEVER MIND.

Upgrade didn't go smooth as silk. Apparently upload never finished and so I hadn't completed the update. Its all there. #doh.

 

[Delusion]

Same problem on rt AC86U..........

Solved giving time for the implementation of the new firmware between........restorations..... restarts and implementations of qos...........5 minutes approximately in my case

Now all works fine

What do you mean... I didn't understand I don't use QoS .

 

[Asad Ali]

FYI - Wow! Absolutely amazing response - see this HND model v384.11.1 commit

Yeah just saw it!!
Thank you so much @RMerlin

 

[Pit_g]

What do you mean... I didn't understand I don't use QoS .

The router needs time to implement changes correctly.........

Update firmware and wait 5 minutes before restarting or restoring.......


P.D: Sorry for my English.....

 

[Chrisgtl]

For my UK environment, I use Ch42 80MHz, and moved SKY Q to Ch46 40MHz since the SKY Q minis are hard wired, and I haven't heard any complaints with 5G devices failing to connect from visiting friends/colleagues/family/hackers![/QUOTE]

Ch42? Is there such a thing?

 

[Butterfly Bones]

I get this message on the log every 20 minutes or so. I know it has something to do with AiProtection but saw no solution to this issue which was claimed to be solved in some FW update :
I think turning off AiProtection solves this issue but I don't want it disabled , I also run Skynet and Diversion ,,, After dcd crash, does it restart automatically ? Is it something to worry about?

kernel: dcd[28920]: unhandled level 3 translation fault (11) at 0x00000000, esr 0x92000007
May 11 15:43:19 kernel: pgd = ffffffc012a63000
May 11 15:43:19 kernel: [00000000] *pgd=0000000012a7e003, *pud=0000000012a7e003, *pmd=0000000003574003, *pte=0000000000000000
May 11 15:43:19 kernel: CPU: 1 PID: 28920 Comm: dcd Tainted: P           O    4.1.27 #2
May 11 15:43:19 kernel: Hardware name: Broadcom-v8A (DT)
May 11 15:43:19 kernel: task: ffffffc0191ce080 ti: ffffffc0063a0000 task.ti: ffffffc0063a0000
May 11 15:43:19 kernel: PC is at 0xf74ebf44
May 11 15:43:19 kernel: LR is at 0x1dc74
May 11 15:43:19 kernel: pc : [<00000000f74ebf44>] lr : [<000000000001dc74>] pstate: 600e0010
May 11 15:43:19 kernel: sp : 00000000fffd7ab8
May 11 15:43:19 kernel: x12: 000000000009ff08
May 11 15:43:19 kernel: x11: 00000000f67ff024 x10: 00000000000a02ac
May 11 15:43:19 kernel: x9 : 00000000f67ff798 x8 : 00000000000a0764
May 11 15:43:19 kernel: x7 : 00000000f67ff7d0 x6 : 00000000000a075e
May 11 15:43:19 kernel: x5 : 0000000000000000 x4 : 00000000f67ff77c
May 11 15:43:19 kernel: x3 : 0000000000000000 x2 : 00000000fffd7a94
May 11 15:43:19 kernel: x1 : 000000000007c66c x0 : 0000000000000000

Know issue posted in post #1 of this thread:
https://www.snbforums.com/threads/release-asuswrt-merlin-384-9-is-now-available.54843/

There is a number of known issues in this release that cannot be fixed at this time:

• dcd process crashing on RT-AC86U (bug in Trend Micro's code, outside of my control).
• Users failing to read changelogs will probably complain about the above issues. (Outside of my control).

Workaround:
https://www.snbforums.com/threads/script-to-remove-dcd-crashes-from-system-log.54734/

 

[Martineau]

For my UK environment, I use Ch42 80MHz, and moved SKY Q to Ch46 40MHz since the SKY Q minis are hard wired, and I haven't heard any complaints with 5G devices failing to connect from visiting friends/colleagues/family/hackers!

Ch42? Is there such a thing?

Probably a bit too small to read but yes, Ch42 80MHz is shown three times!

i.e.
RT-AC68U - Achievable rate = 1300 Mbps
RT-AC86U - Achievable rate = 1733 Mbps


This should explain it UK 5GHz WLAN Spectrum (Aug 2017)

 

[Martineau]

I can't get the tcpdump command to display any output:

tcpdump -i eth0 -p port 853 -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes

No packets displayed.

FYI, tcpdump can advise you of all of the interfaces available

tcpdump -D

So from the tcpdump interface name list.....try

tcpdump -tttt -n -i any port 53 or 853

Whilst the above is particularly useful if you are unsure of your WAN interface name, hopefully the router can detect the correct interface

tcpdump -tttt -n -i $(nvram get wan0_gw_ifname) port 53 or 853

 

[scjr]

Approaching 3 days uptime. Everything running great. All WiFi clients connected. DoT Cloudflare running well. Thanks, RMerlin!

 

[Chrisgtl]

View attachment 17575

Probably a bit too small to read but yes, Ch42 80MHz is shown three times!

i.e.
RT-AC68U - Achievable rate = 1300 Mbps
RT-AC86U - Achievable rate = 1733 Mbps


This should explain it UK 5GHz WLAN Spectrum (Aug 2017)

I can't select channel 42 on my 86U. I have 40 and 44 but no 42.

 

[Delusion]

Know issue posted in post #1 of this thread:
https://www.snbforums.com/threads/release-asuswrt-merlin-384-9-is-now-available.54843/

Workaround:
https://www.snbforums.com/threads/script-to-remove-dcd-crashes-from-system-log.54734/

This workaround only removes the messages in the log and nothing else right? if so, what is the benefit hiding\removing the messages ?

After the dcd crash, does it come back or stays crashed ? if it crashes does AiProtection still runs or does it fails too or restarts till the next dcd?

Thanks.

 

[Swistheater]

I can't select channel 42 on my 86U. I have 40 and 44 but no 42.

Could have been shut off in all the recent firmware adjustments by asus.

 

[Xentrk]

FYI, tcpdump can advise you of all of the interfaces available

tcpdump -D

So from the tcpdump interface name list.....try

tcpdump -tttt -n -i any port 53 or 853

Whilst the above is particularly useful if you are unsure of your WAN interface name, hopefully the router can detect the correct interface

tcpdump -tttt -n -i $(nvram get wan0_gw_ifname) port 53 or 853

Thanks @Martineau!

tcpdump -tttt -n -i $(nvram get wan0_gw_ifname) port 853

works. Very verbose.

Good addition for the Wiki.

 

[Martineau]

Thanks @Martineau

tcpdump -tttt -n -i $(nvram get wan0_gw_ifname) port 853

works.

So just out of curiosity what is your actual WAN interface name?

 

[Butterfly Bones]

This workaround only removes the messages in the log and nothing else right? if so, what is the benefit hiding\removing the messages ?

After the dcd crash, does it come back or stays crashed ? if it crashes does AiProtection still runs or does it fails too or restarts till the next dcd?

Thanks.

Yes, it is just a cosmetic fix. It will crash over and over and over. I think AIProtection still works. I'm a single old guy who uses the 'Net carefully with noone else on my network. I see no hits on AIProtection, though it is enabled.

As Rmerlin has stated many, many times, this is a TrendMicro issue that is closed source and only TrendMicro can fix it. RMerlin can not fix it. Now one knows the answers to your questions except TrendMicro and their closed source programmers who write the code.

Sorry, I know not much help. Many of us have it and remove it from the syslog to minimize the annoyance. I have seen no reports of issues using that workaround or removing them with syslog-ng via scribe, which is how many of us handle that dcd tainted crash.

 

[Xentrk]

I enabled DNSSEC via stubby.postconf:

#!/bin/sh
CONFIG=$1
source /usr/sbin/helper.sh
pc_insert "  - GETDNS_TRANSPORT_TLS" "dnssec_return_status: GETDNS_EXTENSION_TRUE" $CONFIG

followed by a reboot.

Validate DNSSEC:

stubby -l
[14:57:06.647624] STUBBY: Read config from file /etc/stubby/stubby.yml
[14:57:06.648410] STUBBY: DNSSEC Validation is ON
[14:57:06.648601] STUBBY: Transport list is:
[14:57:06.648871] STUBBY:   - TLS
[14:57:06.649121] STUBBY: Privacy Usage Profile is Strict (Authentication required)
[14:57:06.649244] STUBBY: (NOTE a Strict Profile only applies when TLS is the ONLY transport!!)
[14:57:06.649355] STUBBY: Starting DAEMON....
[14:57:14.201165] STUBBY: 9.9.9.9                                  : Conn opened: TLS - Strict Profile
[14:57:14.254501] STUBBY: 9.9.9.9                                  : Verify passed : TLS
<snip>

But the drill -D command did not return the "ad" flag:

drill -D x3mtek.com
;; ->>HEADER<<- opcode: QUERY, rcode: SERVFAIL, id: 8578
;; flags: qr rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; x3mtek.com.  IN      A

Reran drill adding the -T flag:

drill -DT x3mtek.com
;; Number of trusted keys: 2
;; Domain: .
[T] . 172800 IN DNSKEY 256 3 8 ;{id = 25266 (zsk), size = 2048b}
. 172800 IN DNSKEY 257 3 8 ;{id = 20326 (ksk), size = 2048b}
Checking if signing key is trusted:
New key: .      172800  IN      DNSKEY 
<snip>

I then reran drill with just the -D option and it now returns the "ad" flag which validates DNSSEC.

 drill -D x3mtek.com
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 11476
;; flags: qr rd ra ad ; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; x3mtek.com.  IN      A

;; ANSWER SECTION:
x3mtek.com.     300     IN      A       104.27.172.243
x3mtek.com.     300     IN      A       104.27.173.243
<snip>

Well, at least it seems to work now and validating with the "ad" flag. I did another drill -D a few minutes later and the "ad" flag was there.

https://linux.die.net/man/1/drill

 

[Xentrk]

So just out of curiosity what is your actual WAN interface name?

ppp0

 

[Swistheater]

I enabled DNSSEC via stubby.postconf:

#!/bin/sh
CONFIG=$1
source /usr/sbin/helper.sh
pc_insert "  - GETDNS_TRANSPORT_TLS" "dnssec_return_status: GETDNS_EXTENSION_TRUE" $CONFIG

followed by a reboot.

Validate DNSSEC:

stubby -l
[14:57:06.647624] STUBBY: Read config from file /etc/stubby/stubby.yml
[14:57:06.648410] STUBBY: DNSSEC Validation is ON
[14:57:06.648601] STUBBY: Transport list is:
[14:57:06.648871] STUBBY:   - TLS
[14:57:06.649121] STUBBY: Privacy Usage Profile is Strict (Authentication required)
[14:57:06.649244] STUBBY: (NOTE a Strict Profile only applies when TLS is the ONLY transport!!)
[14:57:06.649355] STUBBY: Starting DAEMON....
[14:57:14.201165] STUBBY: 9.9.9.9                                  : Conn opened: TLS - Strict Profile
[14:57:14.254501] STUBBY: 9.9.9.9                                  : Verify passed : TLS
<snip>

But the drill -D command did not return the "ad" flag:

drill -D x3mtek.com
;; ->>HEADER<<- opcode: QUERY, rcode: SERVFAIL, id: 8578
;; flags: qr rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; x3mtek.com.  IN      A

Reran drill adding the -T flag:

drill -DT x3mtek.com
;; Number of trusted keys: 2
;; Domain: .
[T] . 172800 IN DNSKEY 256 3 8 ;{id = 25266 (zsk), size = 2048b}
. 172800 IN DNSKEY 257 3 8 ;{id = 20326 (ksk), size = 2048b}
Checking if signing key is trusted:
New key: .      172800  IN      DNSKEY
<snip>

I then reran drill with just the -D option and it now returns the "ad" flag which validates DNSSEC.

 drill -D x3mtek.com
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 11476
;; flags: qr rd ra ad ; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; x3mtek.com.  IN      A

;; ANSWER SECTION:
x3mtek.com.     300     IN      A       104.27.172.243
x3mtek.com.     300     IN      A       104.27.173.243
<snip>

Well, at least it seems to work now and validating with the "ad" flag. I did another drill -D a few minutes later and the "ad" flag was there.

https://linux.die.net/man/1/drill

You need to tell dnsmasq to proxy-dnssec so you can see the flags

 

[Martineau]

I can't select channel 42 on my 86U. I have 40 and 44 but no 42.

@Swistheater / @Chrisgtl Did you not understand the diagram?

The UK Band "A" channels are 36-64 i.e. in increments of 4 in the GUI.

If you select 20MHz width, you have 8 discrete channels, and a WiFi scanner will show these 8 channels.

If you select 40MHz, then you will occupy 2 channels, leaving only 4 separate channels, so in the GUI, as an example, selecting either 44 or 48 will show up in a WiFi scanner as Ch46.

If you select 80MHz, then you occupy 4 channels, so in the GUI, selecting any of the following 36,40,44 or 48 will show up in a WiFi scanner as Ch42.

Simples!

In much the same way as using 20MHz and channels 1,6 or 11 for the 2.4GHz WLAN Spectrum (to be a good neighbour and reduce the amount of interference), it is sometimes necessary to use the discrete 20MHz channels i.e. suppose you had 6 APs, you wouldn't want them all hogging say Ch42 and fighting each other, so you would assign each of them to a different 20MHz channel.

Hope this is helpful.