What's new

Diversion Seeing Ads (Mobile/Tablets)

  • 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!

Background

Regular Contributor
Hi,

I'm running RT-AC88U and for the last few months or so (March time) I'm getting ads mostly on devices including in-app ads used to always be blocked and worked fine. Like Instagram sponsored posts (stories) or just apps that require to watch an "advert" to download or pop-up ads like Vellum (wallpaper app) and especially Twitter.

I've the pixel ca.crt profile installed (and approved) on both iPhone/iPad. Any ideas? I use uBlock Origin on PC/Laptops so not sure if it's failing on PC as uBlock Origin probably blocks it.

Router: RT-AC88U
Merlin: 386.2_beta3
Diversion: 4.1.12 (Standard)
DNS: 1.1.1.1/8.8.8.8
Connect to DNS Server automatically: No
DNSFilter: Enabled (Mode: Router)


Update:
I've just seen from GitHub Wiki "Enable full trust for root certificates" [iOS 10.3] is this my issue? Although, I've never done this before when it worked for months previously on both iOS 13 and iOS 14..


Update 2:
Nope! Guess it's not cause of that being enabled. Still getting "Promoted" ads (like one from XboxUK here) across Twitter and other Apps.
 
Last edited:
Is your device running iOS 14? If yes, then certain DNS requests are not able to be blocked by diversion. You can check your dnsmasq.log and see if this is the case.

This is a sample blocked by diversion:
Code:
Jun 27 12:15:53 dnsmasq[445]: 6444 192.168.1.21/64321 query[A] rt.applvn.com from 192.168.1.21
Jun 27 12:15:53 dnsmasq[445]: 6444 192.168.1.21/64321 /opt/share/diversion/list/blockinglist rt.applvn.com is 192.168.1.254

Here, the same site request from same device is forwarded. The difference is iOS 14 support DNS type 65 query . If an apps use this type of query then diversion is bypassed.
Code:
Jun 27 12:15:53 dnsmasq[445]: 6443 192.168.1.21/61264 query[type=65] rt.applvn.com from 192.168.1.21
Jun 27 12:15:53 dnsmasq[445]: 6443 192.168.1.21/61264 forwarded rt.applvn.com to 127.0.0.1
 
Is your device running iOS 14? If yes, then certain DNS requests are not able to be blocked by diversion. You can check your dnsmasq.log and see if this is the case.

This is a sample blocked by diversion:
Code:
Jun 27 12:15:53 dnsmasq[445]: 6444 192.168.1.21/64321 query[A] rt.applvn.com from 192.168.1.21
Jun 27 12:15:53 dnsmasq[445]: 6444 192.168.1.21/64321 /opt/share/diversion/list/blockinglist rt.applvn.com is 192.168.1.254

Here, the same site request from same device is forwarded. The difference is iOS 14 support DNS type 65 query . If an apps use this type of query then diversion is bypassed.
Code:
Jun 27 12:15:53 dnsmasq[445]: 6443 192.168.1.21/61264 query[type=65] rt.applvn.com from 192.168.1.21
Jun 27 12:15:53 dnsmasq[445]: 6443 192.168.1.21/61264 forwarded rt.applvn.com to 127.0.0.1
Hi!

Yes, running iOS 14.6 (latest).

I'm rather new to Merlin and don't really do much techy logging wise. How would I go about checking the mentioned dnsmasq.log? Cheers.
 
Hi!

Yes, running iOS 14.6 (latest).

I'm rather new to Merlin and don't really do much techy logging wise. How would I go about checking the mentioned dnsmasq.log? Cheers.
Hi, the log is in directory /opt/var/log. After SSH into the router, you can check the running log by
Code:
 tail -f /opt/var/log/dnsmasq.log
. To stop it, use Ctrl+c key.
Alternatively, you can type diversion and get the menu, then type letter f to follow the said log.
 
Here, the same site request from same device is forwarded. The difference is iOS 14 support DNS type 65 query . If an apps use this type of query then diversion is bypassed.

You can try blocking it via iptables.

Code:
iptables -I INPUT -i br0 -p udp --dport 53 -d $(nvram get lan_ipaddr) -m string --hex-string "|000041|" --algo bm -j DROP
iptables -I FORWARD -i br0 -p udp --dport 53 -m string --hex-string "|000041|" --algo bm -j DROP

@RMerlin @thelonelycoder

asuswrt-merlin.ng/libxt_dns.c at master · RMerl/asuswrt-merlin.ng · GitHub

iptables has extensions to control dns query types.
It doesn't appear to have been added for the broadcom chipset, but I think it will be worth testing.
 
