Diversion Diversion - the Router Ad-Blocker

[SamHNB]

Option 4 in ep restarts pixelserv-tls...
And since Entware is installed, you could use the /opt path:

/opt/etc/init.d/S80pixelserv-tls stop

And lastly: Any Syslog entries of interest?

Not sure, but I see this line which is the IP address of pioxelserv "lldpd[359]: removal request for address of xxx.xxx.xxx.3%10, but no knowledge of it"

Also, will changing NAT/Firewall rules from UI cause the interfaces to reconfigure or being dropped, as I see these lines preceding:

Sep 3 11:09:27 rc_service: httpds 251:notify_rc restart_firewall
Sep 3 11:09:28 nat: apply nat rules (/tmp/nat_rules_eth0_eth0)
Sep 3 11:09:28 custom_script: Running /jffs/scripts/firewall-start (args: eth0)
Sep 3 11:11:58 rc_service: httpds 251:notify_rc restart_net_and_phy
Sep 3 11:12:00 iTunes: daemon is stopped
Sep 3 11:12:00 FTP_Server: daemon is stopped
Sep 3 11:12:01 Samba_Server: smb daemon is stopped
Sep 3 11:12:01 kernel: gro disabled
Sep 3 11:12:01 dropbear[27598]: Exit (nimda): Terminated by signal
Sep 3 11:12:01 dropbear[214]: Early exit: Terminated by signal
Sep 3 11:12:01 dropbear[577]: Exit (nimda): Terminated by signal
Sep 3 11:12:03 lldpd[359]: removal request for address of xx.xx.xx.xx%4, but no knowledge of it
Sep 3 11:12:03 kernel: Attempt to kill tasklet from interrupt
Sep 3 11:12:03 kernel: device eth0 left promiscuous mode
Sep 3 11:12:03 kernel: br0: port 1(vlan1) entering forwarding state
Sep 3 11:12:03 kernel: device eth0 entered promiscuous mode
Sep 3 11:12:03 kernel: br0: topology change detected, propagating
Sep 3 11:12:03 kernel: br0: port 1(vlan1) entering forwarding state
Sep 3 11:12:03 kernel: br0: port 1(vlan1) entering forwarding state
Sep 3 11:12:06 watchdog: restart httpd
Sep 3 11:12:06 rc_service: watchdog 257:notify_rc stop_httpd
Sep 3 11:12:06 rc_service: waitting "restart_net_and_phy" via ...
Sep 3 11:12:07 nat: apply nat rules (/tmp/nat_rules_eth0_eth0)
Sep 3 11:12:08 kernel: br0: port 3(eth2) entering forwarding state
Sep 3 11:12:08 kernel: br0: port 2(eth1) entering forwarding state
Sep 3 11:12:08 kernel: br0: port 1(vlan1) entering forwarding state
Sep 3 11:12:08 kernel: device eth0 left promiscuous mode
Sep 3 11:12:08 kernel: device vlan1 left promiscuous mode
Sep 3 11:12:08 kernel: br0: port 1(vlan1) entering disabled state
Sep 3 11:12:08 kernel: device eth1 left promiscuous mode
Sep 3 11:12:08 kernel: br0: port 2(eth1) entering disabled state
Sep 3 11:12:08 kernel: device eth2 left promiscuous mode
Sep 3 11:12:08 kernel: br0: port 3(eth2) entering disabled state
Sep 3 11:12:08 lldpd[359]: removal request for address of xxx.xxx.xx.1%10, but no knowledge of it
Sep 3 11:12:08 lldpd[359]: removal request for address of xxx.xxx.xx.3%10, but no knowledge of it

 

[shark]

Hello,

I would like to ask if i use port 443 as the https lan port of my router web interface, it will cause any problems with diversion\pixelserver? Because a few days ago i did an initialize of my router, then after that i did the basic configuration(pppoe, wifi and etc), then i went to the administration page to enable https only for the web interface, but before that i changed the Ai Cloud web access port to 9443 instead of 443 and then the https lan port in the administration page to 443 instead of 8443... The problem is that after it, i tried to install diversion standard(with pixelserver) but i got an error saying that port 443 was being used by another application, so i changed the ports back, https lan port to 8443 and Ai cloud web access port back to 443 and i did not got an error anymore.

 

[Xentrk]

Hello,

I would like to ask if i use port 443 as the https lan port of my router web interface, it will cause any problems with diversion\pixelserver? Because a few days ago i did an initialize of my router, then after that i did the basic configuration(pppoe, wifi and etc), then i went to the administration page to enable https only for the web interface, for that i changed the Ai Cloud web access port do 9443 instead of 443 and the port of the https lan port in the administration page to 443 instead of 8443... The problem is that after it, i tried to install diversion standard(with pixelserver) but i got an error saying that port 443 was being used by another application, so i changed the ports back, https lan port to 8443 and Ai cloud web access port back do 443 and i did not got and error anymore.

