I have this in my /jffs/scripts/wan-start script
Code:#!/bin/sh logger "WAN Up: New IP address is $(nvram get wan_ipaddr)" sleep 20 killall wan_check.sh /mnt/usb4gb/wan_check.sh &
and the contents of my usb mounted wan_check.sh script
Code:#!/bin/sh #space separated list of hosts to check HSTS="$(nvram get wan_gateway) $(nvram get wan_dns) 8.8.8.8 8.8.4.4" # No of times to check each host before trying next TRIES=3 # How often to check in seconds if OK TCHECK=30 # How long to wait if all hosts fail TFAIL=10 # How many fails before restarting with dhcpc_renew NFAIL=3 chk=0 LG(){ echo "wan_check: $@"|/usr/bin/logger -s } CHK(){ cnt=0 chk=0 while [ $cnt -lt $TRIES ]; do if /bin/ping -c 1 $@ >/tmp/wan_check.log; then chk=1 break else sleep 1 let cnt=cnt+1 fi done } dn=0 LG monitoring WAN connection using ping while [ $dn -lt $NFAIL ]; do for h in $HSTS; do UP=0; CHK $h if [ $chk -gt 0 ]; then UP=1 break else LG ping check failed $h fi done if [ $UP -gt 0 ]; then dn=0 sleep $TCHECK else let dn=dn+1 sleep $TFAIL fi done LG "renewing dhcp wan" killall -USR1 udhcpc sleep 30 service restart_wan
It's a modded version of something I found on the net. It is slow to detect a fault because my ISP seems to drop ping packets when line is very busy, and I don't want false restarts of the wan. There's another variant around that reboots the router if the restart_wan doesn't work. The first 2 ips to ping are not correct nvram vars if you try dual wan.
I'll probably try your fork, I dragged this further for a combination of laziness and little timeRecovering from a modem reboot is actually quite difficult due to all the state changes the modem goes thru and the fact that a lot of the router recovery is event driven. I did quite a bit of work on my fork to try and improve things, and have tested it quite a bit on the AC68 (along with simulated power fails where I drop and restore the power to both the modem and router). I'd be interested in any feedback if you decide to try it on the N66.
But, I'd be more concerned about what is causing the reboot to begin with when you answer a call. Best case the recovery will take a couple of minutes, and I think that would be pretty disruptive.
Recovering from a modem reboot is actually quite difficult due to all the state changes the modem goes thru and the fact that a lot of the router recovery is event driven. I did quite a bit of work on my fork to try and improve things, and have tested it quite a bit on the AC68 (along with simulated power fails where I drop and restore the power to both the modem and router). I'd be interested in any feedback if you decide to try it on the N66.
But, I'd be more concerned about what is causing the reboot to begin with when you answer a call. Best case the recovery will take a couple of minutes, and I think that would be pretty disruptive.
Welcome To SNBForums
SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.
If you'd like to post a question, simply register and have at it!
While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!