[Release] Asuswrt-Merlin 384.11 is available

[scjr]

Also, it looks like the default config for DNS Filter is set to 8.8.8.8. Do I need to change this if I want to be using Cloudflare?

Just set DNSFilter to Router. You can clear those fields.

 

[RMerlin]

Also, it looks like the default config for DNS Filter is set to 8.8.8.8. Do I need to change this if I want to be using Cloudflare?

The Custom Field values only get used if you set anything to use the Custom Field 1,2 or 3, either globally or allocated to a client in the list below.

 

[richardeid]

So I can have the router tell specific clients which DNS I'd like them to use? That seems pretty handy. Thank you guys for clearing this up for me.

 

[Kingp1n]

Do you have DNS Filter turned on with global mode set to Router? --If not any device with a hard coded DNS can bypass DoT.

(e.g. Android Phone)

I thought you only turn on this feature if you require clients that need to be filtered?

 

[skeal]

I thought you only turn on this feature if you require clients that need to be filtered?

That is exactly what has just been described.

 

[DAVIZINHO]

I backported anything related to ntpd that was potentially worth it, from the latest Busybox release. Don't know for sure if any of these affected us, but it was safer to backport them just in case. These should make it into 384.11_2 (the changes targeting 384.12 are in a separate branch for now).

Great!! all the spanish people are waiting for this 384.11_2 jejeje
when do you release it?

thanks for your great job!!

 

[Kingp1n]

That is exactly what has just been described.

I'm tracking now...some clients are hardcoded to use specific DNS and turning on this feature will force router options. I initially had DSNFilter off since I didn't need any device to be filtered but I just turned on the option to use "router". Thanks!

 

[L&LD]

Great!! all the spanish people are waiting for this 384.11_2 jejeje
when do you release it?

thanks for your great job!!

When it's ready and RMerlin says when that is.

 

[Swistheater]

I did not. I just turned it on. It looks like that took care of a lot of the traffic on port 53, but what does it mean if I still see something? So for instance after switching DNS Filter on and setting it to Router, I got one result in tcpdump right away.

20:04:18.834101 IP 61-219-11-153.hinet-ip.hinet.net.62288 > {removed}: Flags [S], seq 988932639, win 1024, length 0

Also, it looks like the default config for DNS Filter is set to 8.8.8.8. Do I need to change this if I want to be using Cloudflare?

I'm sorry if this is all so basic. As time has gone on I haven't kept up with this stuff the way I should have and get lost in a lot of these new options. But thank you for such a fast response.

make all of the custom dns addresses on dns filter be empty
it should look like this

any other connections you see on port 53 should just be strictly for router communications ( like updating the clock)

 

[Swistheater]

So I can have the router tell specific clients which DNS I'd like them to use? That seems pretty handy. Thank you guys for clearing this up for me.

Note: if you do decide to use custom dns options to specify a specific dns for a device it will show up as port 53 request again because it will not use DoT for that function. Any other traffic though will be designated to DoT as long as you have the global feature set to "ROUTER". the main good feature about specifing custom dns or using one of the DNS in the list of filters for a client device is if you want a childs device to use like say for example Open DNS for its specific filtering features.

In this example the device is set to use openDNS family as a filter. the traffic for this device would show up as port 53 traffic, while the rest of the devices would be force to use DoT port 853

in this specific example we have specified google dns as custom for a filter- and this will force the device in the list to specifically use google dns-- this will show up as port 53 traffic, while the rest of the devices will show up as port 853 traffic.

 

[Swistheater]

Great!! all the spanish people are waiting for this 384.11_2 jejeje
when do you release it?

thanks for your great job!!

if the spanish people need it that bad maybe they can join the community of self compilers. as for merlin i am sure he will build it when he feels he has adequate enough changes to justify a release.

 

[Kingp1n]

384.11_2 ? Is this tailored to have Spanish translation option?

 

[Gar]

make all of the custom dns addresses on dns filter be empty
it should look like this

View attachment 17627

any other connections you see on port 53 should just be strictly for router communications ( like updating the clock)

