What's new
  • 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!

@thelonelycoder can this be used to make sure dnsmasq with logging is correctly setup as not sure mine is?

Thanks :)
If you want to have logging enabled with no other benefits that Diversion offers, then installing Diversion would be overkill IMO.

Enabling Dnsmasq logging to a file in Asuswrt-Merlin is a simple matter of adding three lines and having a permanently plugged in USB device that is capable of holding the large log files Dnsmasq creates.
Be aware that the log file can grow to be very large, make sure you purge the content of the file regularily or do your own log rotation to only keep a weeks or so of log data.

See the Merlin wiki how to add a custom config file.
Basically, adding the following to file /jffs/configs/dnsmasq.conf.add will do all you need for starters:
Code:
log-async
log-queries
log-facility=/path/to/your/usb-device/dnsmasq.log
Be sure to have set a label for your USB device and using that as the path and not the device name (such as sda1, sdb1 etc) or else your log path may change after a reboot.
 
Is Diversion supposed to work with Vlans?

I have a main AC-RT68U router connected to a secondary AC-R68U acting just as AP. Since you cannot use guest networks properly when in AP mode, I created a vlan instead for the guest networks (using the same idea as here https://www.snbforums.com/threads/expand-the-guest-network-to-two-merlin-routers.61231/)

Basically all the packets from the devices connected to the guest networks on the AP are tagged vlan101 and using br1 on the main router, and the main router is using dnsmasq to assign dhcp addresses in the 192.168.20.x range (main addresses are 192.168.1.x) with
Code:
admin@RT-AC68U-7BA8:/tmp/home/root# cat /jffs/configs/dnsmasq.conf.add
interface=br1
dhcp-range=br1,192.168.20.3,192.168.20.149,255.255.255.0,86400s
dhcp-option=br1,3,192.168.20.1
dhcp-option=br1,6,192.168.20.1

and a change in iptables as follows
Code:
# Allow BR1 to access WAN
iptables -D FORWARD -i br1 -m state --state NEW -j ACCEPT >/dev/null 2>&1
iptables -I FORWARD -i br1 -m state --state NEW -j ACCEPT
# Prevent BR1 from accessing BR0 and vice versa
iptables -D FORWARD -i br1 -o br0 -m state --state NEW -j DROP >/dev/null 2>&1
iptables -I FORWARD -i br1 -o br0 -m state --state NEW -j DROP
iptables -D FORWARD -i br0 -o br1 -m state --state NEW -j DROP >/dev/null 2>&1
iptables -I FORWARD -i br0 -o br1 -m state --state NEW -j DROP
#
iptables -D INPUT -i br1 -m state --state NEW -j DROP >/dev/null 2>&1
iptables -I INPUT -i br1 -m state --state NEW -j DROP
# Allow DNSMASQ to distribute IP addresses for br1.
iptables -D INPUT -i br1 -p tcp --dport 53 -j ACCEPT >/dev/null 2>&1
iptables -I INPUT -i br1 -p tcp --dport 53 -j ACCEPT
# Allow DNSMASQ to distribute IP addresses for br1.
iptables -D INPUT -i br1 -p udp -m multiport --dport 53,67 -j ACCEPT >/dev/null 2>&1
iptables -I INPUT -i br1 -p udp -m multiport --dport 53,67 -j ACCEPT

I have to admit that the IPTABLES part is a bit of a black magic to me. I understand everything else just fine, but I simply copied the IPTABLES part (and I also saw someone else using EBTABLES instead). I was also surprised to see that the devices on the guest network also use Diversion and Diversion blocks everything in my block list even for guest devices

For a while everything worked just fine, but I started noticing that some webpages are not loading properly when on the guest network. Disabling Diversion then re-enabling it, seems to fix things for a while. But I don't know if it's because of Diversion or simply because disabling and re-enabling Diversion also restarts a few services

Is my setup even supposed to work, given that Diversion also uses dnsmasq? I do see in dnsmasq.log all the requests coming from the clients on 192.168.20.x, and those seem to be redirected properly or blocked as appropriate... Is there anything I can to to help troubleshoot the connectivity problems?
 
Is Diversion supposed to work with Vlans?

I have a main AC-RT68U router connected to a secondary AC-R68U acting just as AP. Since you cannot use guest networks properly when in AP mode, I created a vlan instead for the guest networks (using the same idea as here https://www.snbforums.com/threads/expand-the-guest-network-to-two-merlin-routers.61231/)

Basically all the packets from the devices connected to the guest networks on the AP are tagged vlan101 and using br1 on the main router, and the main router is using dnsmasq to assign dhcp addresses in the 192.168.20.x range (main addresses are 192.168.1.x) with
Code:
admin@RT-AC68U-7BA8:/tmp/home/root# cat /jffs/configs/dnsmasq.conf.add
interface=br1
dhcp-range=br1,192.168.20.3,192.168.20.149,255.255.255.0,86400s
dhcp-option=br1,3,192.168.20.1
dhcp-option=br1,6,192.168.20.1

and a change in iptables as follows
Code:
# Allow BR1 to access WAN
iptables -D FORWARD -i br1 -m state --state NEW -j ACCEPT >/dev/null 2>&1
iptables -I FORWARD -i br1 -m state --state NEW -j ACCEPT
# Prevent BR1 from accessing BR0 and vice versa
iptables -D FORWARD -i br1 -o br0 -m state --state NEW -j DROP >/dev/null 2>&1
iptables -I FORWARD -i br1 -o br0 -m state --state NEW -j DROP
iptables -D FORWARD -i br0 -o br1 -m state --state NEW -j DROP >/dev/null 2>&1
iptables -I FORWARD -i br0 -o br1 -m state --state NEW -j DROP
#
iptables -D INPUT -i br1 -m state --state NEW -j DROP >/dev/null 2>&1
iptables -I INPUT -i br1 -m state --state NEW -j DROP
# Allow DNSMASQ to distribute IP addresses for br1.
iptables -D INPUT -i br1 -p tcp --dport 53 -j ACCEPT >/dev/null 2>&1
iptables -I INPUT -i br1 -p tcp --dport 53 -j ACCEPT
# Allow DNSMASQ to distribute IP addresses for br1.
iptables -D INPUT -i br1 -p udp -m multiport --dport 53,67 -j ACCEPT >/dev/null 2>&1
iptables -I INPUT -i br1 -p udp -m multiport --dport 53,67 -j ACCEPT

I have to admit that the IPTABLES part is a bit of a black magic to me. I understand everything else just fine, but I simply copied the IPTABLES part (and I also saw someone else using EBTABLES instead). I was also surprised to see that the devices on the guest network also use Diversion and Diversion blocks everything in my block list even for guest devices

For a while everything worked just fine, but I started noticing that some webpages are not loading properly when on the guest network. Disabling Diversion then re-enabling it, seems to fix things for a while. But I don't know if it's because of Diversion or simply because disabling and re-enabling Diversion also restarts a few services

Is my setup even supposed to work, given that Diversion also uses dnsmasq? I do see in dnsmasq.log all the requests coming from the clients on 192.168.20.x, and those seem to be redirected properly or blocked as appropriate... Is there anything I can to to help troubleshoot the connectivity problems?
Try moving your INPUT ... DROP commands AFTER the INPUT ... ACCEPT commands.
 
Try moving your INPUT ... DROP commands AFTER the INPUT ... ACCEPT commands.
I tried, but I think that in that case it drops every TCP packet, at least according to
Code:
admin@RT-AC68U-7BA8:/tmp/home/root# iptables -L -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
  448 47229 DROP       all  --  br1    any     anywhere             anywhere             state NEW
   19  1824 ACCEPT     udp  --  br1    any     anywhere             anywhere             multiport dports domain,bootps
    0     0 ACCEPT     tcp  --  br1    any     anywhere             anywhere             tcp dpt:domain

To be clear, I tried:
Code:
# Allow BR1 to access WAN
iptables -D FORWARD -i br1 -m state --state NEW -j ACCEPT >/dev/null 2>&1
iptables -I FORWARD -i br1 -m state --state NEW -j ACCEPT
# Prevent BR1 from accessing BR0 and vice versa
iptables -D FORWARD -i br1 -o br0 -m state --state NEW -j DROP >/dev/null 2>&1
iptables -I FORWARD -i br1 -o br0 -m state --state NEW -j DROP
iptables -D FORWARD -i br0 -o br1 -m state --state NEW -j DROP >/dev/null 2>&1
iptables -I FORWARD -i br0 -o br1 -m state --state NEW -j DROP
# Allow DNSMASQ to distribute IP addresses for br1.
iptables -D INPUT -i br1 -p tcp --dport 53 -j ACCEPT >/dev/null 2>&1
iptables -I INPUT -i br1 -p tcp --dport 53 -j ACCEPT
# Allow DNSMASQ to distribute IP addresses for br1.
iptables -D INPUT -i br1 -p udp -m multiport --dport 53,67 -j ACCEPT >/dev/null 2>&1
iptables -I INPUT -i br1 -p udp -m multiport --dport 53,67 -j ACCEPT
#
iptables -D INPUT -i br1 -m state --state NEW -j DROP >/dev/null 2>&1
iptables -I INPUT -i br1 -m state --state NEW -j DROP
and in that case I can't even get an IP address on the guest network/vlan
 
I tried, but I think that in that case it drops every TCP packet, at least according to
Code:
admin@RT-AC68U-7BA8:/tmp/home/root# iptables -L -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
  448 47229 DROP       all  --  br1    any     anywhere             anywhere             state NEW
   19  1824 ACCEPT     udp  --  br1    any     anywhere             anywhere             multiport dports domain,bootps
    0     0 ACCEPT     tcp  --  br1    any     anywhere             anywhere             tcp dpt:domain

To be clear, I tried:
Code:
# Allow BR1 to access WAN
iptables -D FORWARD -i br1 -m state --state NEW -j ACCEPT >/dev/null 2>&1
iptables -I FORWARD -i br1 -m state --state NEW -j ACCEPT
# Prevent BR1 from accessing BR0 and vice versa
iptables -D FORWARD -i br1 -o br0 -m state --state NEW -j DROP >/dev/null 2>&1
iptables -I FORWARD -i br1 -o br0 -m state --state NEW -j DROP
iptables -D FORWARD -i br0 -o br1 -m state --state NEW -j DROP >/dev/null 2>&1
iptables -I FORWARD -i br0 -o br1 -m state --state NEW -j DROP
# Allow DNSMASQ to distribute IP addresses for br1.
iptables -D INPUT -i br1 -p tcp --dport 53 -j ACCEPT >/dev/null 2>&1
iptables -I INPUT -i br1 -p tcp --dport 53 -j ACCEPT
# Allow DNSMASQ to distribute IP addresses for br1.
iptables -D INPUT -i br1 -p udp -m multiport --dport 53,67 -j ACCEPT >/dev/null 2>&1
iptables -I INPUT -i br1 -p udp -m multiport --dport 53,67 -j ACCEPT
#
iptables -D INPUT -i br1 -m state --state NEW -j DROP >/dev/null 2>&1
iptables -I INPUT -i br1 -m state --state NEW -j DROP
and in that case I can't even get an IP address on the guest network/vlan
Sorry, my mistake. I missed that you were inserting with -I instead of appending with -A. Put it back the way you had and post the iptables -nvL again.
 
Sorry, my mistake. I missed that you were inserting with -I instead of appending with -A. Put it back the way you had and post the iptables -nvL again.
Here it is:
Code:
admin@RT-AC68U-7BA8:/tmp/home/root# iptables -nvL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
  179 13288 ACCEPT     udp  --  br1    *       0.0.0.0/0            0.0.0.0/0            multiport dports 53,67
    0     0 ACCEPT     tcp  --  br1    *       0.0.0.0/0            0.0.0.0/0            tcp dpt:53
  639 52485 DROP       all  --  br1    *       0.0.0.0/0            0.0.0.0/0            state NEW
    0     0 INPUT_PING  icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 8
 6001  675K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
  149 11372 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state INVALID
 1323  370K PTCSRVWAN  all  --  !br0   *       0.0.0.0/0            0.0.0.0/0
 2020  455K PTCSRVLAN  all  --  br0    *       0.0.0.0/0            0.0.0.0/0
 2020  455K ACCEPT     all  --  br0    *       0.0.0.0/0            0.0.0.0/0            state NEW
 1176  340K ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0            state NEW
  147 29685 OVPN       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state NEW
    4  1342 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp spt:67 dpt:68
    0     0 INPUT_ICMP  icmp --  *      *       0.0.0.0/0            0.0.0.0/0
  143 28343 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DROP       all  --  br0    br1     0.0.0.0/0            0.0.0.0/0            state NEW
    0     0 DROP       all  --  br1    br0     0.0.0.0/0            0.0.0.0/0            state NEW
  305 72848 ACCEPT     all  --  br1    *       0.0.0.0/0            0.0.0.0/0            state NEW
40107   31M ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
   35  2873 other2wan  all  --  !br0   eth0    0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     all  --  br0    br0     0.0.0.0/0            0.0.0.0/0
   14  1344 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state INVALID
  254 66882 NSFW       all  --  *      *       0.0.0.0/0            0.0.0.0/0
  254 66882 ACCEPT     all  --  br0    *       0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate DNAT
    0     0 OVPN       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state NEW
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain OUTPUT (policy ACCEPT 9197 packets, 9899K bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain ACCESS_RESTRICTION (0 references)
 pkts bytes target     prot opt in     out     source               destination

Chain DNSFILTER_DOT (0 references)
 pkts bytes target     prot opt in     out     source               destination

Chain FUPNP (0 references)
 pkts bytes target     prot opt in     out     source               destination

Chain INPUT_ICMP (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 RETURN     icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 8
    0     0 RETURN     icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 13
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0

Chain INPUT_PING (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DROP       icmp --  eth0   *       0.0.0.0/0            0.0.0.0/0

Chain NSFW (1 references)
 pkts bytes target     prot opt in     out     source               destination

Chain OVPN (2 references)
 pkts bytes target     prot opt in     out     source               destination

Chain PControls (0 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain PTCSRVLAN (1 references)
 pkts bytes target     prot opt in     out     source               destination

Chain PTCSRVWAN (1 references)
 pkts bytes target     prot opt in     out     source               destination

Chain SECURITY (0 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 RETURN     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcpflags: 0x17/0x02 limit: avg 1/sec burst 5
    0     0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcpflags: 0x17/0x02
    0     0 RETURN     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcpflags: 0x17/0x04 limit: avg 1/sec burst 5
    0     0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcpflags: 0x17/0x04
    0     0 RETURN     icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 8 limit: avg 1/sec burst 5
    0     0 DROP       icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 8
    0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain default_block (0 references)
 pkts bytes target     prot opt in     out     source               destination

Chain logaccept (0 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            state NEW LOG flags 7 level 4 prefix "ACCEPT "
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain logdrop (0 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            state NEW LOG flags 7 level 4 prefix "DROP "
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain other2wan (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 RETURN     all  --  tun+   *       0.0.0.0/0            0.0.0.0/0
   35  2873 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0
admin@RT-AC68U-7BA8:/tmp/home/root#
Appreciate the help...
 
Here it is:
Code:
admin@RT-AC68U-7BA8:/tmp/home/root# iptables -nvL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
  179 13288 ACCEPT     udp  --  br1    *       0.0.0.0/0            0.0.0.0/0            multiport dports 53,67
    0     0 ACCEPT     tcp  --  br1    *       0.0.0.0/0            0.0.0.0/0            tcp dpt:53
  639 52485 DROP       all  --  br1    *       0.0.0.0/0            0.0.0.0/0            state NEW
    0     0 INPUT_PING  icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 8
 6001  675K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
  149 11372 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state INVALID
 1323  370K PTCSRVWAN  all  --  !br0   *       0.0.0.0/0            0.0.0.0/0
 2020  455K PTCSRVLAN  all  --  br0    *       0.0.0.0/0            0.0.0.0/0
 2020  455K ACCEPT     all  --  br0    *       0.0.0.0/0            0.0.0.0/0            state NEW
 1176  340K ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0            state NEW
  147 29685 OVPN       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state NEW
    4  1342 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp spt:67 dpt:68
    0     0 INPUT_ICMP  icmp --  *      *       0.0.0.0/0            0.0.0.0/0
  143 28343 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DROP       all  --  br0    br1     0.0.0.0/0            0.0.0.0/0            state NEW
    0     0 DROP       all  --  br1    br0     0.0.0.0/0            0.0.0.0/0            state NEW
  305 72848 ACCEPT     all  --  br1    *       0.0.0.0/0            0.0.0.0/0            state NEW
40107   31M ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
   35  2873 other2wan  all  --  !br0   eth0    0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     all  --  br0    br0     0.0.0.0/0            0.0.0.0/0
   14  1344 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state INVALID
  254 66882 NSFW       all  --  *      *       0.0.0.0/0            0.0.0.0/0
  254 66882 ACCEPT     all  --  br0    *       0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate DNAT
    0     0 OVPN       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state NEW
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain OUTPUT (policy ACCEPT 9197 packets, 9899K bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain ACCESS_RESTRICTION (0 references)
 pkts bytes target     prot opt in     out     source               destination

Chain DNSFILTER_DOT (0 references)
 pkts bytes target     prot opt in     out     source               destination

Chain FUPNP (0 references)
 pkts bytes target     prot opt in     out     source               destination

Chain INPUT_ICMP (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 RETURN     icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 8
    0     0 RETURN     icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 13
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0

Chain INPUT_PING (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DROP       icmp --  eth0   *       0.0.0.0/0            0.0.0.0/0

Chain NSFW (1 references)
 pkts bytes target     prot opt in     out     source               destination

Chain OVPN (2 references)
 pkts bytes target     prot opt in     out     source               destination

Chain PControls (0 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain PTCSRVLAN (1 references)
 pkts bytes target     prot opt in     out     source               destination

Chain PTCSRVWAN (1 references)
 pkts bytes target     prot opt in     out     source               destination

Chain SECURITY (0 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 RETURN     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcpflags: 0x17/0x02 limit: avg 1/sec burst 5
    0     0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcpflags: 0x17/0x02
    0     0 RETURN     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcpflags: 0x17/0x04 limit: avg 1/sec burst 5
    0     0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcpflags: 0x17/0x04
    0     0 RETURN     icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 8 limit: avg 1/sec burst 5
    0     0 DROP       icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 8
    0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain default_block (0 references)
 pkts bytes target     prot opt in     out     source               destination

Chain logaccept (0 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            state NEW LOG flags 7 level 4 prefix "ACCEPT "
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain logdrop (0 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            state NEW LOG flags 7 level 4 prefix "DROP "
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain other2wan (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 RETURN     all  --  tun+   *       0.0.0.0/0            0.0.0.0/0
   35  2873 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0
admin@RT-AC68U-7BA8:/tmp/home/root#
Appreciate the help...
Is Diversion using Pixelserv IP on br0: pixelserv-tls? Or just using 0.0.0.0 as blocking IP? I’m just about out of my league here, so don’t believe everything you read on the Internet. :oops:

If you enable logging in Diversion, do you see traffic logged from your br1 clients?
 
Is Diversion using Pixelserv IP on br0: pixelserv-tls? Or just using 0.0.0.0 as blocking IP? I’m just about out of my league here, so don’t believe everything you read on the Internet. :oops:

If you enable logging in Diversion, do you see traffic logged from your br1 clients?
Yes, I'm using pixelserv and I think it's on br0, since its IP is 192.168.1.2 (main router DHCP addresses)

I do see the traffic from devices on br1, e.g.
Code:
May 27 14:36:58 dnsmasq-dhcp[1159]: DHCPDISCOVER(br1) c2:96:da:80:d1:60
May 27 14:36:58 dnsmasq-dhcp[1159]: DHCPOFFER(br1) 192.168.20.112 c2:96:da:80:d1:60
May 27 14:36:58 dnsmasq-dhcp[1159]: DHCPREQUEST(br1) 192.168.20.112 c2:96:da:80:d1:60
May 27 14:36:58 dnsmasq-dhcp[1159]: DHCPACK(br1) 192.168.20.112 c2:96:da:80:d1:60

and

May 27 14:32:38 dnsmasq[1159]: query[A] www.ups.com from 192.168.1.126
May 27 14:32:38 dnsmasq[1159]: cached www.ups.com is <CNAME>
May 27 14:32:38 dnsmasq[1159]: cached ev.ups.com.akadns.net is <CNAME>
May 27 14:32:38 dnsmasq[1159]: cached ev1.ups.com.akadns.net is <CNAME>
May 27 14:32:38 dnsmasq[1159]: cached ev2b.ups.com.edgekey.net is <CNAME>
May 27 14:32:38 dnsmasq[1159]: cached ev2b.ups.com.edgekey.net.globalredir.akadns.net is <CNAME>
May 27 14:32:38 dnsmasq[1159]: forwarded www.ups.com to 8.8.8.8
May 27 14:32:38 dnsmasq[1159]: reply clients3.google.com is <CNAME>
May 27 14:32:38 dnsmasq[1159]: reply clients.l.google.com is 216.58.217.46
May 27 14:32:38 dnsmasq[1159]: reply www.ups.com is <CNAME>
May 27 14:32:38 dnsmasq[1159]: reply ev.ups.com.akadns.net is <CNAME>
May 27 14:32:38 dnsmasq[1159]: reply ev1.ups.com.akadns.net is <CNAME>
May 27 14:32:38 dnsmasq[1159]: reply ev2b.ups.com.edgekey.net is <CNAME>
May 27 14:32:38 dnsmasq[1159]: reply ev2b.ups.com.edgekey.net.globalredir.akadns.net is <CNAME>
May 27 14:32:38 dnsmasq[1159]: reply e13626.a.akamaiedge.net is 23.45.229.189

The weird thing is that if I use the "follow dnsmasq" feature in diversions, and I try to filter by the br1 IP addresses (192.168.20.x), I get
Code:
 Enter device IP to filter by  [q=Quit] 192.168.20.112

  ✖  192.168.20.112 is not a router address
because Deviation doesn't know about my alternate DHCP on br1

At this point I'm positive that my problems are caused by a weird interaction between Diversion and vlans (to be clear: I'm not blaming Diversion, I'm sure I'm doing something that was not designed for). If I disable Diversion, all problems disappear. With Diversion enabled, some things work just fine (e.g. Outlook email and the speedtest app in my Android phone, all my media devices streaming, etc) but other, like a simple browsing of the ups.com page from Chrome in Android takes forever to refresh or sometimes doesn't even load (even if I can see the event in the dnsmasq.log, as per above. 192.168.20.112 is my Android phone and I see a lot of activity from it, both the one that works like Outlook and the one that doesn't like Chrome)

So I'm sure you are onto something with your question...
 
Yes, I'm using pixelserv and I think it's on br0, since its IP is 192.168.1.2 (main router DHCP addresses)

I do see the traffic from devices on br1, e.g.
Code:
May 27 14:36:58 dnsmasq-dhcp[1159]: DHCPDISCOVER(br1) c2:96:da:80:d1:60
May 27 14:36:58 dnsmasq-dhcp[1159]: DHCPOFFER(br1) 192.168.20.112 c2:96:da:80:d1:60
May 27 14:36:58 dnsmasq-dhcp[1159]: DHCPREQUEST(br1) 192.168.20.112 c2:96:da:80:d1:60
May 27 14:36:58 dnsmasq-dhcp[1159]: DHCPACK(br1) 192.168.20.112 c2:96:da:80:d1:60

and

May 27 14:32:38 dnsmasq[1159]: query[A] www.ups.com from 192.168.1.126
May 27 14:32:38 dnsmasq[1159]: cached www.ups.com is <CNAME>
May 27 14:32:38 dnsmasq[1159]: cached ev.ups.com.akadns.net is <CNAME>
May 27 14:32:38 dnsmasq[1159]: cached ev1.ups.com.akadns.net is <CNAME>
May 27 14:32:38 dnsmasq[1159]: cached ev2b.ups.com.edgekey.net is <CNAME>
May 27 14:32:38 dnsmasq[1159]: cached ev2b.ups.com.edgekey.net.globalredir.akadns.net is <CNAME>
May 27 14:32:38 dnsmasq[1159]: forwarded www.ups.com to 8.8.8.8
May 27 14:32:38 dnsmasq[1159]: reply clients3.google.com is <CNAME>
May 27 14:32:38 dnsmasq[1159]: reply clients.l.google.com is 216.58.217.46
May 27 14:32:38 dnsmasq[1159]: reply www.ups.com is <CNAME>
May 27 14:32:38 dnsmasq[1159]: reply ev.ups.com.akadns.net is <CNAME>
May 27 14:32:38 dnsmasq[1159]: reply ev1.ups.com.akadns.net is <CNAME>
May 27 14:32:38 dnsmasq[1159]: reply ev2b.ups.com.edgekey.net is <CNAME>
May 27 14:32:38 dnsmasq[1159]: reply ev2b.ups.com.edgekey.net.globalredir.akadns.net is <CNAME>
May 27 14:32:38 dnsmasq[1159]: reply e13626.a.akamaiedge.net is 23.45.229.189

The weird thing is that if I use the "follow dnsmasq" feature in diversions, and I try to filter by the br1 IP addresses (192.168.20.x), I get
Code:
 Enter device IP to filter by  [q=Quit] 192.168.20.112

  ✖  192.168.20.112 is not a router address
because Deviation doesn't know about my alternate DHCP on br1

At this point I'm positive that my problems are caused by a weird interaction between Diversion and vlans (to be clear: I'm not blaming Diversion, I'm sure I'm doing something that was not designed for). If I disable Diversion, all problems disappear. With Diversion enabled, some things work just fine (e.g. Outlook email and the speedtest app in my Android phone, all my media devices streaming, etc) but other, like a simple browsing of the ups.com page from Chrome in Android takes forever to refresh or sometimes doesn't even load (even if I can see the event in the dnsmasq.log, as per above. 192.168.20.112 is my Android phone and I see a lot of activity from it, both the one that works like Outlook and the one that doesn't like Chrome)

So I'm sure you are onto something with your question...
If you disable Pixerlserv in ep in Diversion, you can avoid accessing the 192.168.1.2 from br1, but I'm still not clear if your dns requests are getting through since you only showed a log of a br0 client.
 
I will try disabling pixelserv tomorrow.

I can confirm that disabling pixelserv-tls solves my problems. And now I think I understand why some pages and some services loaded fast, others either didn't load or loaded very slowly (waiting for pixelserv and timing out, probably). Thanks so much for the suggestion

That is obviously great news for me, since I can live without pixelserv-tls, but could not live anymore without Diversion :)

Is there a way to "magically" make pixelserv-tls work again using IPTABLES to let traffic from br1 to 192.168.1.2 and back flow? I'm sure that I can read up on IPTABLES and figure out myself the proper magic incantation, but I would highly appreciate a quick pointer to save me from spousal anger (every time I mess up something and reboot the routers, the wife isn't exactly thrilled. Cabin fever from Covid19 seems to shorten the fuse :)).

Here's my current set of IPTABLES rules
Code:
# Allow BR1 to access WAN
iptables -D FORWARD -i br1 -m state --state NEW -j ACCEPT >/dev/null 2>&1
iptables -I FORWARD -i br1 -m state --state NEW -j ACCEPT
# Prevent BR1 from accessing BR0 and vice versa
iptables -D FORWARD -i br1 -o br0 -m state --state NEW -j DROP >/dev/null 2>&1
iptables -I FORWARD -i br1 -o br0 -m state --state NEW -j DROP
iptables -D FORWARD -i br0 -o br1 -m state --state NEW -j DROP >/dev/null 2>&1
iptables -I FORWARD -i br0 -o br1 -m state --state NEW -j DROP
#
iptables -D INPUT -i br1 -m state --state NEW -j DROP >/dev/null 2>&1
iptables -I INPUT -i br1 -m state --state NEW -j DROP
# Allow DNSMASQ to distribute IP addresses for br1.
iptables -D INPUT -i br1 -p tcp --dport 53 -j ACCEPT >/dev/null 2>&1
iptables -I INPUT -i br1 -p tcp --dport 53 -j ACCEPT
# Allow DNSMASQ to distribute IP addresses for br1.
iptables -D INPUT -i br1 -p udp -m multiport --dport 53,67 -j ACCEPT >/dev/null 2>&1
iptables -I INPUT -i br1 -p udp -m multiport --dport 53,67 -j ACCEPT

I'm pretty sure I would need a FORWARD-ACCEPT rule from br1 to br0 with source anywhere and destination 192.168.1.2 that executes before the FORWARD-DROP rule blocking all br1 to br0 traffic, but I have no idea if I also need something in the INPUT chain.
 
Last edited:
I'm pretty sure I would need a FORWARD-ACCEPT rule from br1 to br0 with source anywhere and destination 192.168.1.2 that executes before the FORWARD-DROP rule blocking all br1 to br0 traffic, but I have no idea if I also need something in the INPUT chain
See if something simple works only in the INPUT chain:
Code:
iptables -I INPUT -i br1 -d 192.168.1.2/32 -p tcp -m multiport --dport 80,443 -j ACCEPT
 
See if something simple works only in the INPUT chain:
Code:
iptables -I INPUT -i br1 -d 192.168.1.2/32 -p tcp -m multiport --dport 80,443 -j ACCEPT
Thanks for doing my homework!

It kinda helped: with just the INPUT statement above, I can browse webpages without problems and everything works (so, actually, much better than "kinda works" :)). But instead of the neat "1 transparent pixel" on the webpages I browse, I get the ugly "grey broken link box" on the webpages. Granted, 90% of the times, IoT devices do not care about that, but from time to time I need to chromecast or Airplay to my smart TV (on the guest, isolated network) and my devices are also on the guest network in that case, grey boxes and all.

So I also needed to add one more rule:
Code:
 iptables -I FORWARD -i br1 -d 192.168.1.2/32 -p tcp -m multiport --dport 80,443 -j ACCEPT
And with that, the webpages can actually reach pixelsrv-tls and get the neat 1 pixel filler. Exactly the same as your rule, just for the FORWARD chain. Awesome

As far as I can tell, those two ACCEPT rules should not expose the rest of the network to any risk, so I finally have an isolated guest network with full Diversion and pixelserv-tls support.

Might be worth adding it to the Diversion documentation under "using Diversion in vlans". Not sure how many people will need it, but I could not find anything about it

Once again, thanks everyone for the help, I love this community
 
I think we can safely say that YouTube ad blocking does not really work (impossible to do?). I've had the feature on for weeks, and I keep seeing video ads and repeats of the same video ads over and over again. I'm not a coder, so I'm not coming at this from that angle (i.e. I'm not criticizing or complaining), but just stating a bald fact from the end-user position.

On the other hand, Diversion's ad blocking is a true wonder!

Anton
 
I think we can safely say that YouTube ad blocking does not really work (impossible to do?). I've had the feature on for weeks, and I keep seeing video ads and repeats of the same video ads over and over again. I'm not a coder, so I'm not coming at this from that angle (i.e. I'm not criticizing or complaining), but just stating a bald fact from the end-user position.

On the other hand, Diversion's ad blocking is a true wonder!

Anton
Same experience here. Ended up disabling it and going back to uBlock Origin.

Appreciate the effort though of course, and hoping it becomes foolproof in the future.
 
I highly recommend you looking at whitelisted domains from links for this github,
https://raw.githubusercontent.com/anudeepND/whitelist/master/domains/referral-sites.txt
https://raw.githubusercontent.com/anudeepND/whitelist/master/domains/whitelist.txt

and adding them with
nano /opt/share/diversion/list/whitelist*
copy and paste
run diversion el options for whitelist sort and verify, then process.

the whitelist above usually fixes things that get broken from ad-blockers.

Thank you
 
I think we can safely say that YouTube ad blocking does not really work (impossible to do?). I've had the feature on for weeks, and I keep seeing video ads and repeats of the same video ads over and over again. I'm not a coder, so I'm not coming at this from that angle (i.e. I'm not criticizing or complaining), but just stating a bald fact from the end-user position.

On the other hand, Diversion's ad blocking is a true wonder!

Anton
It's not 100% effective but it eliminates many annoying ads. I can live with it.
 
It's not 100% effective but it eliminates many annoying ads. I can live with it.
It seems to break YouTube for me a lot.
Today a video through the YouTube app wouldn't load, and it seemed to constantly try to load an advertisement but failing, so I ended up in an endless loop. :(
On desktop I seem to get video loading failures as well all the time.
So yeah, it does block but YouTube then seems to break the playback half the time.
 
Pixelserv doing nothing?

At my In-Laws' house, new Asus router. Current uptime, 6 days:

--------
req 105 total # of requests (HTTP, HTTPS, success, failure etc)
avg 90 bytes average size of requests
rmx 314 bytes largest size of request(s)
tav 4 ms average processing time (per request)
tmx 9 ms longest processing time (per request)


slh 0 # of accepted HTTPS requests
slm 0 # of rejected HTTPS requests (missing certificate)
sle 0 # of rejected HTTPS requests (certificate available but not usable)
slc 0 # of dropped HTTPS requests (client disconnect without sending any request)
slu 0 # of dropped HTTPS requests (other TLS handshake errors)
------

Can confirm lots of "Cannot connect to server" boxes where the ads should be. ca.crt imported on relevant devices.

Thoughts??
 
I've pushed a Diversion update, no version change

- NEW : Option to enable the Diversion WebUI beta in d.
- CHANGED: Dnsmasq and pixelserv-tls operation functions to make them compatible with the new WebUI functions.

This first WebUI beta version is limited in its ability but fully functional. I need some feedback if things work as intended on a broader range of routers.
The Home page with its general settings is of most interest to me, while the Test pages are solely there to test the page switching function I came up with to outmaneuver the limitation of the firmware.
I tested this on my newer Merlin routers and the trusted RT-AC66U on Johns fork.

Please report inconsistencies and errors. And enjoy this first release of a GUI for Diversion :)

Use u to update
 
Last edited:

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!

Staff online

Top