Diversion Diversion - the Router Ad-Blocker

[thelonelycoder]

Is your IP 192.168.1.20 reserved for pixelserv -tls in your LAN DHCP Server settings? Just asking because default value is 192.168.1.2

Diversion would prevent setting an IP that is within the set DHCP IP pool. But then, one may change the pool starting and ending address after the Diversion installation. Would be a classical PEBKAC error.

 

[Mutzli]

That's was my thought that he might have changed the pool starting address back to .2 from .21
(edited to change from .1)

 

[DonnyJohnny]

Hi,

I would greatly appreciate it if some could help me figure out why Pixelserv-tls doesn't seem to work on my router.
I have Diversion 4.1.4 with pixelserv-tls 2.2.1 installed and running:
View attachment 19379

I have also generates the Pixelserv CA certificate and I have installed it in the Windows Trusted cert store.

But the servstats page always show very little number of requests and many zeroes.

Any help is much appreciated, thank you.

I once have this issue. Maybe you have adblock/ublock extension/add-on in your web browser. u may need to disable it so that the dns queries will go thru diversion.

 

[thelonelycoder]

That's was my thought that he might have changed the pool starting address back to .1 from .21

That would be .2, actually

 

[Delusion]

Again, the "Wan: Use local caching DNS server as system resolver" is only set during installation. A Diversion update does not check this and other settings.

I don't understand. When I installed Diversion 4.1.4 it changed "Wan: Use local caching DNS server as system resolver (default: No)" from No to Yes. But then it didn't change it back to No (I have issues when it is set to Yes) . Then I set it to No and decided to try Pixelserv , so I did an upgrade to Standard edition and It changed "Wan: Use local caching DNS server as system resolver (default: No)" to Yes during the upgrade . So I had to change it to No .

Here is an example of what happened when after Diversion was upgraded and set use local caching was set to YES ( I ran update on blacklist in Diversion):
Warning: Transient problem: timeout Will retry in 1 seconds. 3 retries left.
Warning: Transient problem: timeout Will retry in 2 seconds. 2 retries left.
Warning: Transient problem: timeout Will retry in 4 seconds. 1 retries left.

I had to go to tools and change it back to No so that the green connection icon in WebUi will turn green (it was gray as if disconnected ) and show Connected .
So... Is Local caching in tools ->other setting needs to be set to Yes or to No ? because Yes causes issues.
If Diversion set it to Yes only for installation , I have no problem set it to No but if Diversion needs it to be set to Yes to work as Intended then Its a problem for me :\

 

[thelonelycoder]

I don't understand. When I installed Diversion 4.1.4 it changed "Wan: Use local caching DNS server as system resolver (default: No)" from No to Yes. But then it didn't change it back to No (I have issues when it is set to Yes) . Then I set it to No and decided to try Pixelserv , so I did an upgrade to Standard edition and It changed "Wan: Use local caching DNS server as system resolver (default: No)" to Yes during the upgrade . So I had to change it to No .

Here is an example of what happened when after Diversion was upgraded and set use local caching was set to YES ( I ran update on blacklist in Diversion):
Warning: Transient problem: timeout Will retry in 1 seconds. 3 retries left.
Warning: Transient problem: timeout Will retry in 2 seconds. 2 retries left.
Warning: Transient problem: timeout Will retry in 4 seconds. 1 retries left.

I had to go to tools and change it back to No so that the green connection icon in WebUi will turn green (it was gray as if disconnected ) and show Connected .
So... Is Local caching in tools ->other setting needs to be set to Yes or to No ? because Yes causes issues.
If Diversion set it to Yes only for installation , I have no problem set it to No but if Diversion needs it to be set to Yes to work as Intended then Its a problem for me :\

I'll double check my logic when installing/upgrading.

No matter what, if DNS queries from LAN clients go anywhere else than the local Dnsmasq then Diversion has nothing to do and wont be able to do its job.

 

[nick_max]

Is your IP 192.168.1.20 reserved for pixelserv -tls in your LAN DHCP Server settings? Just asking because default value is 192.168.1.2

My DHCP reservation is from 1.2 till 1.19 and I've set 1.20 for pixelserv-tls

 

[Mutzli]

My DHCP reservation is from 1.2 till 1.19 and I've set 1.20 for pixelserv-tls

18 devices is a small allotment, I have 40-50 devices at any given time on my network, well mostly lights and other smart home products.

 

[thelonelycoder]