You can try blocking it via iptables.

Code:
iptables -I INPUT -i br0 -p udp --dport 53 -d $(nvram get lan_ipaddr) -m string --hex-string "|000041|" --algo bm -j DROP
iptables -I FORWARD -i br0 -p udp --dport 53 -m string --hex-string "|000041|" --algo bm -j DROP

@RMerlin @thelonelycoder

asuswrt-merlin.ng/libxt_dns.c at master · RMerl/asuswrt-merlin.ng · GitHub

iptables has extensions to control dns query types.
It doesn't appear to have been added for the broadcom chipset, but I think it will be worth testing.
It works. There is no more Type 65 DNS query seen in dnsmasq log. tcpdump shows query is sent but seems like is silently dropped.

Before apply,
dnsmasq log
Code:
Jun 28 13:01:09 dnsmasq[445]: 20766 192.168.1.21/61933 query[type=65] rt.applovin.com from 192.168.1.21
Jun 28 13:01:09 dnsmasq[445]: 20766 192.168.1.21/61933 forwarded rt.applovin.com to 127.0.0.1

corresponding tcpdump
Code:
13:01:09.523138 IP 192.168.1.21.61933 > 192.168.1.1.53: 63745+ Type65? rt.applovin.com. (33)
13:01:09.524385 IP 192.168.1.1.53 > 192.168.1.21.61933: 63745 2/1/0 CNAME ipv6-wildcard.applovin.com.edgekey.net., CNAME e10204.dsca.akamaiedge.net. (183)

After apply, no more log in dnsmasq. Only query seen in tcpdump.
Code:
13:02:06.489090 IP 192.168.1.21.61089 > 192.168.1.1.53: 40348+ Type65? rt.applovin.com. (33)
13:02:07.513380 IP 192.168.1.21.61089 > 192.168.1.1.53: 40348+ Type65? rt.applovin.com. (33)
13:02:09.568240 IP 192.168.1.21.61089 > 192.168.1.1.53: 40348+ Type65? rt.applovin.com. (33)

Since this is blanket drop for all type 65 query, non ads/tracker sites will gets dropped too?
Edit to show more consistent with the same adblock site.
 
Last edited:
Hi, the log is in directory /opt/var/log. After SSH into the router, you can check the running log by
Code:
 tail -f /opt/var/log/dnsmasq.log
. To stop it, use Ctrl+c key.
Alternatively, you can type diversion and get the menu, then type letter f to follow the said log.

Noted! Thanks for the steps.

I'm seeing a lot of query[type=65] around the Twitter and Instagram domain when a sponsored post appears. The same can be said for Snapchat (CDN) viewing stories and the advert in-between every story.

Jun 28 17:09:42 dnsmasq[24549]: query[type=65] tpop-api.twitter.com from 192.168.1.23
Jun 28 17:09:42 dnsmasq[24549]: forwarded tpop-api.twitter.com to 1.1.1.1
Jun 28 17:09:42 dnsmasq[24549]: query[A] tpop-api.twitter.com from 192.168.1.23
Jun 28 17:09:42 dnsmasq[24549]: forwarded tpop-api.twitter.com to 1.1.1.1
Jun 28 17:09:42 dnsmasq[24549]: query[A] e69896.dscapi6.akamaiedge.net from 192.168.1.23
 
Noted! Thanks for the steps.

I'm seeing a lot of query[type=65] around the Twitter and Instagram domain when a sponsored post appears. The same can be said for Snapchat (CDN) viewing stories and the advert in-between every story.
You can try the suggestion from @Odkrys above to block all query type 65. Some apps will try query type 65 first, if not available it will try normal query. So this will works. If an app is only set to use query type 65, blocking it may break it though. So far I only found one shopping apps that all images cannot load with query type 65 blocked. Other apps are working fine.

To block
Code:
iptables -I INPUT -i br0 -p udp --dport 53 -d $(nvram get lan_ipaddr) -m string --hex-string "|000041|" --algo bm -j DROP
iptables -I FORWARD -i br0 -p udp --dport 53 -m string --hex-string "|000041|" --algo bm -j DROP

To unblock, just delete the rules
Code:
iptables -D INPUT -i br0 -p udp --dport 53 -d $(nvram get lan_ipaddr) -m string --hex-string "|000041|" --algo bm -j DROP
iptables -D FORWARD -i br0 -p udp --dport 53 -m string --hex-string "|000041|" --algo bm -j DROP
 
You can try the suggestion from @Odkrys above to block all query type 65. Some apps will try query type 65 first, if not available it will try normal query. So this will works. If an app is only set to use query type 65, blocking it may break it though. So far I only found one shopping apps that all images cannot load with query type 65 blocked. Other apps are working fine.

