What's new

Prevent and Stop WAN connection unless Diversion and USB device is working!

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

Aziron5

Occasional Visitor
Hello

I wanted to find a solution for this for quite some time, keeping being a problem yet again. It's a bit of a long story but whenever there's maintenance of networking, there's a chance the attached USB device is removed or whatever that makes diversion stop, but WAN can keep working, while restarting diversion requires more manual work and attention. There's also not a big enough indications that diversion isn't running!

I would like to completely and strongly prohibit WAN from being allowed unless AMTM / Entware, Diversion and the supporting USB device where installations, swap and logs are, is fully loaded and operational.

This goes for boot ups, as well as live interruptions. It should prohibit WAN only after these conditions are met, and it would disable WAN when actions that stop any of these components are done.
So that when an USB ejection is detected, either in GUI, SSH or physically unplugging, diversion being shutdown, upgraded or reinstalled, it would stop WAN right there ASAP, re-enabling it after everything's done.
Except when updating Diversion lists, there should be no need to restart WAN.

I would really hope if this would be possible, perhaps requiring custom FW support? Perhaps through scripts right now?

Thank you very very much, and if this is a worthwhile feature for the rest of the community, let it be a standard option in AMTM/Diversion/Merlin, that would be great! Thanks again
 
Last edited:
Additionally, for status reporting, perhaps SNMP or something similar could be used to report AMTM/Entware/Diversion/USB status and an utility app in linux or tray application in Windows created for using these SNMP reports for notifications.

Perhaps something around this already exists or is possible DIY with scripts/tools?

Exposing such status for SNMP must first be supported by the FW, if it'll be possible at all?
 
And why is this so necessary? Your router needs external DNS and NTP server during bootup process. Diversion is just one of the many limited functionality DNS-based ad-blockers with relatively easy way to go around it. Why do you want to bring the entire system reliability down to the reliability of your USB drive?
 
There's also not a big enough indications that diversion isn't running!

I would like to completely and strongly prohibit WAN from being allowed unless AMTM / Entware, Diversion and the supporting USB device where installations, swap and logs are, is fully loaded and operational.
I don't personally use diversion but suggested something like the following for a forum user years ago.

Basically you would need to check if /opt is mounted or the existence of a specific file in this case diversion...either in init-start and or firewall-start by calling the following script

e.g. /jffs/scripts/WAN_Diversion_KILLSwitch.sh
Code:
#!/bin/sh

WAN_IF=$(ip route | awk '/^default/{print $NF}')

if [ -f /jffs/scripts/WaitForDiversion.sh ] & [ ! -f /opt/share/diversion/.conf/diversion.conf]; then

    for ACTION in D I
        do
            iptables -$ACTION FORWARD -i br0 -o $WAN_IF -m state --state NEW -j REJECT --reject-with icmp-host-prohibited 2>/dev/null
            iptables -$ACTION FORWARD -i br0 -p tcp -o $WAN_IF -m state --state NEW -j REJECT --reject-with tcp-reset      2>/dev/null
        done
      
    STATE="ON"

    logger -st "($(basename $0))" "WAN KILL-Switch" $STATE

    sh /jffs/scripts/WaitForDiversion.sh &
fi

/jffs/scripts/WaitForDiversion.sh
Code:
#!/bin/sh

WAN_IF=$(ip route | awk '/^default/{print $NF}')

DIVERSION_STATUS="Unknown"

while true

    do
  
        [ -f /opt/share/diversion/.conf/diversion.conf] && DIVERSION_STATUS=$(grep -E "^DIVERSION_STATUS" /opt/share/diversion/.conf/diversion.conf)

        [ "$DIVERSION_STATUS" == "enabled" ] && break

        sleep 1
    done


iptables -D FORWARD -i br0 -o $WAN_IF -m state --state NEW -j REJECT --reject-with icmp-host-prohibited 2>/dev/null
iptables -D FORWARD -i br0 -p tcp -o $WAN_IF -m state --state NEW -j REJECT --reject-with tcp-reset        2>/dev/null

STATE="OFF"

logger -st "($(basename $0))" "WAN KILL-Switch" $STATE

Not sure if this still works.
 
Last edited:
And why is this so necessary? Your router needs external DNS and NTP server during bootup process. Diversion is just one of the many limited functionality DNS-based ad-blockers with relatively easy way to go around it. Why do you want to bring the entire system reliability down to the reliability of your USB drive?

