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.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.I understand it's country specific, but my mobile phone has public IPv4 address (IPv6 not supported)
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.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.
Correct that does produce the issue. That specific query.Test with the query posted by Dave. I was able to reproduce the issue on an RT-AX86U with just that single query.
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@c454668github.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.
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.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.
I’ve added a nat-start script so I can keep DNSFilter enabled for IPv4.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.
#!/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.using Custom (user-defined) IPv6 DNS entries in the DNS Filter, you'll have this issue
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.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.
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.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
Keep your router updated. To this point it appears they are using old/known exploits for the initial vector.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
and modern Internal combustion engined cars are increasingly resembling Goldberg's creations...See https://en.wikipedia.org/wiki/Rube_Goldberg_machine as to why that is not necessarily true.
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.)I’ve added a nat-start script so I can keep DNSFilter enabled for IPv4.
Bash:#!/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.
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.I don't think so. 47,573,248 IPs on ~26mln population. About the same ratio in Canada. And we don't worry here.
The "Tainted" part of the message is irrelevant.It seems like the kernel is misinterpreting the results and flagging taint because of misinterpretation of a failed request.
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.The "Tainted" part of the message is irrelevant.
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).and the tainted message is the kernels way of screaming impropriety at the modules being used
Hmm, did realize this. Im on US Verizon. I just checked my phones IP public address - sure enough IPv6.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.
Same here. In Latvia no ISP offers IPv6 to private customers. And only one ISP offers IPv6 to business customers.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.
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 think this affects only MIPS routers.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
Pick a process, almost any process and dump it. They all have the same "Tainted:" information being displayed.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.
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
Welcome To SNBForums
SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.
If you'd like to post a question, simply register and have at it!
While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!