Asuswrt-Merlin 3.0.0.4.374.37 is out

[RMerlin]

After enabled JFFS partition and enable format on next boot, after reboot router i still have unmounted jffs partition in TOOLS>SYSINFO

I have version soft v3.0.0.4.374.37

By this I can not create a script to opt LED at a certain time with this manual:
https://github.com/RMerl/asuswrt-merlin/wiki/Scheduled-LED-control

Sometimes a second reboot is needed.

Also check the System Log for any error message.

 

[TeMpL]

GPL of ASUS RT-AC68U for firmware 3.0.0.4.374.542

 

[RMerlin]

GPL of ASUS RT-AC68U for firmware 3.0.0.4.374.542

Already had a look at it last night, the firmware code was mostly the same (actually slightly older) than 374.2078. I did grab some updated ARM binaries from it tho.

 

[sydlexia]

This is not a bug, this is by design. Asus added that feature a few weeks ago where syslog gets backed up to /jffs so it can survive reboots.

Thanks for the reply Merlin. Ok, I understand what you are saying. My concern is that /jffs is flash memory, seems like this is a bad idea with the frequency of writes to a log file on flash. Am I missing something here?

Can this be modified? I would rather save syslog.log remotely and prolong the life of my flash ram.

 

[pepeEL]

Sometimes a second reboot is needed.

Also check the System Log for any error message.

Ok works. But in /jffs/ i have a file SERVICES-START which content:

#!/bin/sh
cru a lightsoff "0 22 * * * /jffs/scripts/ledsoff.sh"
cru a lightson "0 8 * * * /jffs/scripts/ledson.sh"


In /jffs/scripts/

i have a ledsoff.sh and ledson.sh

After restart from console i put cru l and i have nothing.
Why ?


When i run script ledsoff.sh and ledson.sh LED on/off works. But didnt work about set hours.

 

[saintdev]

Ok works. But in /jffs/ i have a file SERVICES-START which content:

First, this needs to be in /jffs/scripts/. Second, file names are case sensitive and must be lowercase.

 

[pepeEL]

The name is lowercase.
services-start must be in / jffs / scripts?

 

[leewilko]

Already had a look at it last night, the firmware code was mostly the same (actually slightly older) than 374.2078. I did grab some updated ARM binaries from it tho.

Hi,

So am i best to stay on the stock Asus 3.0.0.4.374_542 firmware or use your latest Merlin version? I wasnt sure if you would advise to use your last one or the latest Asus one?

Many Thanks

Lee

 

[RMerlin]

Thanks for the reply Merlin. Ok, I understand what you are saying. My concern is that /jffs is flash memory, seems like this is a bad idea with the frequency of writes to a log file on flash. Am I missing something here?

Can this be modified? I would rather save syslog.log remotely and prolong the life of my flash ram.

The router still writes to the RAM copy in /tmp. It's only a copy that gets stored to jffs, so the amount of flash writes is minimal.

 

[RMerlin]

The name is lowercase.
services-start must be in / jffs / scripts?

All the scripts I document in the README or the Wiki must be in /jffs/scripts/, otherwise the router won't pick it up.

 

[RMerlin]

Hi,

So am i best to stay on the stock Asus 3.0.0.4.374_542 firmware or use your latest Merlin version? I wasnt sure if you would advise to use your last one or the latest Asus one?

Many Thanks

Lee

Depends on your needs. Personally I'd recommend waiting a week or two for the next release.

 

[wis]

I have zero control over the wifi.

There is nothing unusual about having a different signal level, as they are relative. Each router is reporting how strong THEY are receiving the signal from the other router, so the number aren't expected to be identical.

It's like having two person talk to one another. How loud you can hear the other person depends on the quality of your hearing and how loud the other person is speaking. If you whisper and the other person shouts, you will say that you hear him too loud and he'll tell you that he can't hear you. Different sound level.

At high frequencies, signal propagation is not necessarily symmetric due to reflections and absorption. Even if you had ideally matched transmit / receive pairs and signal strength detection, you are pretty much guaranteed to see different levels at each end.

In an open-field test site you could have identical results. Your results are typical of real world antenna placements.

Regards,

-wis

 

[sydlexia]

The router still writes to the RAM copy in /tmp. It's only a copy that gets stored to jffs, so the amount of flash writes is minimal.

