What's new

Release Asuswrt-Merlin 386.7 is now available for all models

  • 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!

Status
Not open for further replies.
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.
 
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.
 
I think this is related to the new IPv6 DNAT for DNS Filter.

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.
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’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
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.
 
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.

1656504715146.png


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

1656504890616.png
 

Attachments

  • 1656504595021.png
    1656504595021.png
    24.4 KB · Views: 59
Last edited:
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.
 
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.

1656505495082.png
 
Last edited:
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.
 
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).
 
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.
 
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.
 
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.
Pick a process, almost any process and dump it. They all have the same "Tainted:" information being displayed.
Code:
killall -s SEGV dnsmasq
killall -s SEGV vsftpd
killall -s SEGV miniupnpd
killall -s SEGV vnstatd
Code:
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
 
Status
Not open for further replies.

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