not really since it stops redirection of packets that are actually properly being redirected. Instead of redirect, all packets not destined for the "Router" would be dropped, when it seems it is a specifically marked packet that is causing the problem. I imagine the issue could be resolved with a simple wireshark inspection of packet markings, and firewall blocking the bad packet type.
No.
I am not talking about blocking it by NXdomain status. I am talking about blocking it by hex string
What do you think you know about what to block? I feel like you’re misunderstanding the problem. The individual domain name doesn’t matter. I even reproduced it with router.asus.com.
explain why some redirects clearly work no problem, and some don't? are we looking at an issue of packet size, query type, or what? I am inviting you to break out the ol'@dave14305 chalk board and break it down instead of us creating a party of destructive criticism. I pulled out wireshark and I am literally inspecting packets that are working with redirect, and no kernel arguements. And I am also examining the one that clearly breaks on checksum.
Give me a query you have run without any kernel messages, and the output of
ip6tables -t nat -nvL
Chain INPUT (policy ACCEPT 48812 packets, 5767K bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 122K packets, 15M bytes)
pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 311K packets, 36M bytes)
pkts bytes target prot opt in out source destination
Chain DNSFILTER (2 references)
pkts bytes target prot opt in out source destination
0 0 RETURN all * * ::/0 ::/0 MAC E4:5F:01:45:57:9F
60773 6015K RETURN all * * ::/0 ::/0 MAC E4:5F:01:45:57:9D
0 0 RETURN all * * ::/0 ::/0 MAC DC:A6:32:D1:17:E3
60448 5983K RETURN all * * ::/0 ::/0 MAC DC:A6:32:D1:17:E2
0 0 RETURN all * * ::/0 ::/0 MAC DC:A6:32:23:32:57
62172 6147K RETURN all * * ::/0 ::/0 MAC DC:A6:32:23:32:56
127 11057 DNAT all * * !2601:348:300:292b::1 !2601:348:300:292b::1 to:2601:348:300:292b::1Chain INPUT (policy ACCEPT 49161 packets, 5810K bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 123K packets, 15M bytes)
pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 314K packets, 37M bytes)
pkts bytes target prot opt in out source destination
Chain DNSFILTER (2 references)
pkts bytes target prot opt in out source destination
0 0 RETURN all * * ::/0 ::/0 MAC E4:5F:01:45:57:9F
61195 6056K RETURN all * * ::/0 ::/0 MAC E4:5F:01:45:57:9D
0 0 RETURN all * * ::/0 ::/0 MAC DC:A6:32:D1:17:E3
60928 6030K RETURN all * * ::/0 ::/0 MAC DC:A6:32:D1:17:E2
0 0 RETURN all * * ::/0 ::/0 MAC DC:A6:32:23:32:57
62756 6203K RETURN all * * ::/0 ::/0 MAC DC:A6:32:23:32:56
128 11168 DNAT all * * !2601:348:300:292b::1 !2601:348:300:292b::1 to:2601:348:300:292b::1
Chain VSERVER (0 references)
pkts bytes target prot opt in out source destinationSo you’re not testing the same thing.
I do get the same kernel message when dig testing the address you used in your original nslookup test.
So the script is only modified to account for the dnsfilter set to router mode, and the clients on the client list set to no-filter.
#!/bin/sh
iptables -t nat -F DNSFILTER && iptables -t nat -X DNSFILTER
iptables -t nat -N DNSFILTER
ip6tables -t nat -F DNSFILTER && iptables -t nat -X DNSFILTER
ip6tables -t nat -N DNSFILTER
for filter in DNSFILTER_DOT; do
iptables -F $filter && iptables -X $filter
iptables -N $filter
ip6tables -F $filter && ip6tables -X $filter
ip6tables -N $filter
done
for filter in DNSFILTERF DNSFILTERI DNSFILTER_DOT; do
ip6tables -t mangle -F $filter && ip6tables -t mangle -X $filter
done
for i in 0 1 2 3 4 5; do
[ "$i" = "0" ] && NVARS="$(nvram get dnsfilter_rulelist | sed 's/>0/<>/g;s/<>/ /g;s/^[ \t]*//;s/[ \t]*$//')"
[ "$i" != "0" ] && NEXT_NVARS="$(nvram get dnsfilter_rulelist${i} | sed 's/>0/<>/g;s/<>/ /g;s/^[ \t]*//;s/[ \t]*$//')"
[ -n "$NEXT_NVARS" ] && NVARS="$NVARS $NEXT_NVARS"
done
for VAR in -D -I; do
iptables -t nat $VAR PREROUTING -i br+ -p tcp -m tcp --dport 53 -j DNSFILTER
iptables -t nat $VAR PREROUTING -i br+ -p udp -m udp --dport 53 -j DNSFILTER
ip6tables -t nat $VAR PREROUTING -i br+ -p tcp -m tcp --dport 53 -j DNSFILTER
ip6tables -t nat $VAR PREROUTING -i br+ -p udp -m udp --dport 53 -j DNSFILTER
iptables $VAR FORWARD -i br+ -p tcp -m tcp --dport 853 -j DNSFILTER_DOT
ip6tables $VAR FORWARD -i br+ -p tcp -m tcp --dport 853 -j DNSFILTER_DOT
iptables -t nat $VAR DNSFILTER ! -s $(nvram get lan_ipaddr)/32 ! -d $(nvram get lan_ipaddr)/32 -j DNAT --to-destination $(nvram get lan_ipaddr)
ip6tables -t nat $VAR DNSFILTER ! -s $(nvram get ipv6_rtr_addr)/128 ! -d $(nvram get ipv6_rtr_addr)/128 -j DNAT --to-destination $(nvram get ipv6_rtr_addr)
iptables $VAR DNSFILTER_DOT ! -d $(nvram get lan_ipaddr)/32 -j REJECT --reject-with icmp-port-unreachable
ip6tables $VAR DNSFILTER_DOT ! -d $(nvram get ipv6_rtr_addr)/128 -j REJECT --reject-with icmp6-port-unreachable
if [ -n "$NVARS" ]; then
for MAC_ADDR in $NVARS; do
iptables -t nat $VAR DNSFILTER -m mac --mac-source $MAC_ADDR -j RETURN
iptables $VAR DNSFILTER_DOT -m mac --mac-source $MAC_ADDR -j RETURN
ip6tables -t nat $VAR DNSFILTER -m mac --mac-source $MAC_ADDR -j RETURN
ip6tables $VAR DNSFILTER_DOT -m mac --mac-source $MAC_ADDR -j RETURN
done
fi
Just IPv4. I've disabled IPv6 on my network. Zero need for it.
I'm curious as to what "zero need for it" means in the context of IPv4 v. IPv6 means. Assuming one can get IPv4 addresses from an available IPv4 pool, why would anyone need IPv6? In other words, if someone has no need for it, why would anyone have need for it unless they're in some extremely unique environment?
Here is an interesting find. Atleast I didn't have the wrong thought when assuming the checksum errors were from unnecessary padding.
bugs.launchpad.net
bugs.launchpad.net
github.com
github.com
github.com
github.com
No that address is for my main router an RT-AX86. My access points are at .2 and .3.
Hahaha!
Did I mention... I really "Hate" IPv6... ;-)Here is an interesting find. Atleast I didn't have the wrong thought when assuming the checksum errors were from unnecessary padding.
similar issues:
Bug #1614953 “hw csum failure when IPv6 interfaces configured in...” : Bugs : linux package : Ubuntu
Since I started using IPv6 I noticed the following kernel error: Thu Aug 18 15:05:01 2016] <unknown>: hw csum failure [Thu Aug 18 15:05:01 2016] CPU: 5 PID: 11086 Comm: Chrome_IOThread Tainted: P OE 4.4.0-34-generic #53-Ubuntu [Thu Aug 18 15:05:01 2016] Hardware name: Gigabyte...cause of problem to those issues:Bug #1840854 “mlx5_core reports hardware checksum error for padd...” : Bugs : linux package : Ubuntu
BugLink: https://bugs.launchpad.net/bugs/1840854 [Impact] On machines equipped with Mellanox NIC's, in this particular case, Mellanox 5 series NICs using the mlx5_core driver, after installing 4.15.0-56 or later there is the following kernel splat: bond0: hw csum failure CPU: 63 PID: 2473...
net: pskb_trim_rcsum() and CHECKSUM_COMPLETE are friends · torvalds/linux@88078d9
After working on IP defragmentation lately, I found that some large packets defeat CHECKSUM_COMPLETE optimization because of NIC adding zero paddings on the last (small) fragment. While removing t...
---- similar to Asus's ----
asuswrt-merlin.ng/release/src-rt-5.02L.07p2axhnd/kernel/linux-4.1/include/linux/skbuff.h at main · RMerl/asuswrt-merlin.ng
Third party firmware for Asus routers (newer codebase) - RMerl/asuswrt-merlin.ng
some solutions to those issues:
net/mlx4_en: Force CHECKSUM_NONE for short ethernet frames · torvalds/linux@74abc07
When an ethernet frame is padded to meet the minimum ethernet frame size, the padding octets are not covered by the hardware checksum. Fortunately the padding octets are usually zero's, which d...
net/mlx5e: Force CHECKSUM_UNNECESSARY for short ethernet frames · torvalds/linux@e8c8b53
When an ethernet frame is padded to meet the minimum ethernet frame size, the padding octets are not covered by the hardware checksum. Fortunately the padding octets are usually zero's, which d...
Unless someone feels like tackling patches for @RMerlin's kernel 4 and up SDK's (and Asus's), I image the easiest thing to do is what @dave14305 did in this post https://www.snbforums.com/threads/a...able-for-all-models.79450/page-23#post-772610