That would explain why the two files seem to be slightly out of sync... about 30-60 sec. (see below). It appears to me that /jffs/syslog.log is being written to just as often as /tmp/syslog.log. Perhaps I'm not correctly understanding the implications of frequent/continual writes to flash? (i.e. logfiles or spool dir not good.)

Is there any way to disable this outside of reverting to an earlier firmware build? I really need the functionality of /jffs, and this was a major deciding factor in the purchase of the AC56U.

sysadmin@ldopa:/tmp/home/root# ls -l /tmp/syslog.log /jffs/syslog.log
-rw-rw-rw-    1 sysadmin root        166097 Jan  6 21:46 /jffs/syslog.log
-rw-rw-rw-    1 sysadmin root        166097 Jan  6 21:46 /tmp/syslog.log


sysadmin@ldopa:/tmp/home/root# logger hello

sysadmin@ldopa:/tmp/home/root# ls -l /tmp/syslog.log /jffs/syslog.log
-rw-rw-rw-    1 sysadmin root        166097 Jan  6 21:46 /jffs/syslog.log
-rw-rw-rw-    1 sysadmin root        166129 Jan  6 21:47 /tmp/syslog.log

sysadmin@ldopa:/tmp/home/root# logger 111111111111111111111111111111111111111

sysadmin@ldopa:/tmp/home/root# ls -l /tmp/syslog.log /jffs/syslog.log
-rw-rw-rw-    1 sysadmin root        166129 Jan  6 21:47 /jffs/syslog.log
-rw-rw-rw-    1 sysadmin root        166195 Jan  6 21:48 /tmp/syslog.log


sysadmin@ldopa:/tmp/home/root# tail -4 /tmp/syslog.log /jffs/syslog.log
==> /tmp/syslog.log <==
Jan  6 21:47:18 sysadmin: hello
Jan  6 21:48:15 sysadmin: 111111111111111111111111111111111111111
Jan  6 21:48:35 dnsmasq-dhcp[681]: DHCPREQUEST(br0) 192.168.1.104 00:1f:29:ba:55:23
Jan  6 21:48:35 dnsmasq-dhcp[681]: DHCPACK(br0) 192.168.1.104 00:1f:29:ba:55:23 HPC7250

==> /jffs/syslog.log <==
Jan  6 21:45:50 dropbear[870]: Child connection from 192.168.1.226:1236
Jan  6 21:46:08 dropbear[870]: Password auth succeeded for 'sysadmin' from 192.168.1.226:1236
Jan  6 21:47:18 sysadmin: hello
Jan  6 21:48:15 sysadmin: 111111111111111111111111111111111111111

 

[RMerlin]

Is there any way to disable this outside of reverting to an earlier firmware build? I really need the functionality of /jffs, and this was a major deciding factor in the purchase of the AC56U.

You would probably need to recompile the firmware and disable the JFFS2LOG option.

I think someone once tricked the router into moving the log elsewhere, but I don't remember how. I think he simply created a symlink called /jffs/syslog.log that pointed elsewhere in /tmp - cant remember if the symlink was to a file or a directory however.

 

[XAH]

Is there are any plan to release it for RT-N66U?

 

[connorm]

i am also curious when it will be available for the 66u. as it makes 0 sense why the current release wouldnt be the same or better as my beta that i have been waiting on for over 2 weeks

i use the usb every day never seen or had 1 problem

 

[Spazo]

you guys need to relax a little bit.

He already replied in the topic few days ago

Yes, Asus fixed the issue in the GPL 374.2078 code that they sent me last week. The new version is just not ready for release yet.

It wasn't a USB driver issue BTW, it was a firmware handling code. Asus added support for more than two USB devices, and their code wasn't finalized yet in 374.501. It now is.

 

[pepeEL]

The name is lowercase.
services-start must be in / jffs / scripts?

Can you help me with led on/off at set time... Please

 

[RMerlin]

as it makes 0 sense why the current release wouldnt be the same or better as my beta that i have been waiting on for over 2 weeks

i use the usb every day never seen or had 1 problem

As I explained already, 374.37 uses new USB handling code that doesn't work properly on all routers that have two ports on the same controler. That code wasn't there in 374.36 beta, which was based on older Asus GPL code.

 

[Pir8pete]

As I explained already, 374.37 uses new USB handling code that doesn't work properly on all routers that have two ports on the same controler. That code wasn't there in 374.36 beta, which was based on older Asus GPL code.

NEED TO GET THE MOVE ON GETTING THIS rt-n66u