Diversion Diversion 5.1.3 - the Router Ad-Blocker, May 09, 2024

[rtn66uftw]

Diversion update to 5.1.3 frozen at "blocking list" step. What should I do? Thank you!

Enter amtm option  1

  !  Diversion update detected

  i  Running function auto-update now
  i  Downloading latest installer file from diversion.ch
  v  install.div         integrated

  i  Checking router
  v  Asuswrt-Merlin
  v  Wireless router mode
  v  dos2unix
  v  Dnsmasq version 2.90
  i  Router check complete

  i  Checking dnsmasq.conf.add entries
  v  dnsmasq.conf.add

  i  Probing for Entware
  v  Entware is installed

  i  Downloading Diversion from diversion.ch
  v  exclude-devices.div integrated
  v  functions.div       integrated
  v  helper.div          integrated
  v  install.div         integrated
  v  post-conf.div       integrated
  v  rotate-logs.div     integrated
  v  update-bl.div       integrated
  v  webui.zip           downloaded
  v  webui.zip           extracted
  v  write-config.div    integrated
  v  webui.zip           downloaded
  v  webui.zip           extracted

  i  Checking allowlist and denylist
  v  Allowlist
  v  Denylist

  i  Checking /jffs/scripts entries
  v  dnsmasq.postconf
  v  post-mount
  v  services-stop
  v  unmount (Diversion)
  v  service-event (Diversion WebUI)

  i  Initializing Diversion

  v  WebUI               remounted
  v  blocking list

 

[rtn66uftw]

