What's new

Asuswrt-Merlin 378.53 is now available

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

The partition should be empty, except for a couple of directories, are you sure that the partition is mounted?

ssh to your router and type this:
cd /jffs
find

it should list some dirs, but that's it.


admin@RT-AC87U-1C70:/jffs# ls -ltr
drwxr-xr-x 2 admin root 0 Jan 1 00:00 configs
drwxr-xr-x 2 admin root 0 May 13 11:30 scripts
-rw-rw-rw- 1 admin root 86064 May 13 12:30 syslog.log
admin@RT-AC87U-1C70:/jffs#
 
admin@RT-AC87U-1C70:/jffs# ls -ltr
drwxr-xr-x 2 admin root 0 Jan 1 00:00 configs
drwxr-xr-x 2 admin root 0 May 13 11:30 scripts
-rw-rw-rw- 1 admin root 86064 May 13 12:30 syslog.log
admin@RT-AC87U-1C70:/jffs#

I deleted the file and system recreated it again ..
 
Syslog.log is alawys recreated to /jffs what ever you do. You can't move it to /mnt for exampel. Thats by design.
 
Last edited:
Syslog.log is alawys recreated to /jffs what ever you do. You can't move it to /mnt for exampel. Thats by design.
The syslog is kept in /tmp, but on the ARM based routers, the syslog is also copied from /tmp to /jffs. If the router reboots, the current /jffs copy is saved and it starts a new copy (so you will end up with two syslogs on /jffs, current and previous). This way if there is a crash and the router reboots you have a chance of seeing what happened in the /jffs copy.
 
