Diversion Diversion *not* working after installation due to erroneously inserted/added lines of code.

[Martinski]

For over a year now I've been wanting to install & use Diversion (i.e. the Router Ad-Blocker, pka AB-Solution) on my home router but never had time available. However, lately, with everyone in the household working from home or taking classes remotely for many months now due to the coronavirus pandemic, we've become more keenly aware of how ubiquitously intrusive a lot of web ads have become in the past few years, especially those pop-up ads that suddenly appear either dead center on the screen or to the side on top of an online article you've just started to read a few seconds before. I'm certain that I don't have to tell you how f'ing annoying those online ads are (excusez mon français :>).

So last night I decided to install Diversion Standard via amtm and check out how effective its ad-blocking capabilities are. Unfortunately, my initial impressions were not good at all due to what I consider to be installations or setup bugs. Before I start to explain, let me provide the initial installation context:

Router: RT-AC86U
Firmware: AsusWRT-Merlin 384.19_0
AMTM 3.1.8 version
One 32GB USB 3.1 Flash Drive on USB 3.0 Port (1 partition, ext4 format with journaling, ~26GB free)
One 128GB USB 3.0 Flash Drive on USB 2.0 Port (2 partitions, NTFS format, ~115GB free)
2GB swap file on 32GB USB 3.1 Drive.
Entware installed on 32GB USB 3.1 Drive.
Custom shell scripts: init-start, services-start, post-mount, unmount, dnsmasq.postconf, service-event-end, and my own scripts which are called from within those already listed.
No other 3rd-party shell scripts.

The problem was that after installing Diversion and rebooting the router twice, I did not notice any difference in the number of web ads being shown on various websites. In addition, I found a couple of clues which indicated that something had gone awry during the installation or initial configuration:

a) The Diversion CLI menu showed this line:

ep pixelserv-tls 172.25.250.2 (not running)

b) The system log file had this line:

Dec 1 19:54:24 Diversion: pixelserv-tls or Diversion disabled, not starting pixelserv-tls


After looking further at the log entries, I also noticed clues that 3 of the existing custom shell scripts had been modified during installation, and some new lines of code had been appended to or inserted in the wrong place, effectively rendering the necessary changes moot.

The "post-mount" shell script
---------------------------------
The "post-mount" shell script was modified with the insertion of the following 2 lines:

swapon /tmp/mnt/MyUSBDisk1/MySwapFile.swp # Added by amtm

. /jffs/addons/diversion/mount-entware.div # Added by Diversion