btw, in diversion, I excluded some devices using DNS Director. Today I checked and the devices which were on exclusion list couldn't connect to the internet. Was there any update that broke this function?
Edit: after rebooting the router, I couldn't connect to the internet from any device until I unplugged the USB out.
Diversion was set to auto-update so any time I tried to access it from either amtm or diversion command in the terminal, it launched the auto-update process and got stuck at "blocking list". How do I disable it? I tried on the Asus interface but the button slided back on right away
(in the interface, it showed version 5.1.1 but in the amtm terminal it showed 5.1.3, how's it possible?)

 

[JimbobJay]

/opt/share/diversion/file/post-conf.div includes variable CONFIG definition of CONFIG=$1 in the file which is passed on when running certain scripts. In this case "$1" is /etc/dnsmasq.conf

So does that mean when postconf scripts are run automatically by the fw in their usual way, the

CONFIG=$1

variable gets accounted for by the fw because of the file that the postconf is working on? i.e. dnsmasq.postconf knows it's editing /etc/dnsmasq.conf so the fw uses uses that file for the $1 variable?

Which explains why I was seeing these issues when manually running the dnsmasq.postconf?

Sorry, I'm fairly new to coding and scripts so just trying to learn

 

[dave14305]

variable gets accounted for by the fw because of the file that the postconf is working on? i.e. dnsmasq.postconf knows it's editing /etc/dnsmasq.conf so the fw uses uses that file for the $1 variable?

You can see here that when postconf is invoked, it passes the config file path.

asuswrt-merlin.ng/release/src/router/rc/services.c at 466f5aee9e274971480a19497573c4264f865019 · RMerl/asuswrt-merlin.ng

Third party firmware for Asus routers (newer codebase) - RMerl/asuswrt-merlin.ng

github.com

 

[JimbobJay]

You can see here that when postconf is invoked, it passes the config file path.

asuswrt-merlin.ng/release/src/router/rc/services.c at 466f5aee9e274971480a19497573c4264f865019 · RMerl/asuswrt-merlin.ng

Third party firmware for Asus routers (newer codebase) - RMerl/asuswrt-merlin.ng

github.com

Ahh, I see! Great! This helps me understand why I was seeing the issues I did when manually running it. Thanks so much!

 

[Treadler]

2024-05-27 06:43	t.nineanalytics.io	2404:xxxx	HTTPS	Allowed
2024-05-27 06:43	t.nineanalytics.io	2404:xxxx	AAAA	Allowed
2024-05-27 06:42	t.nineanalytics.io	2404:xxxx	AAAA	Blocked
2024-05-27 06:42	t.nineanalytics.io	2404:xxxx	HTTPS	Blocked

Interesting, UiDivstats reporting a domain in blocked list as ‘sometimes’ being allowed?

Not noticed with any other domain, just this one.

 

[SomeWhereOverTheRainBow]

2024-05-27 06:43	t.nineanalytics.io	2404:xxxx	HTTPS	Allowed
2024-05-27 06:43	t.nineanalytics.io	2404:xxxx	AAAA	Allowed
2024-05-27 06:42	t.nineanalytics.io	2404:xxxx	AAAA	Blocked
2024-05-27 06:42	t.nineanalytics.io	2404:xxxx	HTTPS	Blocked

Interesting, UiDivstats reporting a domain in blocked list as ‘sometimes’ being allowed?

Not noticed with any other domain, just this one.

If you can, please manually inspect generated diversion blocklist and report back how the entry is listed/reported inside the file. Also, do you have any devices being redirected with DNSDirector to any source other than the router himself?

 

[Treadler]

If you can, please manually inspect generated diversion blocklist and report back how the entry is listed/reported inside the file. Also, do you have any devices being redirected with DNSDirector to any source other than the router himself?

09:13:26 dnsmasq[13933]: reply t.nineanalytics.io is NODATA
09:13:26 dnsmasq[13933]: query[HTTPS] t.nineanalytics.io from 2404:xxxx
09:13:26 dnsmasq[13933]: config t.nineanalytics.io is NXDOMAIN
09:13:27 dnsmasq[13933]: dnssec-query[DS] nineanalytics.io to 127.0.1.1
09:13:27 dnsmasq[13933]: reply t.nineanalytics.io is NODATA-IPv6
09:13:27 dnsmasq[13933]: query[AAAA] t.nineanalytics.io from 2404:xxxx
09:13:27 dnsmasq[13933]: config t.nineanalytics.io is NXDOMAIN
09:13:27 dnsmasq[13933]: reply nineanalytics.io is no DS
09:13:27 dnsmasq[13933]: reply t.nineanalytics.io is 34.110.168.46

 

[Treadler]

If you can, please manually inspect generated diversion blocklist and report back how the entry is listed/reported inside the file. Also, do you have any devices being redirected with DNSDirector to any source other than the router himself?

No, no redirections, everything pointed to router.

 

[SomeWhereOverTheRainBow]

09:13:26 dnsmasq[13933]: reply t.nineanalytics.io is NODATA
09:13:26 dnsmasq[13933]: query[HTTPS] t.nineanalytics.io from 2404:xxxx
09:13:26 dnsmasq[13933]: config t.nineanalytics.io is NXDOMAIN
09:13:27 dnsmasq[13933]: dnssec-query[DS] nineanalytics.io to 127.0.1.1
09:13:27 dnsmasq[13933]: reply t.nineanalytics.io is NODATA-IPv6
09:13:27 dnsmasq[13933]: query[AAAA] t.nineanalytics.io from 2404:xxxx
09:13:27 dnsmasq[13933]: config t.nineanalytics.io is NXDOMAIN
09:13:27 dnsmasq[13933]: reply nineanalytics.io is no DS
09:13:27 dnsmasq[13933]: reply t.nineanalytics.io is 34.110.168.46

I am curious as to why a request is being forwarded to 127.0.1.1, are you running stubby?
It appears dnsmasq is still forwarding this request to stubby despite it being blocked?
Could it be because dnsmasq recognizes 127.0.1.1 to be a local namespace so it is talking to it to see if it can get a response? (just curious)
Try adding address=/t.nineanalytics.io/# or local=/t.nineanalytics.io/ to /jffs/configs/dnsmasq.conf.add then run service restart_dnsmasq from the ssh terminal. Run the same test using each method. Report back the log entries here. You can also try local=/t.nineanalytics.io/#

 

[Treadler]

I am curious as to why a request is being forwarded to 127.0.1.1, are you running stubby? it appears dnsmasq is still forwarding this request to stubby despite it being blocked?
Try adding address=/t.nineanalytics.io/# or local=/t.nineanalytics.io/ to /jffs/configs/dnsmasq.conf.add then run service restart_dnsmasq from the ssh terminal. Run the same test using each method. Report back the log entries here. You can also try local=/t.nineanalytics.io/#

Using DoT + DNSSEC.
DoT uses stubby I think?

 

[SomeWhereOverTheRainBow]

Using DoT + DNSSEC.
DoT uses stubby I think?

That is correct, and it's listen address is 127.0.1.1:53. Here is the real question, if it is blocked with dnsmasq using local=/t.nineanalytics.io/ in the blocklist, why is dnsmasq forwarding the request to stubby? Why is it even asking stubby about the query? Could it be because dnsmasq recognizes 127.0.1.1 to be a local namespace so it is talking to it to see if it can get a response? (just curious) Because it appears dnsmasq is not satisfied with the NXDOMAIN, or NODATA response's. Look at my previous posts and try my requests to see which one changes this behavior. Also, double check your allow-listings inside diversion and make sure you haven't accidentally allow-listed this domain.

 

[Treadler]

Seems to randomly ‘not block’, sometimes!

09:44:03 dnsmasq[13933]: reply t.nineanalytics.io is NODATA-IPv6
09:44:03 dnsmasq[13933]: reply t.nineanalytics.io is 34.110.168.46
09:44:03 dnsmasq[13933]: reply t.nineanalytics.io is NODATA
09:44:03 dnsmasq[13933]: query[AAAA] t.nineanalytics.io from 2404:xxxx
09:44:03 dnsmasq[13933]: config t.nineanalytics.io is NODATA-IPv6
09:44:03 dnsmasq[13933]: query[HTTPS] t.nineanalytics.io from 2404:xxxx
09:44:03 dnsmasq[13933]: config t.nineanalytics.io is NODATA
09:44:56 dnsmasq[13933]: query[A] t.nineanalytics.io from 2404:xxxx
09:44:56 dnsmasq[13933]: config t.nineanalytics.io is NXDOMAIN
09:45:23 dnsmasq[13933]: reply t.nineanalytics.io is NODATA
09:45:23 dnsmasq[13933]: query[HTTPS] t.nineanalytics.io from 2404:xxxx
09:45:23 dnsmasq[13933]: config t.nineanalytics.io is NXDOMAIN
09:45:23 dnsmasq[13933]: reply t.nineanalytics.io is NODATA-IPv6
09:45:23 dnsmasq[13933]: query[AAAA] t.nineanalytics.io from 2404:xxxx
09:45:23 dnsmasq[13933]: config t.nineanalytics.io is NXDOMAIN
09:45:23 dnsmasq[13933]: reply t.nineanalytics.io is 34.110.168.46

(I haven’t messed with the dnsmasq.conf yet).

 

[SomeWhereOverTheRainBow]

Seems to randomly ‘not block’, sometimes!

09:44:03 dnsmasq[13933]: reply t.nineanalytics.io is NODATA-IPv6
09:44:03 dnsmasq[13933]: reply t.nineanalytics.io is 34.110.168.46
09:44:03 dnsmasq[13933]: reply t.nineanalytics.io is NODATA
09:44:03 dnsmasq[13933]: query[AAAA] t.nineanalytics.io from 2404:xxxx
09:44:03 dnsmasq[13933]: config t.nineanalytics.io is NODATA-IPv6
09:44:03 dnsmasq[13933]: query[HTTPS] t.nineanalytics.io from 2404:xxxx
09:44:03 dnsmasq[13933]: config t.nineanalytics.io is NODATA
09:44:56 dnsmasq[13933]: query[A] t.nineanalytics.io from 2404:xxxx
09:44:56 dnsmasq[13933]: config t.nineanalytics.io is NXDOMAIN
09:45:23 dnsmasq[13933]: reply t.nineanalytics.io is NODATA
09:45:23 dnsmasq[13933]: query[HTTPS] t.nineanalytics.io from 2404:xxxx
09:45:23 dnsmasq[13933]: config t.nineanalytics.io is NXDOMAIN
09:45:23 dnsmasq[13933]: reply t.nineanalytics.io is NODATA-IPv6
09:45:23 dnsmasq[13933]: query[AAAA] t.nineanalytics.io from 2404:xxxx
09:45:23 dnsmasq[13933]: config t.nineanalytics.io is NXDOMAIN
09:45:23 dnsmasq[13933]: reply t.nineanalytics.io is 34.110.168.46

(I haven’t messed with the dnsmasq.conf yet).

I am wondering if you try any of the previous listings i mentioned inside dnsmasq.conf.add if it will change the behavior after you restart dnsmasq. One thing i can tell though is if you are manually requesting the lookup, then that wouldn't explain the resolution issue. It does appear that you may have a client on your network who is not happy with the NODATA/NXDOMAIN responses, hence why it continues making the request very often- unless that is you manually doing it from the client.

 

[Treadler]

I am wondering if you try any of the previous listings i mentioned inside dnsmasq.conf.add if it will change the behavior after you restart dnsmasq. One thing i can tell though is if you are manually requesting the lookup, then that wouldn't explain the resolution issue. It does appear that you may have a client on your network who is not happy with the NODATA/NXDOMAIN responses, hence why it continues making the request very often- unless that is you manually doing it from the client.

No, not doing it manually. Clearly the site/s in question are being very insistent!

 

[SomeWhereOverTheRainBow]

No, not doing it manually. Clearly the site/s in question are being very insistent!

Or the device making the request is being very insistent. Here is what pihole says about NXDOMAIN blocking:

Diversion sets up DNSMASQ to use NXDOMAIN blocking, where as Pihole defaults to NULL blocking (e.g. address=/t.nineanalytics.io/#). hence my curiosity for investigating the behaviors. But without you doing additional testing following my inquires in the previous post, or access to any of your diversion files (e.g. the blocklist and allowlists which is generated by diversion), it may be impossible to identify why this behavior is happening. To determine what is happening, you have to investigate using dns tools (e.g dig), and try various blocking methods to determine if behaviors are specific to how your blocking is currently configured. It is like peeling the layers back on an onion. If you are concerned about your devices reaching out to this domain, you can always block the IP address (34.110.168.46) associated with it via the Skynet script.

 

[dave14305]

Seems to randomly ‘not block’, sometimes!

It would be helpful if you enabled log-queries=extra in Diversion's dnsmasq settings (ds). It would show which query is being replied to with the IPv4 address. Surely it wouldn't be the AAAA (IPv6) query, so it must be the HTTPS query, but shouldn't respond.

What blocklist are you using? That domain isn't blocked by oisd.nl (small or big).

 

[SomeWhereOverTheRainBow]

It would be helpful if you enabled log-queries=extra in Diversion's dnsmasq settings (ds). It would show which query is being replied to with the IPv4 address. Surely it wouldn't be the AAAA (IPv6) query, so it must be the HTTPS query, but shouldn't respond.

What blocklist are you using? That domain isn't blocked by oisd.nl (small or big).

Yea, I played around using dig and couldn't figure it out. If log-queries=extra doesn't help, it would be nice to know the blocklist (and possibly anything allowlisted). The only other logs I was curious about was:

09:13:27 dnsmasq[13933]: dnssec-query[DS] nineanalytics.io to 127.0.1.1
09:13:27 dnsmasq[13933]: reply t.nineanalytics.io is NODATA-IPv6
09:13:27 dnsmasq[13933]: query[AAAA] t.nineanalytics.io from 2404:xxxx
09:13:27 dnsmasq[13933]: config t.nineanalytics.io is NXDOMAIN
09:13:27 dnsmasq[13933]: reply nineanalytics.io is no DS

which was shared in a previous post.

 

[Treadler]

That domain is in the Hagezi ‘ultimate’ list. That’s where I first noticed its odd behaviour in UiDivstats. I’ve since returned to a ‘sane’ blocklist which doesn’t include that domain. (I’ve added it to the Diversion deny list, just because……curious).
Now using Hagezi Pro, & Oisd large. Nothing allow listed by me.

 

[SomeWhereOverTheRainBow]

That domain is in the Hagezi ‘ultimate’ list. That’s where I first noticed its odd behaviour in UiDivstats. I’ve since returned to a ‘sane’ blocklist which doesn’t include that domain. (I’ve added it to the Diversion deny list, just because……curious).
Now using Hagezi Pro, & Oisd large. Nothing allow listed by me.

Yea I was just taking a look at Hagezi Pro++ to see if it was listed in that one. Hagezi Pro++ blocks nineanalytics.io but not exclusively t.nineanalytics.io. I don't know if local=/nineanalytics.io/ includes all subdomains though. I thought you would need something like local=/#.nineanalytics.io/. This may just be an undesired behavior of dnsmasq. I know with unbound local-zone: "nineanalytics.io." always_nxdomain includes all subdomains. From what I can tell though local=/nineanalytics.io/ should be enough to cover itself and all subdomains, but i could be wrong.