Isn't this the same as leaving dns filtering off since there are no clients to get individual filtering in the list?

 

[Delusion]

After some "investigation" , Diversion Standard causes the dcd crash when using 384.11 with DNSSEC and DoT enable. However, everything works fine when using Diversion Lite which doesn't block https ads, no crash what so ever . Is there something that can be done to make Diversion Standard with Pixelserv-tls work on 384.11 with DNSSEC+DoT enabled without crashing dcd ?

I did all the resetting and reflashing but nothing helps. Once installing or upgrading standard the dcd start crashing every 20-10 minutes.

May 13 00:16:46 kernel: dcd[1878]: unhandled level 3 translation fault (11) at 0x00000000, esr 0x92000007
May 13 00:16:46 kernel: pgd = ffffffc00b592000
May 13 00:16:46 kernel: [00000000] *pgd=000000000b7b9003, *pud=000000000b7b9003, *pmd=000000000b7b8003, *pte=0000000000000000
May 13 00:16:46 kernel: CPU: 1 PID: 1878 Comm: dcd Tainted: P           O    4.1.27 #2
May 13 00:16:46 kernel: Hardware name: Broadcom-v8A (DT)
May 13 00:16:46 kernel: task: ffffffc01e0335c0 ti: ffffffc00b7c8000 task.ti: ffffffc00b7c8000
May 13 00:16:46 kernel: PC is at 0xf6ec9f44
May 13 00:16:46 kernel: LR is at 0x1dc74
May 13 00:16:46 kernel: pc : [<00000000f6ec9f44>] lr : [<000000000001dc74>] pstate: 600e0010
May 13 00:16:46 kernel: sp : 00000000ffc4dc58
May 13 00:16:46 kernel: x12: 000000000009ff08
May 13 00:16:46 kernel: x11: 00000000f61ff024 x10: 00000000000a02ac
May 13 00:16:46 kernel: x9 : 00000000f61ff798 x8 : 00000000000a0764
May 13 00:16:46 kernel: x7 : 00000000f61ff7d0 x6 : 00000000000a075e
May 13 00:16:46 kernel: x5 : 0000000000000000 x4 : 00000000f61ff77c
May 13 00:16:46 kernel: x3 : 0000000000000000 x2 : 00000000ffc4dc34
May 13 00:16:46 kernel: x1 : 000000000007c66c x0 : 0000000000000000

 

[Swistheater]

Isn't this the same as leaving dns filtering off since there are no clients to get individual filtering in the list?

No because you are telling the router to globally force all devices hardcoded or not to use dot and when you use the list you are merely allowing one device.to use a different filter, in this page the ROUTER is forced as the filter so if you have DoT enabled it is forced as filter unless you use a client list for something you want on a different filter as I mentioned in the second post

 

[Swistheater]

The option "NO FILTER" globally set would be the same as leaving it off. Meaning any device that is hardcoded a different dns can avoid DoT and leak unencrypted traffic through port 53 defeating the purpose of using DoT

Example would be a android device that is hard coded to use google dns.

 

[Butterfly Bones]

After some "investigation" , Diversion Standard causes the dcd crash when using 384.11 with DNSSEC and DoT enable. However, everything works fine when using Diversion Lite which doesn't block https ads, no crash what so ever . Is there something that can be done to make Diversion Standard with Pixelserv-tls work on 384.11 with DNSSEC+DoT enabled without crashing dcd ?

I did all the resetting and reflashing but nothing helps. Once installing or upgrading standard the dcd start crashing every 20-10 minutes.