The "swapon" line above was inserted as the 2nd line in the script, but this was not necessary as that same line existed already in the script (I've had the swap file set up & running fine for almost a year now). But what made things worse is that the already existing "swapon" line was removed without any concern for the contextual construct in which the line was originally found (in this case, an if-statement).

The "mount-entware.div" line above was appended to the end of the script as the last line *AFTER* an existing "exit 0" line, leaving the newly inserted code with no effective and practical purpose because it would never be reached and executed. Also (as with the "swapon" line), that same line already existed in the script but was removed without any concern (again) for the contextual construct in which it was initially found.

The end result was that the custom script was left with 2 major errors:
- An existing "if statement" was left without any actual statements, which is a syntax error.
- The last inserted line is effectively useless and serves no purpose where it was placed.

Below are snippets of the script that shows what I just described.

ORIGINAL code in "post-mount" script *BEFORE* installation:

#!/bin/sh
########################################################
# ...[CUSTOM COMMENTS REMOVED]
########################################################
...[CUSTOM CODE REMOVED]

if [ -n "$1" ] && [ "$1" == "$MyUSB1_MOUNTpath" ]
then
   # ADD-ONS #
   swapon /tmp/mnt/MyUSBDisk1/MySwapFile.swp
   . /jffs/addons/diversion/mount-entware.div
   # ADD-ONS #
fi

_AddDebugLogMsgs_ "$EXIT_TAG" "OK: Exit."
exit 0
#EOF:post-mount#

MODIFIED code in "post-mount" script *AFTER* installation:

#!/bin/sh
swapon /tmp/mnt/MyUSBDisk1/MySwapFile.swp # Added by amtm
########################################################
# ...[CUSTOM COMMENTS REMOVED]
########################################################
...[CUSTOM CODE REMOVED]
if [ -n "$1" ] && [ "$1" == "$MyUSB1_MOUNTpath" ]
then
   # ADD-ONS #
   # ADD-ONS #
fi
_AddDebugLogMsgs_ "$EXIT_TAG" "OK: Exit."
exit 0
#EOF:post-mount#
. /jffs/addons/diversion/mount-entware.div # Added by Diversion

As you can see above, the installation setup changes make the script fail and error out during execution.

[Continues on next post]...

 

[Martinski]

[Continues 2nd part]

The "unmount" shell script
-------------------------------
The "unmount" shell script was modified with the insertion of the following 2 lines:

[ "$(/usr/bin/find $1/entware/bin/diversion 2> /dev/null)" ] && diversion unmount # Added by Diversion

[ "$(/usr/bin/find $1/MySwapFile.swp 2> /dev/null)" ] && swapoff $1/MySwapFile.swp # Added by Diversion

Both of these lines were appended to the end of the file as the last lines *AFTER* an existing "exit 0" line, leaving the newly inserted code, again, with no effective and practical purpose because those lines would never be reached and executed where they are. See the snippet below showing the code placement error.

MODIFIED code in "unmount" script *AFTER* installation:

#!/bin/sh
########################################################
# ...[CUSTOM COMMENTS REMOVED]
########################################################
...[CUSTOM CODE REMOVED]
if [ -n "$1" ] && [ "$1" == "$MyUSB1_MOUNTpath" ]
then
   # ADD-ONS #
   # ADD-ONS #
fi
_AddDebugLogMsgs_ "$EXIT_TAG" "OK: Exit."
exit 0
#EOF:unmount#
[ "$(/usr/bin/find $1/entware/bin/diversion 2> /dev/null)" ] && diversion unmount # Added by Diversion
[ "$(/usr/bin/find $1/MySwapFile.swp 2> /dev/null)" ] && swapoff $1/MySwapFile.swp # Added by Diversion

The "dnsmasq.postconf" shell script
-----------------------------------------
The "dnsmasq.postconf" shell script was modified with the insertion of the following line:

. /opt/share/diversion/file/post-conf.div # Added by Diversion

But, again, this line was appended to the end of the file *AFTER* an existing "exit 0" line, leaving the newly inserted code with no effective and practical purpose because it would never be executed. See the snippet below showing the code placement error.

MODIFIED Code in "dnsmasq.postconf" script *AFTER* installation:

#!/bin/sh
########################################################
# ...[CUSTOM COMMENTS REMOVED]
########################################################
...[CUSTOM CODE REMOVED]

_AddDebugLogMsgs_ "$EXIT_TAG" "OK: Exit."
exit 0
#EOF:dnsmasq.postconf.sh#
. /opt/share/diversion/file/post-conf.div # Added by Diversion

So, in effect, all of these errors left the Diversion installation in a "bad state." Now, I could easily "fix" those incorrectly placed lines of code by moving them to the appropriate places within each of the modified scripts, but after I did exactly that, some of the "fixes" are actually removed again whenever I launch Diversion CLI menu or change some configuration settings in Diversion (e.g. both "unmount" & "post-mount" scripts get modified again & again as described above). I also could remove the "exit 0" lines in my scripts to allow the newly appended lines to be executed, but none of that actually fixes the cause of the problem.

After more trial & error, I finally figured out that the installation/configuration setup code that looks for the required lines, removes them if found, and inserts or appends a new line, seems to be looking for the code *WITHOUT* any LEADING BLANK chars; otherwise, it decides to remove such a line and replace it by inserting it somewhere else in the script.

For example, the following line is OK (no leading blank chars). When found, the setup installer leaves it alone where it is:

swapon /tmp/mnt/MyUSBDisk1/MySwapFile.swp

However, the very same line indented within the following if-statement causes the setup installer to remove it and insert it somewhere else, leaving a syntactically incorrect if-statement behind:

if [ -n "$1" ] && [ "$1" == "$MyUSB1_MOUNTpath" ] ; then
    swapon /tmp/mnt/MyUSBDisk1/MySwapFile.swp
fi

With this knowledge in mind, the simplest temporary "fix" was actually to remove all leading blank chars from each of the existing lines which makes the Diversion setup installer happy so that it does not replace any existing lines, and inserts the required line only when not already found in the script. So far so good.

 

[Martinski]

[Continues 3rd part]

As mentioned at the beginning of my post, all these installation errors have left me with a bad impression of the utility. This kind of "look-for-specific-line-and-remove-and-replace" bug is a simple rookie mistake to make, and I don't know why it has not been found or reported before during testing or by other users (at least I didn't find any post about this in my search). So this experience didn't give me a lot of confidence in the quality of the code and in the kind of testing it has gone through. Yes, I know: it's a free utility and can't really complain too much since I have not paid any money for it. But still, a lot of us s/w developers, colleagues I know and work with tend to take a high degree of pride in their development work and have an almost visceral disdain for bugs found in their own code, especially for such rookie mistakes, so I will assume that the developer in charge of the Diversion installation setup script has that same perspective. Perhaps I'm being too harshly critical of the bugs found, but I'm trying to provide some constructive criticism here so if my comments don't come off with that tone and tenor, I apologize in advance as I mean no offense, especially to the @thelonelycoder.

