Release Asuswrt-Merlin 386.7 is now available for all models

[RMerlin]

I understand it's country specific, but my mobile phone has public IPv4 address (IPv6 not supported)

Odd. I'm with Fido, which ain't exactly a main brand (it's Roger's flanker brand) and they've quietly supported IPv6 for a few years now.

 

[RMerlin]

So does 149.112.112.11, so if you want to be consistent replace that with 149.112.112.112 (No ECS) in your copy.

I don't want to start diverting from Asus, because then it means I'll need to start manually updating it instead of just running a series of wget commands I have bookmarked in the Makefile.

 

[SomeWhereOverTheRainBow]

Test with the query posted by Dave. I was able to reproduce the issue on an RT-AX86U with just that single query.

Correct that does produce the issue. That specific query.

 

[learning_curve]

I think this is related to the new IPv6 DNAT for DNS Filter.

rc: implement DNAT support for dnsfilter over IPV6 on HND models · RMerl/asuswrt-merlin.ng@c454668

Third party firmware for Asus routers (newer codebase) - rc: implement DNAT support for dnsfilter over IPV6 on HND models · RMerl/asuswrt-merlin.ng@c454668

github.com

I can recreate this by manually setting DNS on my iPad to Cloudflare IPv6 (2606:4700:4700::1112), having DNS Filter in Router mode, and then running the test at https://cmdns.dev.dns-oarc.net/

I imagine the rewrite of the udp ipv6 headers probably triggers this problem.

That is completely odd. I just ran the same test, on the RT-AX88U and same firmware. Same method but I changed the DNS on a desktop computer and not an IPAD. Here are my results.

View attachment 42262

I have No logs like that in my syslog.

FWIW I ran the exact same test (mimic) as @dave14305 did, by manually setting the DNS on my iPad Pro to Cloudflare IPv6 2606:4700:4700::1112) whilst having DNS Filter set in 'Router' mode (but without any additional Custom (user-defined) DNS entries - IPv4 or IPv6) and then running the same test that he did on the same site: https://cmdns.dev.dns-oarc.net/ The log results are... the same (rinse and repeat) despite getting the same image / view from the test site, as you @SomeWhereOverTheRainBow aka This specific issue is internal to the router.

Spoiler

Jun 29 12:38:04 kernel: <unknown>: hw csum failure
Jun 29 12:38:04 kernel: CPU: 0 PID: 2926 Comm: dnsmasq Tainted: P O 4.1.52 #2
Jun 29 12:38:04 kernel: Hardware name: Broadcom-v8A (DT)
Jun 29 12:38:04 kernel: Call trace:
Jun 29 12:38:04 kernel: [<ffffffc000087398>] dump_backtrace+0x0/0x150
Jun 29 12:38:04 kernel: [<ffffffc0000874fc>] show_stack+0x14/0x20
Jun 29 12:38:04 kernel: [<ffffffc0005589d0>] dump_stack+0x90/0xb0
Jun 29 12:38:04 kernel: [<ffffffc0003fe05c>] netdev_rx_csum_fault+0x3c/0x50
Jun 29 12:38:04 kernel: [<ffffffc0003f22d0>] skb_copy_and_csum_datagram_msg+0xe8/0xf8
Jun 29 12:38:04 kernel: [<ffffffc0004f8468>] udpv6_recvmsg+0x2a0/0x7d8
Jun 29 12:38:04 kernel: [<ffffffc0004a616c>] inet_recvmsg+0xa4/0xc8
Jun 29 12:38:04 kernel: [<ffffffc0003df4d4>] sock_recvmsg+0x14/0x20
Jun 29 12:38:04 kernel: [<ffffffc0003e10e4>] ___sys_recvmsg+0xac/0x1a8
Jun 29 12:38:04 kernel: [<ffffffc0003e3b18>] __sys_recvmsg+0x40/0x80
Jun 29 12:38:04 kernel: [<ffffffc000423410>] compat_SyS_recvmsg+0x10/0x18

In a nutshell, IF, you are intentionally allowing devices to circumvent the router specified IPv6 DNS, either by applying IPv6 DNS manually on the device itself as tested above ^^ or, I presume, but have not tried myself by applying IPv6 DNS manually on the device itself, using Custom (user-defined) IPv6 DNS entries in the DNS Filter, you'll have this issue. If you don't, you won't. I have no need to do this, so I don't, hence I haven't had the issue at all, so far, apart from during this ^^ test. Caveat: IF you circumvent the router specified IPv6 DNS via a 3rd part VPN Client (IPv4 & IPv6) on a device, this also, does not trigger this issue, which is what I had guessed. I did test this myself; No related log entries, just the same as using the router normally without any IPv6 DNS circumvention.

 

[dave14305]

It didn’t help, unfortunately. There’s so little written about issues DNATting IPv6 UDP packets, that I’m starting to believe it’s another Broadcom “gift”. Disabling DNS Filter will avoid it.