May 13 00:16:46 kernel: dcd[1878]: unhandled level 3 translation fault (11) at 0x00000000, esr 0x92000007
May 13 00:16:46 kernel: pgd = ffffffc00b592000
May 13 00:16:46 kernel: [00000000] *pgd=000000000b7b9003, *pud=000000000b7b9003, *pmd=000000000b7b8003, *pte=0000000000000000
May 13 00:16:46 kernel: CPU: 1 PID: 1878 Comm: dcd Tainted: P           O    4.1.27 #2
May 13 00:16:46 kernel: Hardware name: Broadcom-v8A (DT)
May 13 00:16:46 kernel: task: ffffffc01e0335c0 ti: ffffffc00b7c8000 task.ti: ffffffc00b7c8000
May 13 00:16:46 kernel: PC is at 0xf6ec9f44
May 13 00:16:46 kernel: LR is at 0x1dc74
May 13 00:16:46 kernel: pc : [<00000000f6ec9f44>] lr : [<000000000001dc74>] pstate: 600e0010
May 13 00:16:46 kernel: sp : 00000000ffc4dc58
May 13 00:16:46 kernel: x12: 000000000009ff08
May 13 00:16:46 kernel: x11: 00000000f61ff024 x10: 00000000000a02ac
May 13 00:16:46 kernel: x9 : 00000000f61ff798 x8 : 00000000000a0764
May 13 00:16:46 kernel: x7 : 00000000f61ff7d0 x6 : 00000000000a075e
May 13 00:16:46 kernel: x5 : 0000000000000000 x4 : 00000000f61ff77c
May 13 00:16:46 kernel: x3 : 0000000000000000 x2 : 00000000ffc4dc34
May 13 00:16:46 kernel: x1 : 000000000007c66c x0 : 0000000000000000

Nice shotgun approach.

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

 

[Swistheater]

After some "investigation" , Diversion Standard causes the dcd crash when using 384.11 with DNSSEC and DoT enable. However, everything works fine when using Diversion Lite which doesn't block https ads, no crash what so ever . Is there something that can be done to make Diversion Standard with Pixelserv-tls work on 384.11 with DNSSEC+DoT enabled without crashing dcd ?

I did all the resetting and reflashing but nothing helps. Once installing or upgrading standard the dcd start crashing every 20-10 minutes.

May 13 00:16:46 kernel: dcd[1878]: unhandled level 3 translation fault (11) at 0x00000000, esr 0x92000007
May 13 00:16:46 kernel: pgd = ffffffc00b592000
May 13 00:16:46 kernel: [00000000] *pgd=000000000b7b9003, *pud=000000000b7b9003, *pmd=000000000b7b8003, *pte=0000000000000000
May 13 00:16:46 kernel: CPU: 1 PID: 1878 Comm: dcd Tainted: P           O    4.1.27 #2
May 13 00:16:46 kernel: Hardware name: Broadcom-v8A (DT)
May 13 00:16:46 kernel: task: ffffffc01e0335c0 ti: ffffffc00b7c8000 task.ti: ffffffc00b7c8000
May 13 00:16:46 kernel: PC is at 0xf6ec9f44
May 13 00:16:46 kernel: LR is at 0x1dc74
May 13 00:16:46 kernel: pc : [<00000000f6ec9f44>] lr : [<000000000001dc74>] pstate: 600e0010
May 13 00:16:46 kernel: sp : 00000000ffc4dc58
May 13 00:16:46 kernel: x12: 000000000009ff08
May 13 00:16:46 kernel: x11: 00000000f61ff024 x10: 00000000000a02ac
May 13 00:16:46 kernel: x9 : 00000000f61ff798 x8 : 00000000000a0764
May 13 00:16:46 kernel: x7 : 00000000f61ff7d0 x6 : 00000000000a075e
May 13 00:16:46 kernel: x5 : 0000000000000000 x4 : 00000000f61ff77c
May 13 00:16:46 kernel: x3 : 0000000000000000 x2 : 00000000ffc4dc34
May 13 00:16:46 kernel: x1 : 000000000007c66c x0 : 0000000000000000

I havent seen this before.

 

[Delusion]

Nice shotgun approach.

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

Its different once I know the cause . dcd is not crashing when not using dns-over-tls with pixelserv-TLS which comes with Diversion Standard . Maybe its worth trying dnscrypt with dns-over-tls and see if it works well with Diversion Standard

 

[Butterfly Bones]

Its different once I know the cause

Look at top or htop and see how many instances of dcd are running. Here is mine with six instances. They will trigger anything with dcd from TrendMicro.