I first tried the reinstall option of Diversion to fix the pixelserv-tls issues. I saw the same errors in the process of debugging. What fixed it is by first doing a complete uninstall of Diversion, followed by a fresh install of Diversion. Not sure if you tried that yet.

What was throwing me off is Diversion displays the IP assigned to pixelserv-tls and the version on the main menu, even though it's not running. Around the same time I was having the issues, I tried to run the config-webgui.sh script and it failed that pixelserv was not running. The log displayed this line

Sep  3 16:53:55 RT-AC88U-8248 pixelserv-tls[18481]: pixelserv-tls: v2.0.1 compiled: Mar  3 2018 11:05:58 options: 192.168.22.2 -l 4

So, I thought it had started okay. But these lines are what confirms it is running.

Sep  3 16:53:55 RT-AC88U-8248 pixelserv-tls[18481]: Listening on :192.168.22.2:80
Sep  3 16:53:55 RT-AC88U-8248 pixelserv-tls[18481]: Listening on :192.168.22.2:443

 

[dugaduga]

Weekly stats completed according to the log, nothing showed up under /stats. Ran it manually...
failed with:

Done The current stats are being compiled now.
This will take some time. If compiling fails,
check the stats.div.log in sf

What do you want to do? /opt/share/diversion/file/stats.div: .: line 62: can't open '/opt/share/diversion/.conf/email.conf'

had to create an empty email.conf and it worked

 

[M@rco]

I was about to do a feature request when I (yes, I actually RTFM before asking) noticed it's already part of Diversion, but it's (at least to me) a little gem, worth mentioning:

I use Diversion for parental controls as well, so I was hoping it would be possible to include a function to automagically change the blocking file during daytime to deny access to gambling, fakenews and porn but loosen the restictions somewhat when the kid goes to sleep. Because I'm a huge fan of ... ehrm... let's say fakenews. And guess what, it can be done easily by creating a cron job which runs

diversion fs

twice a day, to switch blocking files!

@thelonelycoder, you're a genius!

 

[thelonelycoder]

I was about to do a feature request when I (yes, I actually RTFM before asking) noticed it's already part of Diversion, but it's (at least to me) a little gem, worth mentioning:

I use Diversion for parental controls as well, so I was hoping it would be possible to include a function to automagically change the blocking file during daytime to deny access to gambling, fakenews and porn but loosen the restictions somewhat when the kid goes to sleep. Because I'm a huge fan of ... ehrm... let's say fakenews. And guess what, it can be done easily by creating a cron job which runs

diversion fs

twice a day, to switch blocking files!

@thelonelycoder, you're a genius!

I'm also a fan of news. An idea struck me. Two days of coding, testing/debugging later: The blocking file fast switch was born.

 

[elorimer]

I would like to ask if i use port 443 as the https lan port of my router web interface, it will cause any problems with diversion\pixelserver?

Pixelserv listens for https traffic on port 443 of the lan-side interface of the router by default. As you see, you will have an issue binding another service to the same port of the lan-side interface. Pixelserv doesn't bind to the wan-side interface, which is why you can have another service listening on that port on the wan-side. You could move pixelserv to another port, or move the web interface as you did.

It appears many people set up an OpenVPN server for TCP on port 443 rather than the default 1194, because in many client locations, all other traffic is blocked. I've found that to be true, although there is one location where I just can't form a connection. By default, OVPN binds to all interfaces, so it is listening on both the lan side and wan side on port 443. That creates the same problem. Since it seems kind of stupid to make an OVPN connection to the same network you are already on, you can use the local command to cause OVPN to only bind to the wan-side. That resolves the conflict with pixelserv. Another solution apparently is to use the port-share command, which causes OVPN when it is in TCP mode to pass traffic it doesn't recognize on to the other program. That seems like a kludge, and it doesn't work for UDP traffic, although I don't understand why you would use port 443 for UDP traffic, since you could stick with 1194. (I think it makes sense to set up the second server with UDP/1194/no compression, and the other for TCP/443/no compression, and then four client configurations for redirect/noredirect, but now I am in TL;DR territory.)

 

[Xentrk]

I'm also a fan of news. Two days of coding, testing/debugging later: The blocking file fast switch was born.

Nice work. Are there any other Easter eggs you are not telling us about?

 

[thelonelycoder]

Nice work. Are there any other Easter eggs you are not telling us about?

fs is in plain sight. In b under 1. Change composition and in the command-line options 'diversion help'
And I've bragged about it at least twice in the AB thread:
https://www.snbforums.com/threads/ab-solution-the-ad-blocking-solution.37511/page-167#post-425978
https://www.snbforums.com/threads/ab-solution-the-ad-blocking-solution.37511/page-163#post-418681

Heck, even the screenshots in post #1 show that it's there...

 

[tomsk]

I haven't had a play with this yet, but are there any limitations on the blocking files you can switch.. e.g is it possible to switch between two custom files, or a custom file and a standard file?

 