IMO, the setup/installation code should be modified so that when looking for the required lines in each of the known custom shell scripts, all leading blank chars should be ignored by taking the variable where the found string is being stored temporarily and stripping all leading blanks from it, and then continue with the string comparison being done to check if it matches the required line to be inserted or appended. As to the bug where the lines are appended to the script *after* an existing "exit 0" line, perhaps you can also do a search for the last "exit" line and insert the new required lines *before* such "exit" line. I realize that this can become a lot more complicated if several "exit" lines exist, but I'd say that in the standard custom scripts there's usually only one "exit" line at the end of the file. At least, that's the standard practice I follow whenever I write a script that's being called from an essentially "black box" (i.e. unknown caller).

Anyway, that's my feedback & suggestion so that the installation setup code can be fixed & improved in the future.

 

[Martineau]

As to the bug where the lines are appended to the script *after* an existing "exit 0" line, perhaps you can also do a search from the last "exit" line and insert the new required lines *before* such "exit" line. I realize that this can become a lot more complicated if several "exit" lines exist, but I'd say that in the standard custom scripts there's usually only one "exit" line at the end of the file. At least, that the standard practice I follow whenever I write a script that's being called from an essentially "back box" (i.e. unknown caller).

I'm sure the developer would actually welcome a fully coded pull request for your solution to eradicate this annoying 'bug'?

FYI.....I believe only my unbound_manager script attempts to identify/ensure the correct 'insertion point' line in the target script when installing itself as an add-on script, (see Smart_LineInsert() ) but it isn't 100% foolproof unless the explicit insertion marker is defined.

Given most (non-techie) users don't manually create scripts, or more to the point, for those that do, even fewer are old-skool programmers who were taught to formally always code the (if applicable) 'exit' statement (REXX anyone?) as the last line, so I suspect in 99.99% of the unbound installs the need for the execution of the Smart_LineInsert() function by unbound_manager is actually redundant/irrelevant.

P.S. Might be useful if you could tag your post title with the Diversion topic prefix.

 

[Martinski]

I'm sure the developer would actually welcome a fully coded pull request for your solution to eradicate this annoying 'bug'?

I don't have a coded shell script solution that I can provide. I'm a C, C++, C# and Java s/w developer by training & by trade and that's where my main skills & strengths lie. I write shell scripts (bourne, bash, csh) only as needed to automate mostly simple, routine, repetitive tasks at work or at home. If I get some free time, I could try to come up with some coded function but I can't make any commitments at this moment - although with Christmas vacation coming up soon I could set aside some time for it. We'll see.

Given most (non-techie) users don't manually create scripts, or more to the point, for those that do, even fewer are old-skool programmers who were taught to formally always code the (if applicable) 'exit' statement (REXX anyone?) as the last line, so I suspect in 99.99% of the unbound installs the need for the execution of the Smart_LineInsert() function by unbound_manager is actually redundant/irrelevant.

Yes, that's likely very true. It's really a very small percentage of non-techie people that would put an "exit" line at the end of their custom scripts. WRT the Smart_LineInsert() function, I don't consider any code that handles "boundary conditions" or "edge cases" (which perhaps happen to occur very rarely) redundant or irrelevant. IMO, the frequency of execution doesn't necessarily dictate its importance or necessity in the overall design or functionality of a piece of software.

P.S. Might be useful if you could tag your post title with the Diversion topic prefix.

Done. Thanks for the suggestion.

 

[thelonelycoder]

I'm not able to check or verify anything of the above at this time. Looks like I'm a total newbie at coding and a fool while attempting to throw together some code.
I WILL look into it when time allows to either better my code or dispute my desicions that I made at the time.

 

[Mutzli]