To block
Code:
iptables -I INPUT -i br0 -p udp --dport 53 -d $(nvram get lan_ipaddr) -m string --hex-string "|000041|" --algo bm -j DROP
iptables -I FORWARD -i br0 -p udp --dport 53 -m string --hex-string "|000041|" --algo bm -j DROP

To unblock, just delete the rules
Code:
iptables -D INPUT -i br0 -p udp --dport 53 -d $(nvram get lan_ipaddr) -m string --hex-string "|000041|" --algo bm -j DROP
iptables -D FORWARD -i br0 -p udp --dport 53 -m string --hex-string "|000041|" --algo bm -j DROP
Thank you! Is iptables ran via Skynet?
 
You can try the suggestion from @Odkrys above to block all query type 65. Some apps will try query type 65 first, if not available it will try normal query. So this will works. If an app is only set to use query type 65, blocking it may break it though. So far I only found one shopping apps that all images cannot load with query type 65 blocked. Other apps are working fine.

To block
Code:
iptables -I INPUT -i br0 -p udp --dport 53 -d $(nvram get lan_ipaddr) -m string --hex-string "|000041|" --algo bm -j DROP
iptables -I FORWARD -i br0 -p udp --dport 53 -m string --hex-string "|000041|" --algo bm -j DROP

To unblock, just delete the rules
Code:
iptables -D INPUT -i br0 -p udp --dport 53 -d $(nvram get lan_ipaddr) -m string --hex-string "|000041|" --algo bm -j DROP
iptables -D FORWARD -i br0 -p udp --dport 53 -m string --hex-string "|000041|" --algo bm -j DROP

FYI, the Cloudflare Family/Gateway product blocks type 65 queries since February.


Perhaps Diversion should, also?
 
You can try the suggestion from @Odkrys above to block all query type 65. Some apps will try query type 65 first, if not available it will try normal query. So this will works. If an app is only set to use query type 65, blocking it may break it though. So far I only found one shopping apps that all images cannot load with query type 65 blocked. Other apps are working fine.

To block
Code:
iptables -I INPUT -i br0 -p udp --dport 53 -d $(nvram get lan_ipaddr) -m string --hex-string "|000041|" --algo bm -j DROP
iptables -I FORWARD -i br0 -p udp --dport 53 -m string --hex-string "|000041|" --algo bm -j DROP

To unblock, just delete the rules
Code:
iptables -D INPUT -i br0 -p udp --dport 53 -d $(nvram get lan_ipaddr) -m string --hex-string "|000041|" --algo bm -j DROP
iptables -D FORWARD -i br0 -p udp --dport 53 -m string --hex-string "|000041|" --algo bm -j DROP
I've been running these for the last 2-3 days and find that even web browsing can hang and timeout on my iPhone and iPads. I think closing Safari and reopening it seems to fix that. I haven't looked at the router logs, but has anyone else that tried blocking type 65 via iptables seen the same behavior that I'm seeing?
 
Using the drop rules also was having pages hang on my MacBook and prevented the Apple mail client from connecting to the server for my account.

Gonna try reject instead of drop and see how that goes.
 
I've been running these for the last 2-3 days and find that even web browsing can hang and timeout on my iPhone and iPads. I think closing Safari and reopening it seems to fix that. I haven't looked at the router logs, but has anyone else that tried blocking type 65 via iptables seen the same behavior that I'm seeing?

I tried using those commands for 5 minutes only, before having to remove them!

Those commands caused my Windows 10 laptop to stop resolving DNS for "messages.google.com". I was able to replicate this test 3 times. I used ipconfig /flushdns to clear the Windows DNS cache before each test.

So, while I think there is still value in blocking type-65 DNS queries (Cloudflare agrees!), I don't think the iptables commands posted above are doing the job.
 
It actually blocks the character 65, so it also blocks dns queries with a total length of 65 lol.
It seems better to create custom firmware using the source below.


I'm hopeful that these Dnsmasq patches will make it into the mainline so they can get picked up by RMerlin. Another option is if somebody can make a package to override the Dnsmasq on our routers?
 
REJECT seems like it may have been moderately better, but still prevented some pages from loading and my mail client from connecting. I've given up on them and removed both.
Thanks for checking and confirming. Is this the default Mail client?

I mainly just want to block in-app ads and Twitter posts sponsored but based on you guys testing it seems it breaks a few things (although I use Gmail in Chrome and Mailspring client). However, I've no idea how to run iptables command so. All new to me. :p
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top