I’ve added a nat-start script so I can keep DNSFilter enabled for IPv4.

#!/bin/sh

if [ "$(nvram get dnsfilter_enable_x)" = "1" ] && [ "$(nvram get dnsfilter_mode)" = "11" ]; then
        ip6tables -t nat -F PREROUTING
fi

using Custom (user-defined) IPv6 DNS entries in the DNS Filter, you'll have this issue

I haven’t tested it, but I don’t think it will occur unless dnsmasq receives the packets. So custom IPv6 entries apart from the router IPv6 LAN address should not be affected.

 

[nakti]

Is there any fix for rat?

ZuoRAT Malware Hijacking Home-Office Routers to Spy on Targeted Networks

Researchers warn of a new malware, dubbed ZuoRAT, targeting small office/home office routers (SOHO) as part of a sophisticated campaign.

thehackernews.com

 

[SomeWhereOverTheRainBow]

FWIW I ran the exact same test (mimic) as @dave14305 did, by manually setting the DNS on my iPad Pro to Cloudflare IPv6 2606:4700:4700::1112) whilst having DNS Filter set in 'Router' mode (but without any additional Custom (user-defined) DNS entries - IPv4 or IPv6) and then running the same test that he did on the same site: https://cmdns.dev.dns-oarc.net/ The log results are... the same (rinse and repeat) despite getting the same image / view from the test site, as you @SomeWhereOverTheRainBow aka This specific issue is internal to the router.

Spoiler

Jun 29 12:38:04 kernel: <unknown>: hw csum failure
Jun 29 12:38:04 kernel: CPU: 0 PID: 2926 Comm: dnsmasq Tainted: P O 4.1.52 #2
Jun 29 12:38:04 kernel: Hardware name: Broadcom-v8A (DT)
Jun 29 12:38:04 kernel: Call trace:
Jun 29 12:38:04 kernel: [<ffffffc000087398>] dump_backtrace+0x0/0x150
Jun 29 12:38:04 kernel: [<ffffffc0000874fc>] show_stack+0x14/0x20
Jun 29 12:38:04 kernel: [<ffffffc0005589d0>] dump_stack+0x90/0xb0
Jun 29 12:38:04 kernel: [<ffffffc0003fe05c>] netdev_rx_csum_fault+0x3c/0x50
Jun 29 12:38:04 kernel: [<ffffffc0003f22d0>] skb_copy_and_csum_datagram_msg+0xe8/0xf8
Jun 29 12:38:04 kernel: [<ffffffc0004f8468>] udpv6_recvmsg+0x2a0/0x7d8
Jun 29 12:38:04 kernel: [<ffffffc0004a616c>] inet_recvmsg+0xa4/0xc8
Jun 29 12:38:04 kernel: [<ffffffc0003df4d4>] sock_recvmsg+0x14/0x20
Jun 29 12:38:04 kernel: [<ffffffc0003e10e4>] ___sys_recvmsg+0xac/0x1a8
Jun 29 12:38:04 kernel: [<ffffffc0003e3b18>] __sys_recvmsg+0x40/0x80
Jun 29 12:38:04 kernel: [<ffffffc000423410>] compat_SyS_recvmsg+0x10/0x18

In a nutshell, IF, you are intentionally allowing devices to circumvent the router specified IPv6 DNS, either by applying IPv6 DNS manually on the device itself as tested above ^^ or, I presume, but have not tried myself by applying IPv6 DNS manually on the device itself, using Custom (user-defined) IPv6 DNS entries in the DNS Filter, you'll have this issue. If you don't, you won't. I have no need to do this, so I don't, hence I haven't had the issue at all, so far, apart from during this ^^ test. Caveat: IF you circumvent the router specified IPv6 DNS via a 3rd part VPN Client (IPv4 & IPv6) on a device, this also, does not trigger this issue, which is what I had guessed. I did test this myself; No related log entries, just the same as using the router normally without any IPv6 DNS circumvention.

It seems to only happen specifically with this type of query, so something is amiss with it specifically. I can dig test www.google.com using a different ipv6 dns server all day on a windows client and the redirect works just fine.

 

[Paliv]

Is there any fix for rat?

ZuoRAT Malware Hijacking Home-Office Routers to Spy on Targeted Networks

Researchers warn of a new malware, dubbed ZuoRAT, targeting small office/home office routers (SOHO) as part of a sophisticated campaign.

thehackernews.com

Keep your router updated. To this point it appears they are using old/known exploits for the initial vector.

 

[heysoundude]

See https://en.wikipedia.org/wiki/Rube_Goldberg_machine as to why that is not necessarily true.

and modern Internal combustion engined cars are increasingly resembling Goldberg's creations...

 

[SomeWhereOverTheRainBow]

I’ve added a nat-start script so I can keep DNSFilter enabled for IPv4.

#!/bin/sh

