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.
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.
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.
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 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 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.
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.
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.
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.
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.
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.
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.
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.
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 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 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.
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.
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
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!
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.