01/14/2017 at 07:52 •
So, it struck me as odd that the log would 'overflow' as it is a ring buffer in ram. It should be bulletproof. Well I was wrong in assuming that it was the log. And I think I may have my real answer. There is a known bug in init.d/network. When you invoke '/etc/init.d/network restart' you are playing russian roulette with the network interface. Sometimes the resources network needs in order to restart have not been released yet. Instead of waiting patiently for those resources, network crashes.
This is the reason cron is able to revive the router.
Read this for more details.
There is a fix. It involves editing part of init.d/network. Just adding a section to bring the wifi network down before attempting to restart the network.
I might just add a sanity check in the script that reboots the entire router when network crashes... Or just invoke 'wifi down' before restarting the network.
01/14/2017 at 05:00 •
So, the messages I have put into the script seem to be overflowing the log buffer and killing the interface. Specifically, when you have none of the devices on the list to connect to. I would love to just snip that message, but I feel that it is a valuable tool for diagnostic should the router go into an unstable mode. I can confirm that it will come out of it's coma if you have a cron job to reset the router. I have made a cron job that resets the router (and subsequently erases the log for the previous day) once a day at 3am to ensure functionality. Should I snip the offending line of code, or does someone have a better idea (or better understanding)?
01/13/2017 at 09:48 •
So, after testing this out for about a week, I can say that this add-on will definitely crash your router about once a day... I think it has something to do with filling the log with messages. I'll get back to you... Going to do a logread from SSH and see where it dies...
01/06/2017 at 08:33 •
Please feel free to message me about things you've noted. Info to submit. Suggestions.