Menu
What's new
By:
Filters Better Search

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!

Odkrys said:
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.

github.com

GitHub - rozahp/dnsmasq: This repo has moved to https://github.com/rozahp/dnsmasq-patch

This repo has moved to https://github.com/rozahp/dnsmasq-patch - rozahp/dnsmasq
github.com github.com
Click to expand...
Like others I found a few normal query blocked due to this as well. I tested by manually adding the public ip and and blocked domain in diversion blacklist. Then I run "service restart_dnsmasq". Now these domains can be resolved temporarily from the 'blacklist'. A reboot will make all domain in the list into blocked ip though.
How do I add new addn-hosts in /tmp/etc/dnsmasq.conf? I am not sure if this is worth the effort. For some the list may grow too long to maintain. Or is there any other workaround?

Edit: I managed to add it in dnsmasq.add. But it is not working actually. It might be cache or I mistakenly removed the iptables when I tested it.

Update: Looking at the packet, DNS query type 65 is highlight in blue "00 41". It has "00" in front and follow by query Class Internet which has a hex value of "00 01". I extend the iptables hex string from "|000041|" to "|0000410001|". So it has to be more specific match to get rejected by iptables. The few sites that were not loading before are working now.
1625482957846.png


Below is a sample of type A DNS query which happens to have an ip lengh of 65 (0x0041 in hex) that matches the iptables reject rule. Original rules only matches 6 hex digits (000041). As a result, this non type 65 query packet gets dropped.
With the new hex string in the iptables reject rule of "0000410001", it has to match 10 hex digits. Meaning this includes length and identification id. In this sample, the hex is "0000410e96" which does not match "
0000410001" and will not be rejected by the rule.
1625482969879.png

Edited to obsfucate router mac address.
 
Last edited:
chongnt said:
Like others I found a few normal query blocked due to this as well. I tested by manually adding the public ip and and blocked domain in diversion blacklist. Then I run "service restart_dnsmasq". Now these domains can be resolved temporarily from the 'blacklist'. A reboot will make all domain in the list into blocked ip though.
How do I add new addn-hosts in /tmp/etc/dnsmasq.conf? I am not sure if this is worth the effort. For some the list may grow too long to maintain. Or is there any other workaround?

Edit: I managed to add it in dnsmasq.add. But it is not working actually. It might be cache or I mistakenly removed the iptables when I tested it.

Update: Looking at the packet, DNS query type 65 is highlight in blue "00 41". It has "00" in front and follow by query Class Internet which has a hex value of "00 01". I extend the iptables hex string from "|000041|" to "|0000410001|". So it has to be more specific match to get rejected by iptables. The few sites that were not loading before are working now.
View attachment 34800

Below is a sample of type A DNS query which happens to have an ip lengh of 65 (0x0041 in hex) that matches the iptables reject rule. Original rules only matches 6 hex digits (000041). As a result, this non type 65 query packet gets dropped.
With the new hex string in the iptables reject rule of "0000410001", it has to match 10 hex digits. Meaning this includes length and identification id. In this sample, the hex is "0000410e96" which does not match "
0000410001" and will not be rejected by the rule.
View attachment 34801
Edited to obsfucate router mac address.
Click to expand...
How you finding the updated block?
 
Background said:
How you finding the updated block?
Click to expand...
I have been using the updated block for over a week now and for my usage I did not find any abnormality. Nothing seems to be broken. Here is the updated block I am using.

Code: 
iptables -I INPUT -p udp --dport 53 -d $(nvram get lan_ipaddr) -m comment --comment "DNS Type 65" -m string --hex-string "|0000410001|" --algo bm -j REJECT
iptables -I FORWARD -p udp --dport 53 -m comment --comment "DNS Type 65" -m string --hex-string "|0000410001|" --algo bm -j REJECT

To remove the block,
Code: 
iptables -D INPUT -p udp --dport 53 -d $(nvram get lan_ipaddr) -m comment --comment "DNS Type 65" -m string --hex-string "|0000410001|" --algo bm -j REJECT
iptables -D FORWARD -p udp --dport 53 -m comment --comment "DNS Type 65" -m string --hex-string "|0000410001|" --algo bm -j REJECT
 
CriticJay said:
FYI, the Cloudflare Family/Gateway product blocks type 65 queries since February.

community.cloudflare.com

Apple with iOS 14 pokes a hole in DNS filtering with query type 65

@NordicMember This link has since expired. Are you able to upload it again? Cheers!
community.cloudflare.com community.cloudflare.com

Perhaps Diversion should, also?
Click to expand...
Looks like Adguard are onto it as well?
github.com

