What's new

3.0.0.4.384.45717 removes X attribute in /jffs files

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

Ronald Schwerer

Very Senior Member
Maybe it's been mentioned before and I missed it. I just noticed that, on a reboot, all my executable files in /jffs and below had their X attribute removed. This includes the .asusrouter script I used to schedule some cron housekeeping. I believe this is a new "feature". I saw this on all three of my RT-AC68Us only after installing
3.0.0.4.384.45717. One is configured as the AiMesh network router, one is a node, and one is a repeater.

Has anyone else seen this and is there any way around it (other than installing Merlin)? If this was an intentional change by ASUS, I find it offensive. I want control of my hardware and my scripts are none of ASUS's business.
 
Last edited:
I know why Asus did this, and while it was with good intentions, it was a bad idea. They should have removed that change from future releases AFAIK.

The implication that installing 45717 could prevent switching to Merlin

No, it does not. Totally unrelated, and won't prevent switching either.
 
I know why Asus did this, and while it was with good intentions, it was a bad idea. They should have removed that change from future releases AFAIK.
So it sounds like it might be fixed in a future release. Until then, I'll just need to remember to chmod all my files and manually launch .asusrouter after each reboot.
 
This is really bad. I was on vacation and didn't notice it till today. I rely on .asusrouter and my own script to detect if wan0 is down and turn on a warning light behind my TV to avoid streaming video on wan1, a mobile hotspot.
 
This is really bad. I was on vacation and didn't notice it till today. I rely on .asusrouter and my own script to detect if wan0 is down and turn on a warning light behind my TV to avoid streaming video on wan1, a mobile hotspot.
I found several workarounds. The simplest one requires a USB stick or drive mounted to your router.
If necessary add a line in your .asusrouter script to add-back the X attribute to any local scripts it runs. Example:
Code:
chmod 744 /jffs/my_utility_script.sh  /jffs/my_other_script.sh

Now set a command to run whenever a USB storage device is mounted:
Code:
nvram set script_usbmount="chmod 744 /jffs/.asusrouter;/jffs/.asusrouter"
nvram commit

Reboot the router, and .asusrouter will run when the USB device auto-mounts. I assume the specified script_usbmount command will run each time a drive mounts, so you might need to consider the consequences of this if you have 2 USB drives, or you occasionally swap drives. To make sure it only runs once per boot cycle, add this before any critical code in your .asusrouter script:
Code:
mkdir  /home/root/.asusrouterlock || exit
 
Last edited:
Thanks. I used script_usbmount a year ago before I discovered .asusrouter on this forum. I just thought .asusrouter was more elegant.

You don't need chmod to execute a script. Using the shell is sufficient.
Code:
nvram set script_usbmount="/bin/sh /jffs/scripts/my_script.sh"
nvram commit
 
After installing firmware version 384.81039 it no longer removes the execute permission from the files, but /jffs/.asusrouter still doesn't run.
 
After installing firmware version 384.81039 it no longer removes the execute permission from the files, but /jffs/.asusrouter still doesn't run.
More "fixes" huh? Seems they intentionally want to break this capability. Well, as long as the script pointed to by script_usbmount works, I'm OK.

Haven't tried 384.81039 yet. Curious to see what else they broke.
 
More "fixes" huh? Seems they intentionally want to break this capability.

That script was a major issue, since it would still run after a factory default reset. So a single malicious or buggy script stored there would be next to impossible to remove by end-users. Removing it was the sensible thing to do.
 
That script was a major issue, since it would still run after a factory default reset. So a single malicious or buggy script stored there would be next to impossible to remove by end-users. Removing it was the sensible thing to do.
I always assumed /jffs got initialized during a factory reset. How about a physical NVRAM erase (holding WPS during power On)? I just have never tried because either of these since I didn't want to do it at the time.
 
Last edited:
I always assumed /jffs got initialized during a factory reset. How about a physical NVRAM erase (holding WPS during power On)? I just have never tried because either of these since I didn't want to do it at the time.
Neither will erase the jffs partition.

Sent from my SM-T720 using Tapatalk
 
Is this issue fixed with firmware version 3.0.0.4.384.81049?
It depends on what you mean by "fixed". I have not installed 384.81049, but I briefly installed 384.81039. It no longer removed the 'X' attribute in /jffs, but it seems to of totally removed my .asusrouter script. I think this "feature" is also in 384.81049.
So they have changed the problem. As RMerlin stated - to keep malicious code from locking the router. Seems the best fix is to use
Code:
nvram set script_usbmount=some command
to execute a command when a USB device gets mounted.

By using an indirection to a removable device, the security concerns are mitigated since once the device is removed, you can regain control of a hacked router.
 
Last edited:
I'm using a different technique to execute my script.
Code:
nvram set jffs2_exec=/jffs/boot_runscript
I will give firmware version 3.0.0.4.384.81049 a try.
 
I'm using a different technique to execute my script.
Code:
nvram set jffs2_exec=/jffs/boot_runscript
I will give firmware version 3.0.0.4.384.81049 a try.

That no longer works with 81049.
 

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