[thelonelycoder]

I haven't had a play with this yet, but are there any limitations on the blocking files you can switch.. e.g is it possible to switch between two custom files, or a custom file and a standard file?

Any combination is possible. There's no check if you 'accidently' select the same type or hosts files.

Diversion keeps a backup of each downloaded hosts file and wont redownload if the backup file is less than one day old.
So if you have one or several hosts files url's in both the primary and secondary blocking file type they are (or it is) only downloaded once.
You can check that by running a manual update of the blocking file(s).

 

[tomsk]

Any combination is possible. There's no check if you 'accidently' select the same type or hosts files.

Diversion keeps a backup of each downloaded hosts file and wont redownload if the backup file is less than one day old.
So if you have one or several hosts files url's in both the primary and secondary blocking file type they are (or it is) only downloaded once.
You can check that by running a manual update of the blocking file(s).

Works like a charm.......

 

[Jozek]

How to uninstall It?

 

[thelonelycoder]

How to uninstall It?

Look in d.

 

[Xentrk]

I had issues debugging my issues the other day. I discovered that the Diversion Main menu displays the pixelserv-tls IP and version even if pixelserv is not listening on the assigned ports. This led me to believe pixelserv-tls was operating normally.

I discovered this when trying to run the config-webgui.sh script and it failed on pixelserv-tls not running. Here is the code snip from config-webgui.sh that told me there was an issue with pixelserv-tls:

  [[ "$(/bin/ps | grep -v grep | grep -o pixelserv-tls)" = ""  || ! -x /opt/bin/pixelserv-tls ]] && \
      echo "You do not appear to have pixelserv-tls installed or running." &&  \
        exit 1

One way to duplicate the issue is to enter an invalid pixelserv-tls switch value e.g. -u 4

Thank you for looking into the concern.

 

[thelonelycoder]

I had issues debugging my issues the other day. I discovered that the Diversion Main menu displays the pixelserv-tls IP and version even if pixelserv is not listening on the assigned ports. This led me to believe pixelserv-tls was operating normally.

I discovered this when trying to run the config-webgui.sh script and it failed on pixelserv-tls not running. Here is the code snip from config-webgui.sh that told me there was an issue with pixelserv-tls:

  [[ "$(/bin/ps | grep -v grep | grep -o pixelserv-tls)" = ""  || ! -x /opt/bin/pixelserv-tls ]] && \
      echo "You do not appear to have pixelserv-tls installed or running." &&  \
        exit 1

One way to duplicate the issue is to enter an invalid pixelserv-tls switch value e.g. -u 4

Thank you for looking into the concern.

The only checks that pixelserv is running are during the installation, Re-install or Update of Diversion.
I was wary of those pixelserv not running posts, to be honest.

So far, that check built into the Diversion installer appears to be reliable. I have added it to the tests when the UI is opened and it will be included in the next (or first!) Diversion update.

 

[thelonelycoder]

I just found the reason why some had issues with dnscrypt (dnscrypt installer installed trough amtm or manually) when porting AB-Solution to Diversion.
Will be fixed in an update.

 

[Xentrk]

The only checks that pixelserv is running are during the installation, Re-install or Update of Diversion.
I was wary of those pixelserv not running posts, to be honest.

So far, that check built into the Diversion installer appears to be reliable. I have added it to the tests when the UI is opened and it will be included in the next (or first!) Diversion update.

Thank you for checking into it and implementing the pixelserv-tls check on the UI! Greatly appreciated.

 

[Xentrk]

This script is applicable for people who use Diversion and also use an OpenVPN Client. I made some updates now that AB-Solution has been rebranded to Diversion. This script will check for a conflict with the OpenVPN Client Accept DNS Configuration field. If the field is set to Exclusive, dnsmasq is bypassed which prevents Diversion from working.

curl "https://raw.githubusercontent.com/Xentrk/Asuswrt-Merlin-Linux-Shell-Scripts/master/x3mtek_Chk_ADNS.sh" -o /jffs/scripts/x3mtek_Chk_ADNS.sh && chmod +x /jffs/scripts/x3mtek_Chk_ADNS.sh && sh /jffs/scripts/x3mtek_Chk_ADNS.sh

 

[skeal]

This script is applicable for people who use Diversion and also use an OpenVPN Client. This script will check for a conflict with the OpenVPN Client Accept DNS Configuration field. If the field is set to Exclusive, dnsmasq is bypassed which prevents Diversion from working.

curl "https://raw.githubusercontent.com/Xentrk/Asuswrt-Merlin-Linux-Shell-Scripts/master/x3mtek_Chk_ADNS.sh" -o /jffs/scripts/x3mtek_Chk_ADNS.sh && chmod +x /jffs/scripts/x3mtek_Chk_ADNS.sh && sh /jffs/scripts/x3mtek_Chk_ADNS.sh

This works very well sir! Awesome!