I am no longer moving forward with this project as Openwrt supports multiple wireless access points with existing Travelmate package.
An automatic switch between known APs.
To make the experience fit your profile, pick a username and tell us what interests you.
We found and based on your interests.
I am no longer moving forward with this project as Openwrt supports multiple wireless access points with existing Travelmate package.
OpenWRT_wifiMgr_v0.3.5.zipx-zip-compressed - 72.63 kB - 01/15/2017 at 08:21 |
|
|
wifiMgrwifimgr - 266.00 bytes - 01/15/2017 at 08:21 |
|
|
apconnectionlog.htmHyperText Markup Language (HTML) - 423.00 bytes - 01/06/2017 at 08:30 |
|
|
wifiMgr.shBourne Shell Script - 4.48 kB - 01/06/2017 at 08:30 |
|
|
wifiMgrcfgwifimgrcfg - 871.00 bytes - 01/06/2017 at 08:30 |
|
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.
Thoughts?
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)?
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...
Please feel free to message me about things you've noted. Info to submit. Suggestions.
Create an account to leave a comment. Already have an account? Log In.
Become a member to follow this project and never miss any updates