I've expected that I would need to explain a little bit, no problem. If it means gathering more enthusiasm and user demand for such features to become standard then I can certainly do more to help.

One category of reasons that is that we are increasingly sorroudned by various kind of variously intrusive, obsessive, assertive or even deceitful applications in general and when it comes to various data that they transmit back over the internet connection , be it it their authors, managers and/or 3rd-parties, to engage in various unwelcome activities, some of which affects the user experience and functionality of the application in a negative way.
Sometimes such actions may spill over and affect the entire system or even other applications.

I found Diversion to be a great low-cost solution for prohibiting such unwanted behavior and such similar use cases. Perhaps I'm not familiar with alternative or even better solutions for that, but I can imagine enterprise sector has something much more professional for such purposes for a long time, that's above my budget.

Most applications have a relative moderate internet connection (network requests) polling, some are light and do it on fixed schedules, or only at launch/shutdown of themselfs. Operating Systems themselfs can have similar activities, especially those which are from a very commercial author.
However some of the most popular and daily driven applications and those with Cloud features, such as certain web browsers are extremely agressive in demanding internet connection for various unseen background activities, and if these applications detect network problems they even increase their poll-rates significantly, spamming DNS and other requests.
Web browsers and embedded browser libary driven applications (non-user-configurable) are topping the offender list, they're increasingly becoming walled-garden System-Within-A-System type of applications that are creating their own fundamental rules and enforcements and have some of the most agressive network behavior.
In such a case they will ofcourse detect WAN connection the very second it's up. I've noticed that in an event of a router reboot and other cases, WAN may be established before AMTM/Entware/Diversion is ready.
There is no point in using Diversion if WAN is allowed full access even for just a few secons or minutes, even on a sporadic monthly basis, because such agressive applications may already perform these unwanted activities, receive new "commands" and data to behave differently, in some cases they can even permanently change their behavior.

Unwanted activities are such as forced and/or stealth changes to settings, configurations, even system settings, unneeded data gathering and other privacy type issues, activities of preinstalled bloatware apps on mobile phones and devices, security and ofcourse agressive and immoral advertising, among other potential activities I can't recall right now.

Still, many of these applications so far do not actually require always-on internet connection for a lot of their core functionalities, and disabling specific network components doesn't interfere with others, so this is why the use of Diversion in a single place, the main router, is an extremely effective and much more elegant and practical solution in comparison to using the Windows/Linux hosts file for each PC/installation separately.

Compromise Solution:
The router's FW could continue to have early WAN access for core maintenance services, NTP and other useful auxiliaries, just don't allow WAN to reach LAN (downstream clients), to decouple LAN as per default and only link LAN with WAN once everything's clear.
If this ever reaches the FW feature support, I would even expand the GUI on the front main page to include such separation and visibly show WAN/LAN status and linkage.

I've created this draft picture to show the example:
(once I started working on it the idea just went off a bit, heh it shouldn't hurt)

In this kind of a usecase, reliability of internet for the sake of it is not the priority, simply put, I do not care about losing connection to IRC/Discord/a Multiplayer game/etc briefly.
I would treat the loss of WAN if diversion can't do it's job as normal operation. Diversion is implemented as an addon script, right, but in practice I treat it as something what should be part of the FW and normal routine operations, the reason for a separated and delayed modular approach to me is just due to having technical and budgetary limitations.
 
Anything using DoH goes straight through your Diversion.
 
Hopefully in time we would deal with that as well. Unfortunately these technologies are a big double-edged sword it seems, seems to empower such malicious actors to sliently do things over the internet without owner's insight.

I should have the right to decide what kind of data will or will not flow through devices that I own. As far as I know, I bought my router, I didn't license it. Encrypted data that is created by a computer and it's applications and the encrypted data that is shared between two trusted parties should be decryptable by either of them. Isn't the point of encryption all about data protecttion while en-route, while being transported ?!?!

EDIT: I do have it disabled in Firefox, but I now see it was enabled in Brave, if that's the same thing, because I still keep seeing Type 65 requests for some brave specific domans (and others) while disabling "Secure DNS".
I didn't bother reading up on Type 65 and DoT, DoH in depth as far as dealing with it goes because I don't really run anything that uses it, except I guess Brave browser, which so far I only use sporadically for a few specific things.
But ofcourse, adoption will grow.
 
Last edited:

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