Make sure AdGuard Home blocks TYPE65 queries for domains that are blocked · Issue #2135 · AdguardTeam/AdGuardHome

When domain is blocked, we should prevent all kinds of DNS queries. @szolin could you please double-check that we do this in AGH (and in AG DNS as well)?
github.com github.com
 
chongnt said:
I have been using the updated block for over a week now and for my usage I did not find any abnormality. Nothing seems to be broken. Here is the updated block I am using.

Code: 
iptables -I INPUT -p udp --dport 53 -d $(nvram get lan_ipaddr) -m comment --comment "DNS Type 65" -m string --hex-string "|0000410001|" --algo bm -j REJECT
iptables -I FORWARD -p udp --dport 53 -m comment --comment "DNS Type 65" -m string --hex-string "|0000410001|" --algo bm -j REJECT

To remove the block,
Code: 
iptables -D INPUT -p udp --dport 53 -d $(nvram get lan_ipaddr) -m comment --comment "DNS Type 65" -m string --hex-string "|0000410001|" --algo bm -j REJECT
iptables -D FORWARD -p udp --dport 53 -m comment --comment "DNS Type 65" -m string --hex-string "|0000410001|" --algo bm -j REJECT
Click to expand...

Hi, I tried that code but I seem to get `iptables: No chain/target/match by that name.`
 
Background said:
Hi, I tried that code but I seem to get `iptables: No chain/target/match by that name.`
Click to expand...
Maybe can try without comment. The original one is without comment too.

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

In case something break or want to remove the block:
Code: 
iptables -D INPUT -p udp --dport 53 -d $(nvram get lan_ipaddr) -m string --hex-string "|0000410001|" --algo bm -j REJECT
iptables -D FORWARD -p udp --dport 53 -m string --hex-string "|0000410001|" --algo bm -j REJECT
 
chongnt said:
Maybe can try without comment. The original one is without comment too.

Code: 
#Enable block DNS query type 65
iptables -I INPUT -p udp --dport 53 -d $(nvram get lan_ipaddr) -m string --hex-string "|0000410001|" --algo bm -j REJECT
iptables -I FORWARD -p udp --dport 53 -m string --hex-string "|0000410001|" --algo bm -j REJECT

#Disable block DNS query type 65
iptables -D INPUT -p udp --dport 53 -d $(nvram get lan_ipaddr) -m string --hex-string "|0000410001|" --algo bm -j REJECT
iptables -D FORWARD -p udp --dport 53 -m string --hex-string "|0000410001|" --algo bm -j REJECT
Click to expand...
Thanks! That allowed me to enter the command no error but also same time no success message? Is that normal.
 
Background said:
Thanks! That allowed me to enter the command no error but also same time no success message? Is that normal.
Click to expand...
Yes, it is normal. In order to add comment, seems like need to have
Code: 
modprobe xt_comment
. I have this in init-start script. You can run this first before the one with comment. Anyway, it will work without comment.

www.snbforums.com

iptables comment

I gather, on the RT-AC87U at least, that by running modprobe xt_comment I can add -m comment --comment "My comment" in an iptables rule. Is there somewhere I can check which models have this module?
www.snbforums.com www.snbforums.com

To verify the rule
Code: 
iptables -nvL INPUT | grep 'pkts\|0000410001'
iptables -nvL FORWARD | grep 'pkts\|0000410001'

I don't have anything that hit the second rule. This is my output
Code: 
admin@RT-AC86U-DBA8:/tmp/home/root# iptables -nvL INPUT | grep 'pkts\|0000410001'
 pkts bytes target     prot opt in     out     source               destination         
24054 1643K REJECT     udp  --  *      *       0.0.0.0/0            192.168.1.1          udp dpt:53 /* DNS Type 65 */ STRING match  "|0000410001|" ALGO name bm TO 65535 reject-with icmp-port-unreachable
admin@RT-AC86U-DBA8:/tmp/home/root# iptables -nvL FORWARD | grep 'pkts\|0000410001'
 pkts bytes target     prot opt in     out     source               destination         
    0     0 REJECT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:53 /* DNS Type 65 */ STRING match  "|0000410001|" ALGO name bm TO 65535 reject-with icmp-port-unreachable
 
Last edited:
chongnt said:
Yes, it is normal. In order to add comment, seems like need to have
Code: 
modprobe xt_comment
. I have this in init-start script. You can run this first before the one with comment. Anyway, it will work without comment.

www.snbforums.com

iptables comment

I gather, on the RT-AC87U at least, that by running modprobe xt_comment I can add -m comment --comment "My comment" in an iptables rule. Is there somewhere I can check which models have this module?
www.snbforums.com www.snbforums.com

