Diversion Diversion 5.1.2 - the Router Ad-Blocker, April 21, 2024

[L&LD]

Sorry, that was about the extent of my iPhone knowledge.

 

[chewy74]

Question, will using a older USB 2.0 memory stick vs. Newer USB 3.0 stick effect internet speeds when using diversion adblock?

 

[thelonelycoder]

Question, will using a older USB 2.0 memory stick vs. Newer USB 3.0 stick effect internet speeds when using diversion adblock?

Depends. When logging is enabled then maybe. Otherwise not so much.
What makes a difference is to use an SSD instead of a thumb drive. They are by far more reliable.

 

[chewy74]

Depends. When logging is enabled then maybe. Otherwise not so much.
What makes a difference is to use an SSD instead of a thumb drive. They are by far more reliable.

OK just turned logging off

 

[Ellenswamy]

Question, will using a older USB 2.0 memory stick vs. Newer USB 3.0 stick effect internet speeds when using diversion adblock?

Depends. When logging is enabled then maybe. Otherwise not so much.
What makes a difference is to use an SSD instead of a thumb drive. They are by far more reliable.

This is what I did. Got a external usb ssd and I noticed a difference in some aspects

 

[kitzik]

DNS forwarding configured via dnsmasq.conf.add (local= or server=) stopped working since Diversion 5.1
I set up forwarding some hostnames resolution to the external dns server in dnsmasq.cong.add file using local=/hostname/external_dns.ip, and it indeed was working before Diversion 5.1 update. Now it just ignored until I switch ad-blocking to off. Could someone help? Thanks.

UPDATE: I have found a root cause. If forwarding hostname specified in the allow list, it conflicts with dnsmasq,conf.add

 

[thelonelycoder]

UPDATE: I have found a root cause. If forwarding hostname specified in the allow list, it conflicts with dnsmasq,conf.add

For my local *.test domains I use address=/test/192.168.2.160 in dnsmasq.conf.add to point them to the local web server.

 

[bjark]

Not sure that this is really in the domain of Diversion, but it may be related so here I go. Tell me if it should be posted someplace else instead.

I have been using the Google Discover feed on my Android phones for a long time. (It is by now heavily tuned in to what I want it to do, and I find it really good.)
My phone, if away from home wifi, is usually accessing Internet through a VPN tunnel over my home router which runs Diversion (with also Skynet and unbound, all assisted by amtm).

Up until some months ago I never saw any ads in the Discovery feed.
Then there started appearing ads, but they were easily "visually skippable" thanks to just being a short text and an empty square where the related image was supposed to appear. Not optimal, but not extremely annoying.
Then just recently these images started to load as I presume is intended by Google & co. Now the annoyance level is markedly increased. (NB, sometimes the feed is still totally free from ads, which I guess maybe could be because Google wants to see how the users react to different amounts of ad saturation, or just that they have run out of paying advertisers for me for the moment - this makes it a bit difficult to test blocking solutions at times.)

This happened around the same time I updated amtm (4.0 to 4.3) and Diversion (4.3.3 to 5.1, after amtm update). I also updated my blocking list selection to match the new Diversion system. Let me be clear, I don't know if the start of the appearance of the ad images could be causally related to the updates on the router, I only know that I did this around the same time I noticed the ad images started appearing.

I have tried to see if I can identify any blockable hosts (following dnsmasq log on the router, filtering for the Android device) related to refreshing the Discover feed, but I don't see any. I don't know of any way to see the Discover feed in a proper browser where I could inspect source and/or network traffic, and it doesn't seem that anyone else has a solution to this either. I have tried googling my way around the internet to find if anyone else has presented a DNS filter solution for this, but with no productive result. I have tried with blocking the hard-coded pagead2 host but it did not improve anything. I have checked that I do have every Google setting about targeted ads set to disabled (if I take a look at "why do I see this ad" information, they all say that they are based on country and time of day) like I've always had them.

So two questions out of this...
First, mostly for completeness sake because I don't really believe it myself - could the appearance of these ad images somehow be related to changes in Diversion's blocking?
Second, more practically important for me - does anyone have suggestions, or even a tested solution, on how to block these images/ads or should I just give up on it?