so I did an upgrade to Standard edition and It changed "Wan: Use local caching DNS server as system resolver (default: No)" to Yes during the upgrade . So I had to change it to No .

OK, that was unintended but a logical conclusion as an upgrade is a re-install with more features, hence the setting change to "Ja, Si, Oui, Yes".
Let me check how I can fix that.

 

[nick_max]

I once have this issue. Maybe you have adblock/ublock extension/add-on in your web browser. u may need to disable it so that the dns queries will go thru diversion.

I use Chrome with uBlock Origin, Ghostery, Privacy Badger and Disconnect extensions. Could these interfere with Pixelserv?

 

[thelonelycoder]

My DHCP reservation is from 1.2 till 1.19 and I've set 1.20 for pixelserv-tls

Better turn it the other way round for simplicity. Use .2 for pixelserv-tls, then set the IP pool start/end to .3/.[something so high all devices get an IP].
In my small network I have it set to 50, which is plenty for me.

 

[Delusion]

I'll double check my logic when installing/upgrading.

No matter what, if DNS queries from LAN clients go anywhere else than the local Dnsmasq then Diversion has nothing to do and wont be able to do its job.

I guess it is still goes to local Dnsmasq because it does block ads and everything works .

This what RMerlin wrote about this option:
"Local caching has no impact on the LAN, it only affects the router itself, and program running locally on the router (and using /etc/resolv.conf)."

I guess that this why when I run update on Blacklist filters in Diversion or update Skynet list, I have this disconnection, the programs think there is no internet connection when Local Caching is set to "Yes" (as he said, it affects the programs running locally on router).

However, I feel that when this setting is set to Yes , everything is more smooth and response is faster.
It could be great if while updating filters in Diversion and Skynet, this option will be set to No and after the update is done, set it back to Yes .

nvram set dns_local_cache="1"
nvram set dns_local_cache="0"

 

[thelonelycoder]

I use Chrome with uBlock Origin, Ghostery, Privacy Badger and Disconnect extensions. Could these interfere with Pixelserv?

No.

 

[thelonelycoder]

OK, simple fix.
I've pushed a Diversion update, no version change

What's new
- Completely removed check "Wan: Use local caching DNS server as system resolver (default: No)" in Diversion.
Edit: This check seems to trigger more controversy than solving problems.

How to update
Use u to update to this latest version

 

[dave14305]

I use Chrome with uBlock Origin, Ghostery, Privacy Badger and Disconnect extensions. Could these interfere with Pixelserv?

They will prevent many ad domains from being requested in the first place, so you can say they preempt Diversion/Pixelserv rather than interfere.

You wear four belts plus suspenders!

 

[SomeWhereOverTheRainBow]

Diversion would prevent setting an IP that is within the set DHCP IP pool. But then, one may change the pool starting and ending address after the Diversion installation. Would be a classical PEBKAC error.

So I switched my DNS caching back to local and all seems to be working well; is there any significant research on this to show Diversion performs better this way? any testing?

 

[DonnyJohnny]

I use Chrome with uBlock Origin, Ghostery, Privacy Badger and Disconnect extensions. Could these interfere with Pixelserv?

They will prevent many ad domains from being requested in the first place, so you can say they preempt Diversion/Pixelserv rather than interfere.

You wear four belts plus suspenders!

answered by dave14305
meaning ublock will do the filtering first before it set the request to diversion. That is why you have low hit in the pixelserv stats.
pro is likely the ublock on PC will likely be faster and effective than diversion since it is more than just a dns block but script block.
con is u get lesser ad domain cert being generated to be stored in pixelserv cert cache.. but not a big issue.

 

[Butterfly Bones]

OK, simple fix.
I've pushed a Diversion update, no version change

Illegitimi non carborundum

 

[thelonelycoder]

So I switched my DNS caching back to local and all seems to be working well; is there any significant research on this to show Diversion performs better this way? any testing?

I'm not sure about the inner workings and frankly I am unhappy about that change that Asus brought us (RMerlin simply merged that behavior into his firmware).
The tooltip for that dreaded "Wan: Use local caching DNS server as system resolver (default: No)" is:

By default, DNS queries generated by the router itself are handled/cached by dnsmasq. Disabling this will send these queries directly to your WAN DNS servers (like stock firmware does). This means scripts running on the router will not be able to resolve local hostnames, but might work better with some setups. This does not affect your clients, ONLY queries done by the router itself.

That might help. It did now for me.

 

[thelonelycoder]

Illegitimi non carborundum

I might not say it but ...