What's new

[Release] Asuswrt-Merlin 384.11 is available

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

I flashed this morning from 384.10_2.

I can't get the tcpdump command to display any output:
Code:
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:

Code:
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:
Code:
netstat -lnpt | grep -E '^Active|^Proto|/stubby'
Code:
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
 
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.
 
Last edited:
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 .
 
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?
 
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?

Code:
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/
 
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?

upload_2019-5-11_14-49-46.png


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)
 
Last edited:
I can't get the tcpdump command to display any output:
Code:
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
Code:
tcpdump -D
So from the tcpdump interface name list.....try
Code:
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
Code:
tcpdump -tttt -n -i $(nvram get wan0_gw_ifname) port 53 or 853
 
Approaching 3 days uptime. Everything running great. All WiFi clients connected. DoT Cloudflare running well. Thanks, RMerlin!
 
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.
 
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.
 
FYI, tcpdump can advise you of all of the interfaces available
Code:
tcpdump -D
So from the tcpdump interface name list.....try
Code:
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
Code:
tcpdump -tttt -n -i $(nvram get wan0_gw_ifname) port 53 or 853
Thanks @Martineau!

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

works. Very verbose.

Good addition for the Wiki.
 
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.
 
I enabled DNSSEC via stubby.postconf:

Code:
#!/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:
Code:
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:

Code:
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:

Code:
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.
Code:
 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>

:confused: 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
 
I enabled DNSSEC via stubby.postconf:

Code:
#!/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:
Code:
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:

Code:
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:

Code:
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.
Code:
 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>

:confused: 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
 
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!:D

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.
 

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top