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.
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.
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?
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:
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:~# Connection to 192.168.17.1 closed by remote host.
Connection to 192.168.17.1 closed.
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
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.
As a follow up.
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.