if [ "$(nvram get dnsfilter_enable_x)" = "1" ] && [ "$(nvram get dnsfilter_mode)" = "11" ]; then
        ip6tables -t nat -F PREROUTING
fi

I haven’t tested it, but I don’t think it will occur unless dnsmasq receives the packets. So custom IPv6 entries apart from the router IPv6 LAN address should not be affected.

I don't know the real "value" of doing this, since the break appears to only happen with certain queries using this test. It seems like the kernel is misinterpreting the results and flagging taint because of misinterpretation of the request results. (i.e. the kernel is assuming impropriety.)


This is an example where i use my router to force safe search with same ipv6 redirect rules.

Here is my "dig test" results of the same query you were trying.

 

[heysoundude]

I don't think so. 47,573,248 IPs on ~26mln population. About the same ratio in Canada. And we don't worry here.

we're also not particularly forward-thinking or innovative, because we hesitate to take the plunge. toe dippers is what we are, forever checking the waters. It's almost like we're afraid of showing that we're human and can make mistakes and recover, which may stem from a national sense of esteem...but these are discussions beyond this thread and place.

 

[ColinTaylor]

It seems like the kernel is misinterpreting the results and flagging taint because of misinterpretation of a failed request.

The "Tainted" part of the message is irrelevant.

 

[SomeWhereOverTheRainBow]

The "Tainted" part of the message is irrelevant.

In reality, from what I can tell is that it works just fine, and the tainted message is the kernels way of screaming impropriety at the modules being used (or atleast at what it is interpreting). I can see my ipv6 request being redirected just fine. So I would assume it is doing its job and only bugging out on random not so common request like the one in question for this test.

When I do this dig request, I don't get the same tainted message that I do with the test query.

 

[ToeStub]

Mixed results on dirty upgrades:

1x RT-AC88U Router: Success, no issues.
2x RT-AC68U and 1x RT-AC68P as AiMesh Nodes: Updated successfully, but would not reconnect to AiMesh Router. Tried re-pairing as well (edit: factory reset and re-paired "successfully," but would not reconnect after reboot). Had to downgrade to 386.5_2.

Don't know if this is related, but I could not successfully login through SSH after upgrading the AC68x nodes to 386.7.

 

[ColinTaylor]

and the tainted message is the kernels way of screaming impropriety at the modules being used

The "tainted" part isn't "screaming" anything. It's just one small piece of the information being dumped - it's not the cause of the problem. We already know the module creating the dump is dnsmasq and that it's proprietary (just like most of the rest of the firmware).

 

[JGrana]

Odd. I'm with Fido, which ain't exactly a main brand (it's Roger's flanker brand) and they've quietly supported IPv6 for a few years now.

Hmm, did realize this. Im on US Verizon. I just checked my phones IP public address - sure enough IPv6.

 

[pirx73]

I understand it's country specific, but my mobile phone has public IPv4 address (IPv6 not supported) and my ISP is providing 2x public IPv4 addresses (IPv6 supported). I keep IPv6 disabled (disabled by Default settings) on all my networks for multiple reasons and everything is working properly.

Same here. In Latvia no ISP offers IPv6 to private customers. And only one ISP offers IPv6 to business customers.

 

[SomeWhereOverTheRainBow]

The "tainted" part isn't "screaming" anything. It's just one small piece of the information being dumped - it's not the cause of the problem. We already know the module creating the dump is dnsmasq and that it's proprietary (just like most of the rest of the firmware).

I don't know about that, the kernel taint if you run debug on it is setting the 12th bit as well as the first. May not indicate anything, but that is where I was getting my observation. Which may be misinterpreted.

 

[Mutzli]

Is there any fix for rat?

ZuoRAT Malware Hijacking Home-Office Routers to Spy on Targeted Networks

Researchers warn of a new malware, dubbed ZuoRAT, targeting small office/home office routers (SOHO) as part of a sophisticated campaign.

thehackernews.com

I think this affects only MIPS routers.

 

[ColinTaylor]

I don't know about that, the kernel taint if you run debug on it is setting the 12th bit as well as the first. May not indicate anything, but that is where I was getting my observation. Which may be misinterpreted.

Pick a process, almost any process and dump it. They all have the same "Tainted:" information being displayed.

killall -s SEGV dnsmasq
killall -s SEGV vsftpd
killall -s SEGV miniupnpd
killall -s SEGV vnstatd

Jun 29 14:08:14 kernel: CPU: 1 PID: 18692 Comm: dnsmasq Tainted: P           O    4.1.52 #2
Jun 29 14:09:07 kernel: CPU: 3 PID: 3251 Comm: vsftpd Tainted: P           O    4.1.52 #2
Jun 29 14:10:30 kernel: CPU: 0 PID: 3259 Comm: miniupnpd Tainted: P           O    4.1.52 #2
Jun 29 14:12:54 kernel: CPU: 2 PID: 3213 Comm: vnstatd Tainted: P           O    4.1.52 #2