My bet is that the only changes actually having happened are made by Google and that I can't do anything about it. Sorry to waste your time then.

 

[kitzik]

The content of dnsmasq.conf on my router is the following:

<some dnsmasq options>
...
<content copied from dnsmasq.conf.add>
...

# start of Diversion directives #
conf-file=/opt/share/diversion/list/allowlist.conf
conf-file=/opt/share/diversion/list/blockinglist.conf
conf-file=/opt/share/diversion/list/denylist.conf
log-async
log-queries
log-facility=/opt/var/log/dnsmasq.log
# end of Diversion directives #

If you put some test hostname into Diversion allow list it will be processed to the directive server=/test/# in the allowlist.conf
And if at the same time you have something like server=/test/external_dns_ip_address in the dnsmasq.conf.add, it will be overwritten by this server directive from allowlist.conf, because diversion directives come last. Thus test will not be resolved via external_dns_ip_address, but via locally specified dns.

It seems something changed in version 5.1, because there was no such issue in the previous version.

 

[ColinTaylor]

If you put some test hostname into Diversion allow list it will be processed to the directive server=/test/# in the allowlist.conf
And if at the same time you have something like server=/test/external_dns_ip_address in the dnsmasq.conf.add, it will be overwritten by this server directive from allowlist.conf
Thus test will not be resolved via external_dns_ip_address, but via locally specified dns.

It seems something changed in version 5.1, because there was no such issue in the previous version.

Regardless of how Diversion worked in the past, surely the fundamental problem is that you have two conflicting directives:

server=/test/#
server=/test/external_dns_ip_address

So the answer is to not have conflicting directives whose interpretation is ambiguous. Or am I missing something?

 

[kitzik]

Regardless of how Diversion worked in the past, surely the fundamental problem is that you have two conflicting directives:

server=/test/#
server=/test/external_dns_ip_address

So the answer is to not have conflicting directives whose interpretation is ambiguous. Or am I missing something?

This can be fixed if Diversion directives come first in dnsmasq.conf, but it seems that Diversion put them automatically to the end of config file every time.

 

[thelonelycoder]

This can be fixed if Diversion directives come first in dnsmasq.conf, but it seems that Diversion put them automatically to the end of config file every time.

That‘s not by choice and I have no control over the order when they are added.

 

[dave14305]

This can be fixed if Diversion directives come first in dnsmasq.conf, but it seems that Diversion put them automatically to the end of config file every time.

Consider appending your entries by adding pc_append commands in /jffs/scripts/dnsmasq.postconf AFTER the post-conf.div line.

Of course, that could break if Diversion deletes and re-adds its own postconf entry. Hmm.

 

[thelonelycoder]

Consider appending your entries by adding pc_append commands in /jffs/scripts/dnsmasq.postconf AFTER the post-conf.div line.

Of course, that could break if Diversion deletes and re-adds its own postconf entry. Hmm.

Cat and mouse game.

 

[elorimer]

Then there started appearing ads, but they were easily "visually skippable" thanks to just being a short text and an empty square where the related image was supposed to appear.

This part, I think, relates to deprecating pixelserv in 5.0. Without pixelserv, a link to a blocked ad server returned a timeout and showed like that as a broken link. With pixelserv, the router immediately returned a valid 1 pixel image, which the clever page coders sometimes detected and rejected, sometimes serving up a baked ad, but otherwise was an invisible link rather than the broken link.

 

[BOFH]

Hi Guys,

I'm using Diversion since first day in parallel with Skynet for a long time on different routers.

