What's new
  • 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!

As per design if you've set the global filter mode to Router, it should still force redirect the clients DNS to router.
Yes, Global Filter Mode is set to Router
Yeah, I also thought that diversion should still filter ads out, but it doesn't seem so.
On my phone, when I go to https://1.1.1.1/help, I see that I'm connected to 1.1.1.1 with DoT.
 
Yes, Global Filter Mode is set to Router
Yeah, I also thought that diversion should still filter ads out, but it doesn't seem so.
On my phone, when I go to https://1.1.1.1/help, I see that I'm connected to 1.1.1.1 with DoT.

Okay DoT is the culprit here, DNSFilter only force redirect DNS queries on port 53 but DoT uses port 853.
 
Okay DoT is the culprit here, DNSFilter only force redirect DNS queries on port 53 but DoT uses port 853.
I am using DoT in Router Global Filter Mode. I do not know of a way for a phone to do DoT on it own, so seeing it on the help page suggests you are going through the router and not using VPN. I can see Diversion working for my phone by grepping the dnsmasq.log. The path is probably different on your router. I might have configured Diversion to do logging and perhaps it is possible not to log.
Code:
grep blockinglist /tmp/mnt/ent/entware/var/log/dnsmasq.log | grep {IPv6 or IPv4 phone address}
 
rep blockinglist /tmp/mnt/ent/entware/var/log/dnsmasq.log | grep {IPv6 or IPv4 phone address}
This is the Entware environment, use the shorter command
Code:
grep blockinglist /opt/var/log/dnsmasq.log | grep {IPv6 or IPv4 phone address}
Also, Diversion has that filtering built in in f, if one takes the time to look for it ;)
 
wouldn't this still send to 853 since dnsmasq listens at 53 and stubby listens at 53 directs to 853 going out?
DNSFilter can block DoT over 853 if the chosen filter mode is known to not support DoT. So most of us using router mode will never notice because Router mode is assumed it might support DoT (not dnsmasq, but the ultimate DoT destination in WAN settings).
 
wouldn't this still send to 853 since dnsmasq listens at 53 and stubby listens at 53 directs to 853 going out?

My answer is for someone who is using DoT on an external device like a mobile/PC and not on the router. In that case router will not intercept dns queries going through port 853 because the global filter mode=Router only works for port 53.
 
Diversion, unfortunately, is extremely sloppy with scripts installed before it - it just deletes them. I mean post-mount and write to the crontab. You can also check the presence of previously installed programs during installation and not touch the records made earlier?
 
@Vladimir, ???

Diversion, amtm, and all the other supported amtm scripts require strict coding requirements (how would they have made it into RMerlin's firmware fork otherwise?).

It may be possibly your coding skills or the scripts you use that are the issue?

Calling Diversion extremely sloppy is not only erroneous, but it is also extremely disrespectful here too.

If there is an issue, why don't you just ask for a solution instead and leave the personal opinions aside?
 
@Vladimir, ???

Diversion, amtm, and all the other supported amtm scripts require strict coding requirements (how would they have made it into RMerlin's firmware fork otherwise?).

It may be possibly your coding skills or the scripts you use that are the issue?

Calling Diversion extremely sloppy is not only erroneous, but it is also extremely disrespectful here too.

If there is an issue, why don't you just ask for a solution instead and leave the personal opinions aside?
Diversion makes all my scripts work better.
 
@Vladimir, ???

Diversion, amtm, and all the other supported amtm scripts require strict coding requirements (how would they have made it into RMerlin's firmware fork otherwise?).

It may be possibly your coding skills or the scripts you use that are the issue?

Calling Diversion extremely sloppy is not only erroneous, but it is also extremely disrespectful here too.

If there is an issue, why don't you just ask for a solution instead and leave the personal opinions aside?
Simple example.
You need to run some script on a schedule. In full accordance with the Merlin instructions, you write the cru a command to the /jffs/scripts/services-start file. Everything works fine.
Then at some point you decide to install Diversion. When you install Diversion, it deletes your /jffs/scripts/services-start file and creates its own instead, and all your entries in the cron are simply deleted.
Questions:
- does this behavior match the expected behavior?
- what does my programming skill have to do with this?
The same applies to your /jffs/scripts/post-mount file, which is simply erased when you install Diversion, and Diversion creates its own file instead.
How else can I call it, other than "extremely sloppy"?

And last.
It seems that without knowing me, you have no reason to speculate about my coding skill, do you? I'm sorry, but based on your answer, you couldn't even understand what I'm writing about.

Diversion makes all my scripts work better.
Without a doubt, this is so :)
 
Last edited:
I don't need to know how to code to know you're not asking in a way to get a positive response. ;)
 
Simple example.
You need to run some script on a schedule. In full accordance with the Merlin instructions, you write the cru a command to the /jffs/scripts/services-start file. Everything works fine.
Then at some point you decide to install Diversion. When you install Diversion, it deletes your /jffs/scripts/services-start file and creates its own instead, and all your entries in the cron are simply deleted.
Questions:
- does this behavior match the expected behavior?
- what does my programming skill have to do with this?
The same applies to your /jffs/scripts/post-mount file, which is simply erased when you install Diversion, and Diversion creates its own file instead.
How else can I call it, other than "extremely sloppy"?

And last.
It seems that without knowing me, you have no reason to speculate about my coding skill, do you? I'm sorry, but based on your answer, you couldn't even understand what I'm writing about.


Without a doubt, this is so :)
At no point is the file ever deleted
The install routine may move the file, but it prints on screen when it does so.
Code:
if [ -f "/jffs/scripts/services-start" ] && grep -q '# DO NOT EDIT' /jffs/scripts/services-start; then
        cp /jffs/scripts/services-start "$entDev/old-jffs_scripts/services-start"
        sed -i '/# DO NOT/,/NOT EDIT #/d' /jffs/scripts/services-start
    fi