To verify the rule
Code: 
iptables -nvL INPUT | grep 'pkts\|0000410001'
iptables -nvL FORWARD | grep 'pkts\|0000410001'

I don't have anything that hit the second rule. This is my output
Code: 
admin@RT-AC86U-DBA8:/tmp/home/root# iptables -nvL INPUT | grep 'pkts\|0000410001'
pkts bytes target     prot opt in     out     source               destination        
24054 1643K REJECT     udp  --  *      *       0.0.0.0/0            192.168.1.1          udp dpt:53 /* DNS Type 65 */ STRING match  "|0000410001|" ALGO name bm TO 65535 reject-with icmp-port-unreachable
admin@RT-AC86U-DBA8:/tmp/home/root# iptables -nvL FORWARD | grep 'pkts\|0000410001'
pkts bytes target     prot opt in     out     source               destination        
    0     0 REJECT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:53 /* DNS Type 65 */ STRING match  "|0000410001|" ALGO name bm TO 65535 reject-with icmp-port-unreachable
Click to expand...
Thank you. That's brilliant.

Here is my result, looks pretty much the same (minus the comments).

Code: 
ASUSWRT-Merlin RT-AC88U 386.3_beta2 Sat Jul 10 17:09:51 UTC 2021

RT-AC88U-E998:/tmp/home/root# iptables -nvL INPUT | grep 'pkts\|0000410001'
 pkts bytes target     prot opt in     out     source               destination                                                                                                                                                              
 3777  268K REJECT     udp  --  *      *       0.0.0.0/0            192.168.1.1                                                                                                 

RT-AC88U-E998:/tmp/home/root# iptables -nvL FORWARD | grep 'pkts\|0000410001'
 pkts bytes target     prot opt in     out     source               destination
    0     0 REJECT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:53 STRING match  "|0000410001|" ALGO name bm TO 65535 reject-with icmp-port-unreachable

Still seeing ads/sponsored posts and such across iOS 14/iOS 15 Public Beta though?
 
Background said:
Thank you. That's brilliant.

Here is my result, looks pretty much the same (minus the comments).

Code: 
ASUSWRT-Merlin RT-AC88U 386.3_beta2 Sat Jul 10 17:09:51 UTC 2021

RT-AC88U-E998:/tmp/home/root# iptables -nvL INPUT | grep 'pkts\|0000410001'
pkts bytes target     prot opt in     out     source               destination                                                                                                                                                            
3777  268K REJECT     udp  --  *      *       0.0.0.0/0            192.168.1.1                                                                                               

RT-AC88U-E998:/tmp/home/root# iptables -nvL FORWARD | grep 'pkts\|0000410001'
pkts bytes target     prot opt in     out     source               destination
    0     0 REJECT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:53 STRING match  "|0000410001|" ALGO name bm TO 65535 reject-with icmp-port-unreachable

Still seeing ads/sponsored posts and such across iOS 14/iOS 15 Public Beta though?
Click to expand...
I am sorry to hear that. Looking at the output, DNS query type 65 should be blocked now. It looks like the ads are not block by diversion, and not sneaking through DNS request type 65. I just relook into your first post, ads in application like Instagram and twitter could be difficult to block. It might be something like youtube ads. I tried Vellum apps, with diversion there is no ads shown. It does occasionally have an in-apps pop-up asking to purchase the apps. When I disconnect from wifi and use mobile data, there is ads on the bottom of the screen.
 
Last edited:
chongnt said:
I am sorry to hear that. Looking at the output, DNS query type 65 should be blocked now. It looks like the ads are not block by diversion, and not sneaking through DNS request type 65. I just relook into your first post, ads in application like Instagram and twitter could be difficult to block. It might be something like youtube ads. I tried Vellum apps, with diversion there is no ads shown. It does occasionally have an in-apps pop-up asking to purchase the apps. When I disconnect from wifi and use mobile data, there is ads on the bottom of the screen.
Click to expand...
Hi, many thanks. Yeah the Vellum App seems to never get ads anymore since I updated the app via App Store so seems Diversion is blocking it again. On 4G there is an ad soon as you open the daily wallpaper/try to download.