Diversion installs very clean if you follow the instructions to a t. Make sure that you prep the router correctly and reserve an IP space for pixelserv to work in before starting the installation. I usually have the LAN IP's set to 192.168.1.1 and the DHCP Server Pool starting at 192.168.1.3. This leaves the 192.168.1.2 for pixelserv.
Over the years I have installed Diversion many times on several router models and all without any 'coding' issues.

 

[elorimer]

There is this convention among the add on developers to add one line only to the scripts they share in common, to call more sophisticated things elsewhere. I think you have uncovered why that convention exists.

None of the originating scripts have exit lines or if statements, and generally install through amtm in a fairly coherent manner. The scripts that are called have all that kind of complexity.

My suggestion would be for you to backup the originating scripts where you have your own customization, delete them, install the add on scripts you want from scratch, and then insert your own customizations back in to taste.

Then, you could offer up here your customizations, and why you have them, for the interest of the community.

EDIT: for greater clarity

 

[Treadler]

I'm not able to check or verify anything of the above at this time. Looks like I'm a total newbie at coding and a fool while attempting to throw together some code.
I WILL look into it when time allows to either better my code or dispute my desicions that I made at the time.

No fool, definitely no fool......
Diversion transformed the internet experience on my network, just sayin’.

 

[Martinski]

Looks like I'm a total newbie at coding and a fool while attempting to throw together some code.

Easy there, man. I think you're overreacting with unnecessary self-chastisement. If I understand correctly, your Diversion "4.0" project (with all new code) for AsusWRT-Merlin had its very 1st release on August 25, 2018, so it's been "out in the wild" for a bit over 2 years and it can be considered relatively new (IMO), which means that the code may still need more time to grow, mature and become more robust. There will always be bugs to find and fix - that's just the nature of the beast.

Sometimes those bugs will be simple rookie mistakes (which we have all made more than once before); other times they might be major bugs requiring some architectural changes or redesign. Regardless of the types of bugs, the key is to do an analysis of the root cause, fix the problem, and move on, hopefully with greater knowledge and better coding skills. It's been my experience that we learn more and gain greater insight from our mistakes than from the things we do right, and this includes our coding/programming mistakes.

Based on what I've read and seen in this forum, you've done a pretty good job so far, doing the best you can at the time, fixing problems, and supporting your customers as your time allows, for free. That's an admirable and honorable thing to do, so take credit where credit is due.

Finally, remember the old saying:
"The software isn't finished until the last user is dead."

 

[Martinski]

Diversion installs very clean if you follow the instructions to a t.

Do those installation instructions plainly state that at least 4 custom user scripts (post-mount, unmount, dnsmasq.postconf, services-stop) will be created if not found, or modified when found, during the configuration setup?

Do those instructions also state that if any of those custom user scripts are found, they should not have any "exit" statement at the end of the file?

Do those instructions clearly point out that any existing lines of code previously inserted into the custom scripts by amtm (for swap support) or entware (apparently an initial diversion hook-up) cannot have any leading blank spaces?

If the answer is yes, would you please provide a link to those instructions?

If the answer is no, I'm not sure what you mean by saying "Diversion installs very clean if you follow the instructions to a t" since it doesn't seem to add any insight to be able to address the issues found in the use case scenario I described in my original post.

Note that I'm not disputing that Diversion installs fine in "most" cases. My post simply exposes/explains a scenario in which the installation clearly fails and leaves behind some syntactically incorrect user scripts. By any standards, that end result is not a desirable state. Even if the use case scenario does not happen for most users, and perhaps it's extremely rare, the bug is still there.

 

[Martinski]

There is this convention among the add on developers to add one line only to the scripts they share in common, to call more sophisticated things elsewhere. I think you have uncovered why that convention exists.

I fully agree with that convention and that's, in fact, a good coding practice I like to follow in my own scripts as much as possible.

None of the originating scripts have exit lines or if statements, and generally install through amtm in a fairly coherent manner. The scripts that are called have all that kind of complexity.

Just to be clear, by "originating scripts" I think you're referring to the custom user scripts available in the RMerlin F/W. If so, note that those scripts are for *users* to freely *customize* (within reason and for the specific purposes that they were made available) with valid and syntactically correct statements. I have not read of any restrictions in the RMerlin F/W or add-ons documentation that says users should not create, modify or customize those scripts as needed (again with valid, syntactically correct statements).

WRT "complexity" in the custom scripts, apparently we have a vastly different definition and understanding of what complexity means in terms of s/w development. For example, you seem to be saying that "exit" lines and "if" statements may be "too complex" to be placed in the custom user scripts. Frankly, that would be a silly restriction to have. If the following statement in the "post-mount" script is "too complex" to handle, one really has no business developing code:

if [ -n "$1" ] && [ "$1" == "$MyUSB1_MOUNTpath" ] ; then
    swapon /tmp/mnt/MyUSBDisk1/MySwapFile.swp
fi

Note that the above "if" statement was written so that the "swapon" call is made *ONLY* when the correct USB Partition Mount Point is passed as argument to the "post-mount" script. Without the conditional check, the call is executed every time *any* USB drive is inserted into USB 3.0 & 2.0 ports, and for *each* separate partition that each of the flash drives may have. In my particular case, I happen to have 2 USB flash drives mounted, with a total of 3 partitions, but only one has the swap file. It's simply good coding practice to make sure that you have the right partition before performing an operation on it. Why call the function 3 times when only 1 is necessary & sufficient?

My suggestion would be for you to backup the originating scripts where you have your own customization, delete them, install the add on scripts you want from scratch, and then insert your own customizations back in to taste.

Why would I do that if I already found a solution/workaround for the badly placed lines of code that I found initially after installation? It would be unproductive to do all that without getting any further benefit after what I've already done.

 

[JaimeZX]

So... with the caveat that "I'm not a coder," and with zero intention of casting aspersions, I think the OP's approach here is well-intentioned and poorly-phrased.

OP would have been better-served by contacting thelonleycoder directly with his specific concerns and specific recommendations for fixes. That is:

Change lines 9-12 from XYZ123 to ABC456 #this accomplishes such-and-such while preserving so-and-so
Change lines 78-93 from UVW789 to DEF012 #this accomplishes so-and-so while preserving such-and-such

Obviously no piece of code is ever perfect, but something that works for the vast majority of users the vast majority of the time deserves the benefit of the doubt. Coming in with a "it doesn't work for my edge case so the developer is obviously a n00b" attitude (intended or not) doesn't serve anyone well... the developer is unnecessarily insulted, the OP gains nothing, and the discussion is otherwise irrelevant to nearly everyone else on the forum.

 

[Martinski]

So... with the caveat that "I'm not a coder," and with zero intention of casting aspersions, I think the OP's approach here is well-intentioned and poorly-phrased.

Thank you for letting me know that I apparently failed to communicate clearly my intentions by using poorly chosen words in some of my posts.

Perhaps I'm being too harshly critical of the bugs found, but I'm trying to provide some constructive criticism here so if my comments don't come off with that tone and tenor, I apologize in advance as I mean no offense, especially to the @thelonelycoder.

I thought that with the above I was making it clear that I sincerely meant no offense to the developer, @thelonelycoder, by posting my feedback, analysis, assessment, and initial impressions. However, it seems that my presentation was still, as you succinctly put it, poorly phrased. Again, I apologize to the @thelonelycoder if he feels disrespected in any way.

Perhaps part of the misunderstanding comes from my view that when reporting a bug and making an assessment of the probable root cause, it's not a personal attack on the developer writing the software. Coding is what we do, but not what we are. One can make "simple rookie mistakes" without being a rookie/noob oneself. As mentioned before, I, as a developer, have made such mistakes at one time or another before, and there's no shame or guilt associated with it - it just happens sometimes. I simply fix it and move on. From my perspective, when assessing/reviewing/vetting a piece of code, a s/w module, a utility, I'm simply making judgment calls on the code behavior, not on the person who wrote it. This is just part of what we do as professional programmers.

In any case, I hope this has now clear the air.

As the saying goes:
"We all make stupid mistakes, but that does not make us all stupid."

 

[JaimeZX]

This is why I assumed noble intent in the post, and perhaps all will be forgiven, what with it being so close to Festivus and the associated ceremonial Airing of Grievances.

Reporting of Bugs ought, of course, to be welcomed. The manner in which one does this will impact the reception of the message.

 

[elorimer]

Why would I do that if I already found a solution/workaround for the badly placed lines of code that I found initially after installation?

I had it in mind then you could share it with the rest of us. There are thousands of installs with the code you found problematic.

You will have seen that, in the main, I think, the convention is for the install routine for the 18 or so add-ons to add one line to each relevant user script (that is, the scripts the firmware looks for) with a comment about what script added it, and for the uninstall routine to delete that one line. That line then refers to the whole coding ecosystem of the addon. The convention is further not to mess with someone else's line. There isn't much cleverness about inserting the line. This isn't a diversion thing, per se.

That convention is stable enough that amtm is now incorporated in the firmware, so I think there would be some reluctance to fiddle with it.

 