I recently had to update my GT-AXE16000 firmware to the latest release FW-3004.388.6_2, after the reboot, I noticed that Wireless clients are not able to connect (can't get the IP from DHCP). Checking the logs, I have seen that dnsmasq is failing.
Disabling Diversion solved for me the issue.

Feb 27 17:31:12 ASUS custom_script: Running /jffs/scripts/service-event (args: restart dnsmasq)
Feb 27 17:31:12 ASUS custom_config: Appending content of /jffs/configs/dnsmasq.conf.add.
Feb 27 17:31:12 ASUS custom_script: Running /jffs/scripts/dnsmasq.postconf (args: /etc/dnsmasq.conf)

Feb 27 17:31:26 ASUS Diversion: started second Dnsmasq instance for alternate blocking list on IP 192.168.9.3
Feb 27 17:31:26 ASUS Diversion: restarted Dnsmasq to apply settings
Feb 27 17:31:26 ASUS uiDivStats: dnsmasq has restarted, restarting taildns
Feb 27 17:31:27 ASUS dnsmasq[94064]: failed to create listening socket for 192.168.9.1: Address already in use
Feb 27 17:31:27 ASUS dnsmasq[94064]: FAILED to start up
Feb 27 17:31:27 ASUS custom_script: Running /jffs/scripts/service-event-end (args: restart dnsmasq)
Feb 27 17:31:30 ASUS admin: Started taildns from .

Any idea on how to fix that without disabling Diversion?

 

[donbru]

This morning I upgraded my AC-1900P to 386.12_6 and saw the same exact message. Most of the 2.4 GHz wireless clients would not connect. I thought about disabling Diversion but reinstalled 386.12_0 instead. Everything back to normal.

 

[thelonelycoder]

Hi Guys,

I'm using Diversion since first day in parallel with Skynet for a long time on different routers.

I recently had to update my GT-AXE16000 firmware to the latest release FW-3004.388.6_2, after the reboot, I noticed that Wireless clients are not able to connect (can't get the IP from DHCP). Checking the logs, I have seen that dnsmasq is failing.
Disabling Diversion solved for me the issue.



Any idea on how to fix that without disabling Diversion?

Seems this is an uiDivStats problem. Disable it and see if Dnsmasq/Diversion starts.

 

[BOFH]

Seems this is an uiDivStats problem. Disable it and see if Dnsmasq/Diversion starts.

Hi @thelonelycoder ,

I did, uninstalled the beta version of uiDivStats but the issue still occurs.

Feb 27 21:29:02 ASUS rc_service: service 235224:notify_rc restart_dnsmasq
Feb 27 21:29:02 ASUS custom_script: Running /jffs/scripts/service-event (args: restart dnsmasq)
Feb 27 21:29:02 ASUS dnsmasq[75939]: exiting on receipt of SIGTERM
Feb 27 21:29:02 ASUS custom_config: Appending content of /jffs/configs/dnsmasq.conf.add.
Feb 27 21:29:02 ASUS custom_script: Running /jffs/scripts/dnsmasq.postconf (args: /etc/dnsmasq.conf)
Feb 27 21:29:03 ASUS avahi-daemon[7242]: Registering new address record for 192.168.9.3 on br0.IPv4.
Feb 27 21:29:16 ASUS Diversion: started second Dnsmasq instance for alternate blocking list on IP 192.168.9.3
Feb 27 21:29:16 ASUS Diversion: restarted Dnsmasq to apply settings
Feb 27 21:29:17 ASUS dnsmasq[235791]: failed to create listening socket for 192.168.9.1: Address already in use
Feb 27 21:29:17 ASUS dnsmasq[235791]: FAILED to start up
Feb 27 21:29:17 ASUS custom_script: Running /jffs/scripts/service-event-end (args: restart dnsmasq)

 

[nzwayne]

Hi Guys,

I'm using Diversion since first day in parallel with Skynet for a long time on different routers.

I recently had to update my GT-AXE16000 firmware to the latest release FW-3004.388.6_2, after the reboot, I noticed that Wireless clients are not able to connect (can't get the IP from DHCP). Checking the logs, I have seen that dnsmasq is failing.
Disabling Diversion solved for me the issue.



Any idea on how to fix that without disabling Diversion?

I had an issue some weeks back, where new clients (existing clients worked fine) couldn't connect on LAN or WiFi as DHCP not available. I had created my own dilemma by activating custom AdBlocking URL sites, that weren't supported by Diversion. Are you using the stock site selection or custom?