Release Asuswrt-Merlin 386.7 is now available for all models

[SomeWhereOverTheRainBow]

Isn't the end result the same as @dave14305's idea.

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.

 

[RMerlin]

would it be possible to prevent the type of packet with the firewall since it seems to result in NXdomain any ways?

No.

1) The firewall cannot tell ahead of time that a query is going to result in an NXDOMAIN
2) NXDOMAIN is a valid response, and is not the same as not getting any response at all.

The only possibilities are either to resolve the checksum issue, or to stop redirecting queries to the router. Since the first one seems impossible to do, then the only solution is the latter.

 

[BobbyFlobby]

tested again, full reset. 2x Ax86u AImesh ethernet backhaul. on 2.4, certain older wifi devices wouldnt connect or stuggle to connect / stay on. back down to 5_2 again and everything is perfect. same issue with official asus firmware.

 

[SomeWhereOverTheRainBow]

No.

1) The firewall cannot tell ahead of time that a query is going to result in an NXDOMAIN
2) NXDOMAIN is a valid response, and is not the same as not getting any response at all.

The only possibilities are either to resolve the checksum issue, or to stop redirecting queries to the router. Since the first one seems impossible to do, then the only solution is the latter.

I am not talking about blocking it by NXdomain status. I am talking about blocking it by hex string

 

[dave14305]

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.

 

[SomeWhereOverTheRainBow]

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.

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.

 

[dave14305]

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

I will run the same one.

 

[SomeWhereOverTheRainBow]

Give me a query you have run without any kernel messages, and the output of ip6tables -t nat -nvL

I will run the same one.

this is what I was at before

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::1

This is what I am at after.

Chain 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               destination

i ran

Note I have modified catch all rule over the traditional one Merlin uses. I already mentioned this fact to him.

Here is wireshark

I have No kernel logs.

here is the same one done over ipv4 using identical dnsfilter rules with LAN ipv4

Note these are client side wiresharks. I imagine a pcap on the router might look slightly different.

 

[dave14305]

Note I have modified catch all rule over the traditional one Merlin uses. I already mentioned this fact to him.

So you’re not testing the same thing.

I did note an interesting difference in my testing. If I run nslookup interactively, manually setting the server and entering the query at the nslookup “prompt”, I don’t get the kernel messages. If I put it all on one line, I do get the kernel messages. Using PowerShell Resolve-DnsName works fine.

Will think about it more after dinner.

 

[SomeWhereOverTheRainBow]

So you’re not testing the same thing.

I did note an interesting difference in my testing. If I run nslookup interactively, manually setting the server and entering the query at the nslookup “prompt”, I don’t get the kernel messages. If I put it all on one line, I do get the kernel messages. Using PowerShell Resolve-DnsName works fine.

Will think about it more after dinner.

I do get the same kernel message when dig testing the address you used in your original nslookup test.

I am in away I will send you my modification script after dinner and see if you notice any improvements.

 

[SomeWhereOverTheRainBow]

So you’re not testing the same thing.

I did note an interesting difference in my testing. If I run nslookup interactively, manually setting the server and entering the query at the nslookup “prompt”, I don’t get the kernel messages. If I put it all on one line, I do get the kernel messages. Using PowerShell Resolve-DnsName works fine.

Will think about it more after dinner.

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

further adaptation would have to be made to account for clients set to use any other option than no filter.

 

[shabbs]

Are you using ipv6 also or just ipv4?

Just IPv4. I've disabled IPv6 on my network. Zero need for it.

 

[AntonK]

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?

 

[SomeWhereOverTheRainBow]

So you’re not testing the same thing.

I did note an interesting difference in my testing. If I run nslookup interactively, manually setting the server and entering the query at the nslookup “prompt”, I don’t get the kernel messages. If I put it all on one line, I do get the kernel messages. Using PowerShell Resolve-DnsName works fine.

Will think about it more after dinner.

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

bugs.launchpad.net

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

bugs.launchpad.net

cause of problem to those issues:

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

github.com

---- similar to Asus's ----

asuswrt-merlin.ng/release/src-rt-5.02L.07p2axhnd/kernel/linux-4.1/include/linux/skbuff.h at master · RMerl/asuswrt-merlin.ng

Third party firmware for Asus routers (newer codebase) - RMerl/asuswrt-merlin.ng

github.com

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

github.com

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

github.com

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

 

[Tech9]

In other words, if someone has no need for it, why would anyone have need for it

Because of this:

List of countries by IPv4 address allocation - Wikipedia

en.wikipedia.org

If you live in Canada, you don't have need for IPv6. If you live in India though, IPv6 may be your only option.

 

[Tech9]

unless they're in some extremely unique environment?

Now you know why many Indian folks pack their bags and arrive in Canada. They want an IPv4 address too.

 

[rlfromm]

Try 192.168.1.1

No that address is for my main router an RT-AX86. My access points are at .2 and .3.

 

[AntonK]

Now you know why many Indian folks pack their bags and arrive in Canada. They want an IPv4 address too.

Hahaha!

 

[capncybo]

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

bugs.launchpad.net

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

bugs.launchpad.net

cause of problem to those issues:

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

github.com

---- similar to Asus's ----

asuswrt-merlin.ng/release/src-rt-5.02L.07p2axhnd/kernel/linux-4.1/include/linux/skbuff.h at master · RMerl/asuswrt-merlin.ng

Third party firmware for Asus routers (newer codebase) - RMerl/asuswrt-merlin.ng

github.com

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

github.com

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

github.com

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

Did I mention... I really "Hate" IPv6... ;-)

 

[donnikhan]

Anyway, I feel bad begging @SomeWhereOverTheRainBow to generously write scripts in order to enable two ipv6 dns servers to be sent from the router to all devices so it would be great to have that functionality built in.