Code:
    if [ -f "/jffs/scripts/services-start" ] && grep -q "rc.unslung" /jffs/scripts/services-start; then
        mv /jffs/scripts/services-start /jffs/scripts/obsolete_services-start
        check_nl /jffs/scripts/obsolete_services-start
        echo "# This file was renamed by $NAME, it contains obsolete Entware entries" >>/jffs/scripts/obsolete_services-start
    fi
 
I don't need to know how to code to know you're not asking in a way to get a positive response. ;)
I didn't ask anything. Thank God I can handle it on my own. I only warned about a possible problem.

At no point is the file ever deleted
The install routine may move the file, but it prints on screen when it does so.
Yes, and after that I have to:
- understand what happened
- find where my files were copied
- restore the necessary records.
For all this, you just need to have "programming skills". Not everyone can do it. Isn't it easier to just add your own rules to existing files?
 
I didn't ask anything. Thank God I can handle it on my own. I only warned about a possible problem.


Yes, and after that I have to:
- understand what happened
- find where my files were copied
- restore the necessary records.
For all this, you just need to have "programming skills". Not everyone can do it. Isn't it easier to just add your own rules to existing files?
Please post a copy of your file that gets deleted - that's the only way we'll be able to find out why.
 
Please post a copy of your file that gets deleted - that's the only way we'll be able to find out why.
OK, I'm sorry, I misused the word "deleted", I should have written "removed from the location where it should be". Because of this, there were problems with running my scripts on the crown. But since they run once a week, I was not immediately able to link the problem to the Diversion installation. And the installer's messages - who reads them carefully line by line? And is everyone able to understand that a message like "file so-and-so copied there" is directly related to the work of previously installed scripts?
What is the problem with not removing old files, but adding what is necessary to them?
 
My 87U on 13_4 has been up for 48 hours now. Diversion up to date.

htop is showing me that "/opt/bin/diversion mount" has been running for around 4 hours, using 7 to 13% of CPU. This seems odd to me. Suggestions for what I might be looking for?
 
... Isn't it easier to just add your own rules to existing files?
I agree with this point being made... and I agree that AMTM + Scripts are awesome. I see both sides. My .02.. / An approach like this help / compromise and is what I'd try:

a) copy the file you are modifying in case you really muck it up usually somewhere in the CURRENT directory with a timestamp as part of the name or extension.
b) modify the existing files and add entries.
c) That also means the install code must be able to remove it's own entries and then readd them when it is repeatedly re-installed...without screwing up the existing entries. It's not super hard using SED and AWK but you have be very, very careful. Keep an open mind here guys. I get it. Peace.
 
And the installer's messages - who reads them carefully line by line? And is everyone able to understand that a message like "file so-and-so copied there" is directly related to the work of previously installed scripts?
What is the problem with not removing old files, but adding what is necessary to them?
You can lead a horse to water, they say. That aside.. if you know enough, and care, about how your event scripts work, you should surely be able to understand what the installation messages mean pertaining to them. Would everyone understand? Of course not, which brings us to the answer to the last question - support.

At the risk of putting words into someone else’s mouth, the install process for diversion (and entware for that matter) create a known good configuration file without pulling in someone’s potential nonsense that breaks things. This is the best approach for the common user and the easiest for the script writer to “support” (i.e. provide assistance when something goes wrong). It’s implausible to accommodate all possible edits/configurations people could be trying to bring in because it’s impossible to support.

The diversion project to me seeks to be the lowest common denominator for as wide an audience as possible. If you don’t like the way it installs, your choices as I see it would be to either reinstate your personal changes or not install it to begin with.
 

Sign Up For SNBForums Daily Digest

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