The syslog is kept in /tmp, but on the ARM based routers, the syslog is also copied from /tmp to /jffs. If the router reboots, the current /jffs copy is saved and it starts a new copy (so you will end up with two syslogs on /jffs, current and previous). This way if there is a crash and the router reboots you have a chance of seeing what happened in the /jffs copy.
But this documentation says (https://github.com/RMerl/asuswrt-merlin/wiki/JFFS )

I do not recommend doing frequent writes to this area, as it will prematurely wear out the flash RAM. This is a good place to put files that are written once like scripts or kernel modules, or that rarely get written to. Do not put files that get constantly written to (such as logfiles) - store these on a USB disk instead. Replacing a worn out USB flash disk is much cheaper than replacing the whole router if flash sectors get worn out - they have a limited number of write cycles.

documentation and system behavior don't match here
 
But this documentation says (https://github.com/RMerl/asuswrt-merlin/wiki/JFFS )

I do not recommend doing frequent writes to this area, as it will prematurely wear out the flash RAM. This is a good place to put files that are written once like scripts or kernel modules, or that rarely get written to. Do not put files that get constantly written to (such as logfiles) - store these on a USB disk instead. Replacing a worn out USB flash disk is much cheaper than replacing the whole router if flash sectors get worn out - they have a limited number of write cycles.

documentation and system behavior don't match here

Key section here is "constantly written to". Syslog gets only occasional writes to it, it's not the same thing as a webserver logfile that gets multiple writes per minutes, or having a firewall log that stores every single accepted connections.

Also, syslog isn't written directly to JFFS. It's written in RAM, and the firmware only copies it a specific time intervals IF there was any change to it. Logging isn't done directly in flash.

Finally, the Wiki was written back in the day of the RT-N66U, which had a smaller and cheaper NAND. Nobody simply took the time to update it, and there is only so much I can do on my own. I already updated it in a few locations, I just simply don't go over the entire Wiki every time a single thing changes in the firmware.
 
But this documentation says (https://github.com/RMerl/asuswrt-merlin/wiki/JFFS )

I do not recommend doing frequent writes to this area, as it will prematurely wear out the flash RAM. This is a good place to put files that are written once like scripts or kernel modules, or that rarely get written to. Do not put files that get constantly written to (such as logfiles) - store these on a USB disk instead. Replacing a worn out USB flash disk is much cheaper than replacing the whole router if flash sectors get worn out - they have a limited number of write cycles.

documentation and system behavior don't match here

This is a carry over from the ASUS OEM firmware....If you do a forum search, you'll find a lot of discussion on the topic of saving the syslog to the /jffs and how it relates to the specs of the flash used in the ARM routers (The statement in the wiki really applied to the previous gen routers and should be updated). And there is really no way for a user to disable it. Having said that, I provide the option in my fork for those with strong feelings about it to disable it, although I've become less convinced it's something to loose sleep over.

In addition, the direction that ASUS appears to be going is to use the /jffs space for more things (like functions supporting the TrendMicro engine) so it's becoming a moot point anyway.
 
Hi guys,

I have updated my rt-n66u with newest firmware from Merlin (378.53) recently after long time without updates and found that services-start script from jffs is executed before post-mount during boot:
----------
Jan 1 03:00:18 custom script: Running /jffs/scripts/services-start
....
Jan 1 03:00:34 hotplug[758]: USB ext3 fs at /dev/sda1 mounted on /tmp/mnt/sda1
Jan 1 03:00:34 custom script: Running /jffs/scripts/post-mount (args: /tmp/mnt/sda1)
----------


as I remember before services-start was executed after post-mount.
Did I missed something?

just I found that /opt/etc/init.d/rc.unslung start executed from services-start is not working now because entware folder is not linked to /tmp/opt but this is done by script in post-mount.

If such order of script execution (post-mount after services-start) is expected can you please advise how to run /opt/etc/init.d/rc.unslung start correctly?
 
Can somebody confirm this?
If the firewall and 'ssh access from WAN' are disabled at the same time, then ssh from WAN is possible?
 
Can somebody confirm this?
If the firewall and 'ssh access from WAN' are disabled at the same time, then ssh from WAN is possible?

That's normal. If you disable the firewall, then everything on your router is wide open on the WAN side.
 
Hi guys,

I have updated my rt-n66u with newest firmware from Merlin (378.53) recently after long time without updates and found that services-start script from jffs is executed before post-mount during boot:
----------
Jan 1 03:00:18 custom script: Running /jffs/scripts/services-start
....
Jan 1 03:00:34 hotplug[758]: USB ext3 fs at /dev/sda1 mounted on /tmp/mnt/sda1
Jan 1 03:00:34 custom script: Running /jffs/scripts/post-mount (args: /tmp/mnt/sda1)
----------


as I remember before services-start was executed after post-mount.
Did I missed something?

just I found that /opt/etc/init.d/rc.unslung start executed from services-start is not working now because entware folder is not linked to /tmp/opt but this is done by script in post-mount.

If such order of script execution (post-mount after services-start) is expected can you please advise how to run /opt/etc/init.d/rc.unslung start correctly?

There's no chronological order. Scripts are run based on specific events rather than sequentially.

Services-start runs rather early in the boot process, while the other default services are being started. Whether a disk gets mounted during or after this process cannot be predicted.
 
There's no chronological order. Scripts are run based on specific events rather than sequentially.

Services-start runs rather early in the boot process, while the other default services are being started. Whether a disk gets mounted during or after this process cannot be predicted.

hi RMerlin
Thanks for your reply.

Can you please advise what files are correct to put link creation
ln -sf /tmp/mnt/sda1/entware /tmp/opt

and starting rc.unslung
/opt/etc/init.d/rc.unslung start
 
hi RMerlin
Thanks for your reply.

Can you please advise what files are correct to put link creation
ln -sf /tmp/mnt/sda1/entware /tmp/opt

and starting rc.unslung
/opt/etc/init.d/rc.unslung start

Dunno, it's been a long time since I've manually configured any Entware setup. Look at the entware-setup.sh script to see what's required for a manual configuration.
 
I hope someone will be able to help this n00b with his problem. I've noticed this started happening after the latest 378.53 firmware, and I did not have this problem before. Not sure if it's directly connected to the new firmware, but it's my observation and it won't hurt to ask.

Lately I've noticed it takes good 3-6 seconds for my Chrome (even Firefox) to open simple Google search page. I don't use any proxies. The only thing that's different is, I started blocking one URL in my router (don't want my kid to play that game, it has some very bad, not very healthy reviews). I tried network tools / PING and this is my result now:

PING www.google.com (205................): 56 data bytes
64 bytes from 205................: seq=0 ttl=54 time=467.357 ms
64 bytes from 205................: seq=1 ttl=54 time=515.468 ms
64 bytes from 205................: seq=2 ttl=54 time=529.432 ms
64 bytes from 205................: seq=3 ttl=54 time=568.809 ms
64 bytes from 205................: seq=4 ttl=54 time=601.314 ms

--- www.google.com ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 467.357/536.476/601.314 ms

Before my ping was 24 - 40 ms, but this is unusually high now...

I'd appreciate any input guys. Thanks in advance!
 
Last edited:
Also note that many providers will require you to turn off the modem for a given period of time (can vary between 5 and 30 mins) when moving it between two different interfaces (for instance between a PC and a router) for the connection to fully reset.
Definitely true in the case of Time Warner Cable, Cincinnati USA.
 

Sign Up For SNBForums Daily Digest

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