Snapchat stories, Twitter and Instagram seem to be the worst ads, logs mention these are type=65 :(
 
Background said:
Hi, many thanks. Yeah the Vellum App seems to never get ads anymore since I updated the app via App Store so seems Diversion is blocking it again. On 4G there is an ad soon as you open the daily wallpaper/try to download.

Snapchat stories, Twitter and Instagram seem to be the worst ads, logs mention these are type=65 :(
Click to expand...
I don't have the other apps so could not compare to my logs. Do you mean you still see query[type=65] in dnsmasq log? In your last output I see some packet count hits the reject rule, by right these should not reach dnsmasq anymore.
 
@chongnt 2 questions

1. Do the rejected type 65 packets show up in Diversion stats?

2. If the reject rule is entered correctly, would rejected packets show up in the dnsmasq log file? I view the log file through Diversion menu options and I don't believe I see them there.
 
CriticJay said:
@chongnt 2 questions

1. Do the rejected type 65 packets show up in Diversion stats?

2. If the reject rule is entered correctly, would rejected packets show up in the dnsmasq log file? I view the log file through Diversion menu options and I don't believe I see them there.
Click to expand...
Rejected packets will not show up in Diversion stats and dnsmasq log. You should see packet count in reject rule increases whenever a packet is rejected by the rule. If you don't see any of it in dnsmasq log and the counter in reject rule increases then it is working as expected.
 
chongnt said:
I don't have the other apps so could not compare to my logs. Do you mean you still see query[type=65] in dnsmasq log? In your last output I see some packet count hits the reject rule, by right these should not reach dnsmasq anymore.
Click to expand...
Hi, yes when using the apps I'm seeing that type=65 in dnsmasq log. I noticed Skynet reporting this:


skynet.png


Is this anything to worry about? IPTables Rules Failed.
 
Background said:
Hi, yes when using the apps I'm seeing that type=65 in dnsmasq log. I noticed Skynet reporting this:


View attachment 35046

Is this anything to worry about? IPTables Rules Failed.
Click to expand...
I have been adding and removing the two rules above many times and see no impact to Skynet. Was Skynet working before and did you make any changes to it? You can see Skynet iptables here
Code: 
iptables -t raw -nvL
. Perhaps can try restart Skynet or reboot router and see if it helps.
It is strange that you still see query[type=65] in dnsmasq log after apply the rules. Do you see packet count increases when you run this command a few times?
Code: 
iptables -nvL INPUT | grep 'pkts\|0000410001'
 
chongnt said:
I have been adding and removing the two rules above many times and see no impact to Skynet. Was Skynet working before and did you make any changes to it? You can see Skynet iptables here
Code: 
iptables -t raw -nvL
. Perhaps can try restart Skynet or reboot router and see if it helps.
It is strange that you still see query[type=65] in dnsmasq log after apply the rules. Do you see packet count increases when you run this command a few times?
Code: 
iptables -nvL INPUT | grep 'pkts\|0000410001'
Click to expand...

Hi, running those commands:

Code: 
@RT-AC88U-E998:/tmp/home/root# iptables -t raw -nvL
Chain PREROUTING (policy ACCEPT 23571 packets, 8151K bytes)
pkts bytes target     prot opt in     out     source               destination
    0     0 LOG        all  --  br0    *       0.0.0.0/0            0.0.0.0/0            ! match-set Skynet-Whitelist dst match-set Skynet-Master dst LOG flags 7 level 4 prefix "[BLOCKED - OUTBOUND] "
    0     0 DROP       all  --  br0    *       0.0.0.0/0            0.0.0.0/0            ! match-set Skynet-Whitelist dst match-set Skynet-Master dst
1630 68001 LOG        all  --  eth0   *       0.0.0.0/0            0.0.0.0/0            ! match-set Skynet-Whitelist src match-set Skynet-Master src LOG flags 7 level 4 prefix "[BLOCKED - INBOUND] "
1630 68001 DROP       all  --  eth0   *       0.0.0.0/0            0.0.0.0/0            ! match-set Skynet-Whitelist src match-set Skynet-Master src

Chain OUTPUT (policy ACCEPT 4982 packets, 1120K bytes)
pkts bytes target     prot opt in     out     source               destination
    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            ! match-set Skynet-Whitelist dst match-set Skynet-Master dst LOG flags 7 level 4 prefix "[BLOCKED - OUTBOUND] "
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            ! match-set Skynet-Whitelist dst match-set Skynet-Master dst
@RT-AC88U-E998:/tmp/home/root# iptables -nvL INPUT | grep 'pkts\|0000410001'
pkts bytes target     prot opt in     out     source               destination
@RT-AC88U-E998:/tmp/home/root# iptables -nvL INPUT | grep 'pkts\|0000410001'
@RT-AC88U-E998:/tmp/home/root# iptables -t raw -nvL
Chain PREROUTING (policy ACCEPT 208K packets, 258M bytes)
pkts bytes target     prot opt in     out     source               destination
    0     0 LOG        all  --  br0    *       0.0.0.0/0            0.0.0.0/0            ! match-set Skynet-Whitelist dst match-set Skynet-Master dst LOG flags 7 level 4 prefix "[BLOCKED - OUTBOUND] "
    0     0 DROP       all  --  br0    *       0.0.0.0/0            0.0.0.0/0            ! match-set Skynet-Whitelist dst match-set Skynet-Master dst
1657 69109 LOG        all  --  eth0   *       0.0.0.0/0            0.0.0.0/0            ! match-set Skynet-Whitelist src match-set Skynet-Master src LOG flags 7 level 4 prefix "[BLOCKED - INBOUND] "
1657 69109 DROP       all  --  eth0   *       0.0.0.0/0            0.0.0.0/0            ! match-set Skynet-Whitelist src match-set Skynet-Master src

Chain OUTPUT (policy ACCEPT 122K packets, 56M bytes)
pkts bytes target     prot opt in     out     source               destination
    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            ! match-set Skynet-Whitelist dst match-set Skynet-Master dst LOG flags 7 level 4 prefix "[BLOCKED - OUTBOUND] "
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            ! match-set Skynet-Whitelist dst match-set Skynet-Master dst
@RT-AC88U-E998:/tmp/home/root#

I can confirm another another reboot the query[type=65] in dnsmasq log has stopped.

Code: 
20:16:30 dnsmasq[7964]: blocked by blockinglist app-analytics-v2.snapchat.com is 192.168.1.2
20:16:30 dnsmasq[7964]: reply us-central1-gcp.api.snapchat.com is <CNAME>
20:16:30 dnsmasq[7964]: reply us-central1-gcp.api.sc-gw.com is 35.190.43.134
20:16:30 dnsmasq[7964]: query[A] aws.api.snapchat.com from 192.168.1.50
20:16:30 dnsmasq[7964]: forwarded aws.api.snapchat.com to 1.1.1.2
20:16:30 dnsmasq[7964]: reply aws.api.snapchat.com is <CNAME>
20:16:30 dnsmasq[7964]: reply aws.api.sc-gw.com is <CNAME>
20:16:30 dnsmasq[7964]: reply eu-west1-aws.api.sc-gw.com is 63.32.165.80
20:16:30 dnsmasq[7964]: query[A] cf-st.sc-cdn.net from 192.168.1.50
20:16:30 dnsmasq[7964]: forwarded cf-st.sc-cdn.net to 1.1.1.2
20:16:30 dnsmasq[7964]: reply cf-st.sc-cdn.net is 99.86.116.41
20:16:30 dnsmasq[7964]: reply cf-st.sc-cdn.net is 99.86.116.29
20:16:30 dnsmasq[7964]: reply cf-st.sc-cdn.net is 99.86.116.72
20:16:30 dnsmasq[7964]: reply cf-st.sc-cdn.net is 99.86.116.75
20:16:31 dnsmasq[7964]: query[A] us-east4-gcp.api.snapchat.com from 192.168.1.50
20:16:31 dnsmasq[7964]: forwarded us-east4-gcp.api.snapchat.com to 1.1.1.2
20:16:31 dnsmasq[7964]: reply us-east4-gcp.api.snapchat.com is <CNAME>
20:16:31 dnsmasq[7964]: reply us-east4-gcp.api.sc-gw.com is 35.190.43.134
20:16:31 dnsmasq[7964]: query[A] gtq6.sct.sc-prod.net from 192.168.1.50
20:16:31 dnsmasq[7964]: forwarded gtq6.sct.sc-prod.net to 1.1.1.2
20:16:31 dnsmasq[7964]: reply gtq6.sct.sc-prod.net is 35.190.22.22
20:16:31 dnsmasq[7964]: query[A] bolt-gcdn.sc-cdn.net from 192.168.1.50
20:16:31 dnsmasq[7964]: forwarded bolt-gcdn.sc-cdn.net to 1.1.1.2
20:16:31 dnsmasq[7964]: reply bolt-gcdn.sc-cdn.net is 35.241.16.93
20:16:33 dnsmasq[7964]: query[AAAA] data.meethue.com from 192.168.1.65
20:16:33 dnsmasq[7964]: forwarded data.meethue.com to 1.1.1.2
20:16:33 dnsmasq[7964]: reply data.meethue.com is <CNAME>
20:16:33 dnsmasq[7964]: query[A] data.meethue.com from 192.168.1.65
20:16:33 dnsmasq[7964]: forwarded data.meethue.com to 1.1.1.2
20:16:33 dnsmasq[7964]: reply data.meethue.com is <CNAME>
20:16:33 dnsmasq[7964]: reply prod.huedatastore.com is 54.72.226.75
20:16:33 dnsmasq[7964]: reply prod.huedatastore.com is 54.195.131.198
20:16:34 dnsmasq[7964]: query[A] www.google.com from 192.168.1.85
20:16:34 dnsmasq[7964]: cached www.google.com is 142.250.179.228
20:16:34 dnsmasq[7964]: query[AAAA] www.google.com from 192.168.1.85
20:16:34 dnsmasq[7964]: cached www.google.com is 2a00:1450:4009:81d::2004
20:16:41 dnsmasq[7964]: query[A] europe-west1-gcp.api.snapchat.com from 192.168.1.50
20:16:41 dnsmasq[7964]: forwarded europe-west1-gcp.api.snapchat.com to 1.0.0.2
20:16:41 dnsmasq[7964]: forwarded europe-west1-gcp.api.snapchat.com to 1.1.1.2
20:16:41 dnsmasq[7964]: reply europe-west1-gcp.api.snapchat.com is <CNAME>
20:16:41 dnsmasq[7964]: reply europe-west1-gcp.api.sc-gw.com is 35.190.43.134
20:16:57 dnsmasq[7964]: query[A] configuration.apple.com from 192.168.1.131
20:16:57 dnsmasq[7964]: forwarded configuration.apple.com to 1.1.1.2
20:16:57 dnsmasq[7964]: reply configuration.apple.com is <CNAME>
20:16:57 dnsmasq[7964]: reply configuration.apple.com.akadns.net is <CNAME>
20:16:57 dnsmasq[7964]: reply configuration.apple.com.edgekey.net is <CNAME>
20:16:57 dnsmasq[7964]: reply e673.dsce9.akamaiedge.net is 2.16.75.200
20:17:01 dnsmasq[7964]: query[A] gcp.api.snapchat.com from 192.168.1.50
20:17:01 dnsmasq[7964]: forwarded gcp.api.snapchat.com to 1.1.1.2
20:17:01 dnsmasq[7964]: reply gcp.api.snapchat.com is <CNAME>
20:17:01 dnsmasq[7964]: reply gcp.api.sc-gw.com is 35.190.43.134
20:17:12 dnsmasq[7964]: query[A] clients3.google.com from 192.168.1.85
20:17:12 dnsmasq[7964]: forwarded clients3.google.com to 1.0.0.2
20:17:12 dnsmasq[7964]: forwarded clients3.google.com to 1.1.1.2
20:17:12 dnsmasq[7964]: reply clients3.google.com is <CNAME>

Example of Snapchat + ads (in between stories).



uiDivStats search for "snapchat"

Code: 
2021-07-18 18:32    gcp.api.snapchat.com    XXX.XXX.X.XX    type=65    Allowed
2021-07-18 18:32    mvm.snapchat.com    XXX.XXX.X.XX  type=65    Allowed

I see a lot of this in uiDivStats too, I wonder if it's Apple Ads snapchat and other apps use in iOS 14/15?

Code: 
2021-07-18 19:40    cf.iadsdk.apple.com    XXX.XXX.X.XX type=65    Allowed
 
Last edited:
Background said:
Hi, running those commands:

Code: 
@RT-AC88U-E998:/tmp/home/root# iptables -t raw -nvL
Chain PREROUTING (policy ACCEPT 23571 packets, 8151K bytes)
pkts bytes target     prot opt in     out     source               destination
    0     0 LOG        all  --  br0    *       0.0.0.0/0            0.0.0.0/0            ! match-set Skynet-Whitelist dst match-set Skynet-Master dst LOG flags 7 level 4 prefix "[BLOCKED - OUTBOUND] "
    0     0 DROP       all  --  br0    *       0.0.0.0/0            0.0.0.0/0            ! match-set Skynet-Whitelist dst match-set Skynet-Master dst
1630 68001 LOG        all  --  eth0   *       0.0.0.0/0            0.0.0.0/0            ! match-set Skynet-Whitelist src match-set Skynet-Master src LOG flags 7 level 4 prefix "[BLOCKED - INBOUND] "
1630 68001 DROP       all  --  eth0   *       0.0.0.0/0            0.0.0.0/0            ! match-set Skynet-Whitelist src match-set Skynet-Master src

Chain OUTPUT (policy ACCEPT 4982 packets, 1120K bytes)
pkts bytes target     prot opt in     out     source               destination
    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            ! match-set Skynet-Whitelist dst match-set Skynet-Master dst LOG flags 7 level 4 prefix "[BLOCKED - OUTBOUND] "
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            ! match-set Skynet-Whitelist dst match-set Skynet-Master dst
@RT-AC88U-E998:/tmp/home/root# iptables -nvL INPUT | grep 'pkts\|0000410001'
pkts bytes target     prot opt in     out     source               destination
@RT-AC88U-E998:/tmp/home/root# iptables -nvL INPUT | grep 'pkts\|0000410001'
@RT-AC88U-E998:/tmp/home/root# iptables -t raw -nvL
Chain PREROUTING (policy ACCEPT 208K packets, 258M bytes)
pkts bytes target     prot opt in     out     source               destination
    0     0 LOG        all  --  br0    *       0.0.0.0/0            0.0.0.0/0            ! match-set Skynet-Whitelist dst match-set Skynet-Master dst LOG flags 7 level 4 prefix "[BLOCKED - OUTBOUND] "
    0     0 DROP       all  --  br0    *       0.0.0.0/0            0.0.0.0/0            ! match-set Skynet-Whitelist dst match-set Skynet-Master dst
1657 69109 LOG        all  --  eth0   *       0.0.0.0/0            0.0.0.0/0            ! match-set Skynet-Whitelist src match-set Skynet-Master src LOG flags 7 level 4 prefix "[BLOCKED - INBOUND] "
1657 69109 DROP       all  --  eth0   *       0.0.0.0/0            0.0.0.0/0            ! match-set Skynet-Whitelist src match-set Skynet-Master src

Chain OUTPUT (policy ACCEPT 122K packets, 56M bytes)
pkts bytes target     prot opt in     out     source               destination
    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            ! match-set Skynet-Whitelist dst match-set Skynet-Master dst LOG flags 7 level 4 prefix "[BLOCKED - OUTBOUND] "
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            ! match-set Skynet-Whitelist dst match-set Skynet-Master dst
@RT-AC88U-E998:/tmp/home/root#

I can confirm another another reboot the query[type=65] in dnsmasq log has stopped.

Code: 
20:16:30 dnsmasq[7964]: blocked by blockinglist app-analytics-v2.snapchat.com is 192.168.1.2
20:16:30 dnsmasq[7964]: reply us-central1-gcp.api.snapchat.com is <CNAME>
20:16:30 dnsmasq[7964]: reply us-central1-gcp.api.sc-gw.com is 35.190.43.134
20:16:30 dnsmasq[7964]: query[A] aws.api.snapchat.com from 192.168.1.50
20:16:30 dnsmasq[7964]: forwarded aws.api.snapchat.com to 1.1.1.2
20:16:30 dnsmasq[7964]: reply aws.api.snapchat.com is <CNAME>
20:16:30 dnsmasq[7964]: reply aws.api.sc-gw.com is <CNAME>
20:16:30 dnsmasq[7964]: reply eu-west1-aws.api.sc-gw.com is 63.32.165.80
20:16:30 dnsmasq[7964]: query[A] cf-st.sc-cdn.net from 192.168.1.50
20:16:30 dnsmasq[7964]: forwarded cf-st.sc-cdn.net to 1.1.1.2
20:16:30 dnsmasq[7964]: reply cf-st.sc-cdn.net is 99.86.116.41
20:16:30 dnsmasq[7964]: reply cf-st.sc-cdn.net is 99.86.116.29
20:16:30 dnsmasq[7964]: reply cf-st.sc-cdn.net is 99.86.116.72
20:16:30 dnsmasq[7964]: reply cf-st.sc-cdn.net is 99.86.116.75
20:16:31 dnsmasq[7964]: query[A] us-east4-gcp.api.snapchat.com from 192.168.1.50
20:16:31 dnsmasq[7964]: forwarded us-east4-gcp.api.snapchat.com to 1.1.1.2
20:16:31 dnsmasq[7964]: reply us-east4-gcp.api.snapchat.com is <CNAME>
20:16:31 dnsmasq[7964]: reply us-east4-gcp.api.sc-gw.com is 35.190.43.134
20:16:31 dnsmasq[7964]: query[A] gtq6.sct.sc-prod.net from 192.168.1.50
20:16:31 dnsmasq[7964]: forwarded gtq6.sct.sc-prod.net to 1.1.1.2
20:16:31 dnsmasq[7964]: reply gtq6.sct.sc-prod.net is 35.190.22.22
20:16:31 dnsmasq[7964]: query[A] bolt-gcdn.sc-cdn.net from 192.168.1.50
20:16:31 dnsmasq[7964]: forwarded bolt-gcdn.sc-cdn.net to 1.1.1.2
20:16:31 dnsmasq[7964]: reply bolt-gcdn.sc-cdn.net is 35.241.16.93
20:16:33 dnsmasq[7964]: query[AAAA] data.meethue.com from 192.168.1.65
20:16:33 dnsmasq[7964]: forwarded data.meethue.com to 1.1.1.2
20:16:33 dnsmasq[7964]: reply data.meethue.com is <CNAME>
20:16:33 dnsmasq[7964]: query[A] data.meethue.com from 192.168.1.65
20:16:33 dnsmasq[7964]: forwarded data.meethue.com to 1.1.1.2
20:16:33 dnsmasq[7964]: reply data.meethue.com is <CNAME>
20:16:33 dnsmasq[7964]: reply prod.huedatastore.com is 54.72.226.75
20:16:33 dnsmasq[7964]: reply prod.huedatastore.com is 54.195.131.198
20:16:34 dnsmasq[7964]: query[A] www.google.com from 192.168.1.85
20:16:34 dnsmasq[7964]: cached www.google.com is 142.250.179.228
20:16:34 dnsmasq[7964]: query[AAAA] www.google.com from 192.168.1.85
20:16:34 dnsmasq[7964]: cached www.google.com is 2a00:1450:4009:81d::2004
20:16:41 dnsmasq[7964]: query[A] europe-west1-gcp.api.snapchat.com from 192.168.1.50
20:16:41 dnsmasq[7964]: forwarded europe-west1-gcp.api.snapchat.com to 1.0.0.2
20:16:41 dnsmasq[7964]: forwarded europe-west1-gcp.api.snapchat.com to 1.1.1.2
20:16:41 dnsmasq[7964]: reply europe-west1-gcp.api.snapchat.com is <CNAME>
20:16:41 dnsmasq[7964]: reply europe-west1-gcp.api.sc-gw.com is 35.190.43.134
20:16:57 dnsmasq[7964]: query[A] configuration.apple.com from 192.168.1.131
20:16:57 dnsmasq[7964]: forwarded configuration.apple.com to 1.1.1.2
20:16:57 dnsmasq[7964]: reply configuration.apple.com is <CNAME>
20:16:57 dnsmasq[7964]: reply configuration.apple.com.akadns.net is <CNAME>
20:16:57 dnsmasq[7964]: reply configuration.apple.com.edgekey.net is <CNAME>
20:16:57 dnsmasq[7964]: reply e673.dsce9.akamaiedge.net is 2.16.75.200
20:17:01 dnsmasq[7964]: query[A] gcp.api.snapchat.com from 192.168.1.50
20:17:01 dnsmasq[7964]: forwarded gcp.api.snapchat.com to 1.1.1.2
20:17:01 dnsmasq[7964]: reply gcp.api.snapchat.com is <CNAME>
20:17:01 dnsmasq[7964]: reply gcp.api.sc-gw.com is 35.190.43.134
20:17:12 dnsmasq[7964]: query[A] clients3.google.com from 192.168.1.85
20:17:12 dnsmasq[7964]: forwarded clients3.google.com to 1.0.0.2
20:17:12 dnsmasq[7964]: forwarded clients3.google.com to 1.1.1.2
20:17:12 dnsmasq[7964]: reply clients3.google.com is <CNAME>

Example of Snapchat + ads (in between stories).



uiDivStats search for "snapchat"

Code: 
2021-07-18 18:32    gcp.api.snapchat.com    XXX.XXX.X.XX    type=65    Allowed
2021-07-18 18:32    mvm.snapchat.com    XXX.XXX.X.XX  type=65    Allowed

I see a lot of this in uiDivStats too, I wonder if it's Apple Ads snapchat and other apps use in iOS 14/15?

Code: 
2021-07-18 19:40    cf.iadsdk.apple.com    XXX.XXX.X.XX type=65    Allowed
Click to expand...
From your output, there is no rule listed when you run
Code: 
iptables -nvL INPUT | grep 'pkts\|0000410001'
It was probably removed/not applied during that time. Since you no longer see it in dnsmasq log, looks like it is working. The one in uiDivStats looks like historical records? It will get replaced with new records and there should be no more type=65.
 
chongnt said:
From your output, there is no rule listed when you run
Code: 
iptables -nvL INPUT | grep 'pkts\|0000410001'
It was probably removed/not applied during that time. Since you no longer see it in dnsmasq log, looks like it is working. The one in uiDivStats looks like historical records? It will get replaced with new records and there should be no more type=65.
Click to expand...
maybe a dnsmasq wildcard can be used for all type 65

such as

Code: 
dns-rr=*,65,
 
You must log in or register to reply here.
Similar threads
Thread starter Title Forum Replies Date
Y Diversion Diversion Not Blocking Ads Asuswrt-Merlin AddOns 9
L Diversion Diversion not blocking so many ads - help! Asuswrt-Merlin AddOns 26
C Ad guard fails with mobile devices once Encryption is enabled. Asuswrt-Merlin AddOns 3

Similar threads

Latest threads

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

Members online

Total: 665 (members: 23, guests: 642)
Top