[thelonelycoder]

The "swapon" line above was inserted as the 2nd line in the script, but this was not necessary as that same line existed already in the script (I've had the swap file set up & running fine for almost a year now). But what made things worse is that the already existing "swapon" line was removed without any concern for the contextual construct in which the line was originally found (in this case, an if-statement).

amtm and Diversion contain a check that omits adding the SWAP mounting line to post-mount. Quoting from my release notes of Diversion 4.1.3 on July 13 2019 here:

Adding a commented 'do-not-check-swap' (without the quotes) anywhere to /jffs/scripts/post-mount will read indented swap code and not correct paths (Diversion 4.1.3 and amtm 2.6 and later)

Why one would add an exit command to a script directly in a standardized JFFS user file is a mystery to me. I do not presume that the code I add to any of the files in JFFS are the only ones, I would never dare to stop any execution of following code in a file that may be used by others.

The "mount-entware.div" line above was appended to the end of the script as the last line *AFTER* an existing "exit 0" line, leaving the newly inserted code with no effective and practical purpose because it would never be reached and executed. Also (as with the "swapon" line), that same line already existed in the script but was removed without any concern (again) for the contextual construct in which it was initially found.

See above.

After more trial & error, I finally figured out that the installation/configuration setup code that looks for the required lines, removes them if found, and inserts or appends a new line, seems to be looking for the code *WITHOUT* any LEADING BLANK chars; otherwise, it decides to remove such a line and replace it by inserting it somewhere else in the script.

I have my solid reasons to remove certain code that may interfere with my own code. I make sure the single line that my scripts add is not commented and NOT encapsulated in some other if statement. This unforgiving method is proven countless times with the existing user base success cases. It also proves to be good coding for my sanity as I am tired of the same old errors users posted regularly on this board before I implemented my solution.

Perhaps I'm being too harshly critical of the bugs found, but I'm trying to provide some constructive criticism here so if my comments don't come off with that tone and tenor, I apologize in advance as I mean no offense, especially to the @thelonelycoder.

IMO, the setup/installation code should be modified so that when looking for the required lines in each of the known custom shell scripts, all leading blank chars should be ignored by taking the variable where the found string is being stored temporarily and stripping all leading blanks from it, and then continue with the string comparison being done to check if it matches the required line to be inserted or appended. As to the bug where the lines are appended to the script *after* an existing "exit 0" line, perhaps you can also do a search for the last "exit" line and insert the new required lines *before* such "exit" line. I realize that this can become a lot more complicated if several "exit" lines exist, but I'd say that in the standard custom scripts there's usually only one "exit" line at the end of the file. At least, that's the standard practice I follow whenever I write a script that's being called from an essentially "black box" (i.e. unknown caller).

Give us coders a break. We adhere to the standard that we agreed upon. We all stick to it, any script that gets added to amtm will be checked by me for this and other things that I find important.
Your edge case is a true exception to the rule and I encourage you to take heed of the suggestions by others in this thread to follow our standard.
As for my scripts logic they remain as they are. The decisions I made how to do things are based on years long coding for these routers. I kept in mind that other coders may add to the user scripts that amtm and Diversion create, and I make sure mine and others continue to work after.
You should do the same.

Do those installation instructions plainly state that at least 4 custom user scripts (post-mount, unmount, dnsmasq.postconf, services-stop) will be created if not found, or modified when found, during the configuration setup?

Do those instructions also state that if any of those custom user scripts are found, they should not have any "exit" statement at the end of the file?

This is Asuswrt-Merlin firmware. The way coders can add/remove/modify system files in a consistent and simple way IS through the user files. How else do you think we add the functionality for the addons we code?
This should be expected in my humble opinion. Does any other program or app warn you that it will modify common system files or settings on your phone, computer or other device? I don't think so.

As the saying goes:
"We all make stupid mistakes, but that does not make us all stupid."

Well said, and have a good day.

 

[RMerlin]

. We adhere to the standard that we agreed upon.

Thanks for digging this thread up, I just moved it to the AddOns subforum for easier discoverability.

 

[JT Strickland]

No fool, definitely no fool......
Diversion transformed the internet experience on my network, just sayin’.

He ain't no spring chicken that rode in here on a turnip truck, neither.
I might be, but he ain't.

 

[thelonelycoder]

He ain't no spring chicken that rode in here on a turnip truck, neither.
I might be, but he ain't.

These folks sell and fix things, while I code and also fix things, at 50+.