I have a GL-AR750 connected through wireguard VPN from customer site to my office 24/7. The internet connection at the remote site is wireless. It connects fine via wireguard. After a couple or three days, or so it drops off and then the router has to be rebooted. Usually stays connected approx 3-5 days without a reeboot. It would not cause any issue for me if we could reboot it at midnight or 1am.
How can I use scheduled task to do this?
Your help is appreciated.
You can schedule tasks with cron:
Specifically:
Reboot at 4:30am every day
Note: To avoid infinite reboot loop, wait 70 seconds
and touch a file in /etc so clock will be set
properly to 4:31 on reboot before cron starts.
30 4 * * * sleep 70 && touch /etc/banner && reboot
So from gl-inet web interface go:
More settings > advanced > system > scheduled tasks
Howevre, you have to first ‘restart’ the Cron service to make your edits stick by visiting:
More settings > advanced > system > startup
touch /etc/banner. You will kill the flash memory in no time constantly writing to the memory. Maybe you could restart the wifi with the command wifi instead
All ‘touch’ does is set the file modification date once per day on one single file.
This pales in comparison to the regular every day use of the flash storage on these devices.
This is also the ‘official’ and ‘safe’ method.
Perhaps you might like to substantiate your claims and provide a full alternative command to use with cron rather than a vague suggestion?
The flash memory should never be written once in operation/everything is set. These are embedded devices with limited write cycles. The command to restart
30 4 * * * wifi
Are you suggesting that they are limited in writes in the order of magnitude of… say… 1000 writes. Because that’s roughly how many writes are going to be used using the official Cron entry for 3 years straight.
I don’t think that’s a reasonable assumption at all.
AFAIK these devices function with unionFS so any time there is a modification to a file there is actually still going to be a write made to register that there hasbeen a modification… including bringing the WiFi up and down.
Restart wifi does not write to any flash. Run wifi, leave for 30 mins, reboot the router and check the logread of the time it last remember.
Scheduled Reboot Package? - #6 by hnyman - Installing and Using OpenWrt - OpenWrt Forum. Read Mijzelf post
It’s an interesting suggestion but it does not substantiate anything wrt to flash write issues for a daily file modification.
I would happy to be mistaken on the functioning of Unionfs, but I’m still pretty certain that there are still writes occuring whenever you modify anything (including wifi) - that’s the point of union FS - the original state is safe and preserved, but you can still modify the configuration. Otherwise, you would not even be able to change SSID right?
Is not a change in WiFi state a configuration modification?
wifi is just a command to restart the wireless device. It reads /etc/config/wireless. Maybe this is a better suggestion from Mijzelf post, never try it.
30 4 * * * [ $( cat /proc/uptime | cut -d '.' -f 1 ) -gt 3600 ] && reboot
It doesn’t only read it though does it?..
It flips the “disabled=0” to “disabled=1” and then back again no?
I really could be wrong, but I am not convinced that there is any tangible issue with ‘touching’ one file on the filesystem once per day…
In either case, the relevant files in both our examples are mounted with Union FS so I cannot see why there would be any difference one way or another.
There is no systemd AFAIK so I assume that the mantra ‘everything is a file’ still prevails in openwrt (meaning that any change to config involves writing to a file).
I would really love to see the errors of my ways - there’s always more to learn.
Not convinced yet though 
There is a button on the Web gui to reboot. Why can I not just schedule to “press” that button at 4:30am?
I read this thread about the clock and touch the file… What happens in the code when I press the reboot button on the web gui. Can we not just mimic that?
That button is probably an API call to gl-inet proprietary firmware that probably only calls the ‘reboot’ command.
The issue is only that these devices do not have a real-time clock built in so it is possible to end up in a situation where they are stuck in a perpetual reboot - hence the times delay and file modification.
That is solved with the timing in the Cron job I linked.
What @sammo is suggesting is that this ‘official’ solution can cause premature degradation of the flash memory.
I believe that this is completely out of proportion, and that @sammo’s alternative is likely to be no better wrt to flash degradation.
Having quickly read-up on this out of curiosity I am still inclined to believe that the official solution is completely acceptable:
https://forum.archive.openwrt.org/viewtopic.php?id=55982
I think that the flash degradation is overblown and a bit of an ‘old wife’s tale’ at this stage.
@craignog you should be fine following the official example - I have seen it proposed before by @alzhao in this forum if that adds any legitimacy.
Thank you for your responses!
I think I will try the reboot.
Just do an sync and reboot it is OK.
sync is useful for some Nand models that it writes the data to Nand flash. Otherwise you may lose some data.
Hey @alzhao … so you suggest:
30 4 * * * sleep 70 && touch /etc/banner && sync && reboot
for NAND?
And in the case of GL AR750S which is NOR if I am not mistaken then the original command is better?
for both Nor and Nand you can do a sync.
So just add sync and reboot. Your command looks good.
Wed May 20 12:27:14 2020 kern.notice kernel: [ 0.000000] Linux version 4.14.180 (builder@buildhost) (gcc version 7.5.0 (OpenWrt GCC 7.5.0 r11063-85e04e9f46)) #0 Sat May 16 18:32:20 2020
root@repeater:~# date; touch /etc/banner
Wed May 20 16:00:27 BST 2020
root@repeater:~# reboot
root@repeater:~# Connection to 192.168.17.1 closed by remote host.
Connection to 192.168.17.1 closed.
ssh root@192.168.17.1
root@192.168.17.1’s password:
BusyBox v1.30.1 () built-in shell (ash)
root@repeater:~# logread|head -1
Wed May 20 16:00:34 2020 kern.notice kernel: [ 0.000000] Linux version 4.14.180 (builder@buildhost) (gcc version 7.5.0 (OpenWrt GCC 7.5.0 r11063-85e04e9f46)) #0 Sat May 16 18:32:20 2020
root@repeater:~# date; wifi
Wed May 20 16:03:01 BST 2020
root@repeater:~#
root@repeater:~# reboot
root@repeater:~# Connection to 192.168.17.1 closed by remote host.
Connection to 192.168.17.1 closed.
ssh root@192.168.17.1
root@192.168.17.1’s password:
root@repeater:~# logread|head -1
Wed May 20 16:00:34 2020 kern.notice kernel: [ 0.000000] Linux version 4.14.180 (builder@buildhost) (gcc version 7.5.0 (OpenWrt GCC 7.5.0 r11063-85e04e9f46)) #0 Sat May 16 18:32:20 2020
root@repeater:~#
As you can see, restarting wifi does not write to any files.
There are so many so call scripters thinking they are using a regular linux box and dont treat embedded devices differently.
Hey pal I would like some actual evidence that nothing is written to the flash in one way or another… Perhaps your example is going over my head but it does nothing to proven once and for all that nothing is written to disk when invoking the WiFi command. Perhaps you could take the time to explain your demonstration.
To really be convincing however, you would need to explain how configuration changes are possible with out writing anything to disk on unionfs mounted filesystem.
Then I would like some actual evidence that the limited writing that is allegedly occuring will cause any meaningful damage to the flash storage in any meaningful way.
You have done neither, and are resorting to being rude.
I genuinely would like to be proven wrong on either account but you are neither substantiating, nor backing up your claims with any explanation.
I do not believe that you actually understand this enough to really explain your point at this stage, but am happy to be proven wrong if you are willing to take the time to do so.
May be package named watchcat? It puts scripts in cron like all people said before in posts but sometimes is easier to use luci-apps, no?
As a follow up.
I used
30 4 * * * sleep 70 && touch /etc/banner && sync && reboot
It works great. Before the router would loose its wifi wan connection, now the router reboots and reconnects to the wifi once per day it has saved me asking the customer to reboot the router every 5 or so days when we noticed it was not connecting to VPN.
Thanks!