What's new

WANFailover Dual WAN Failover Script

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

This may be better in my situation anyways, ill have to watch. My primary is starlink. Sometimes I will show connected, but starlink ground infracture has issues alot, ie no internet past the pop.
In my experience that is true, your first hop may be up and running but could be down behind it so targeting something external like Google's server is a true "test".
 
In my experience that is true, your first hop may be up and running but could be down behind it so targeting something external like Google's server is a true "test".
i just went off how you had it setup originally, and recommended. I can do some bash,etc..(I actually used to be a Gentoo dev, that did ALOT of bash, but Ive forgot all that now in my older age). When it comes to routing.. nah. I actually didnt even pay attention to what WanTarget0 was for. Maybe at some point you can get this added to AMTM
 
Last edited:
In my experience that is true, your first hop may be up and running but could be down behind it so targeting something external like Google's server is a true "test".
I just noticed this in the logs after restarting. And far as I know wan1 was already connected.
But its creating a route for wan1 to 0.0.0.0? It looks like its done that all along, but the switchover worked when I tried it .
May not be anything.

5/23/22 @ 11:30:06: ./wanfail.sh - WAN Status: wan0 enabled...
05/23/22 @ 11:30:06: ./wanfail.sh - WAN Status: wan0 is connected...
05/23/22 @ 11:30:06: ./wanfail.sh - WAN Status: Route exists for 8.8.8.8 via 100.64.0.1 dev eth0...
05/23/22 @ 11:30:10: ./wanfail.sh - WAN Status: wan0 has 0% packet loss...
05/23/22 @ 11:30:10: ./wanfail.sh - WAN Status: wan1 enabled...
05/23/22 @ 11:30:10: ./wanfail.sh - WAN Status: wan1 is not connected, attempting to restart interface...
05/23/22 @ 11:30:13: ./wanfail.sh - WAN Status: Creating route 8.8.4.4 via 0.0.0.0 dev eth5...
05/23/22 @ 11:30:13: ./wanfail.sh - WAN Status: Created route 8.8.4.4 via 0.0.0.0 dev eth5.
 
This may be better in my situation anyways, ill have to watch. My primary is starlink. Sometimes I will show connected, but starlink ground infracture has issues alot, ie no internet past the pop.
Yea and that is one reason I needed the old script deleted before doing this new method that uses the config file, I was pulling an NVRAM variable in the past for a target but with this set up that isn't necessary and won't work with the current set up using the config file.
 
I just noticed this in the logs after restarting. And far as I know wan1 was already connected.
But its creating a route for wan1 to 0.0.0.0? It looks like its done that all along, but the switchover worked when I tried it .
May not be anything.

5/23/22 @ 11:30:06: ./wanfail.sh - WAN Status: wan0 enabled...
05/23/22 @ 11:30:06: ./wanfail.sh - WAN Status: wan0 is connected...
05/23/22 @ 11:30:06: ./wanfail.sh - WAN Status: Route exists for 8.8.8.8 via 100.64.0.1 dev eth0...
05/23/22 @ 11:30:10: ./wanfail.sh - WAN Status: wan0 has 0% packet loss...
05/23/22 @ 11:30:10: ./wanfail.sh - WAN Status: wan1 enabled...
05/23/22 @ 11:30:10: ./wanfail.sh - WAN Status: wan1 is not connected, attempting to restart interface...
05/23/22 @ 11:30:13: ./wanfail.sh - WAN Status: Creating route 8.8.4.4 via 0.0.0.0 dev eth5...
05/23/22 @ 11:30:13: ./wanfail.sh - WAN Status: Created route 8.8.4.4 via 0.0.0.0 dev eth5.
It will do that if "nvram get wan1_state_t" doesn't = 2, remember when your interface wouldn't go from Cold Standby to Hot Standby, that is the variable to check for that, 2 is connected or Hot Standby.
 
It will do that if "nvram get wan1_state_t" doesn't = 2, remember when your interface wouldn't go from Cold Standby to Hot Standby, that is the variable to check for that, 2 is connected or Hot Standby.
Its hot, and wan1_state_t shows 2, and wan1_realip_state shows 2, but wan1_realip_ip is empty, even after it restarts it. I assume this is just cosmetic, just letting you know
 
Its hot, and wan1_state_t shows 2, and wan1_realip_state shows 2, but wan1_realip_ip is empty, even after it restarts it. I assume this is just cosmetic, just letting you know
link_wan1=1
switch_wan1prio=0
switch_wan1tagid=
wan1_6rd_ip4size=
wan1_6rd_prefix=
wan1_6rd_prefixlen=
wan1_6rd_router=
wan1_auth_x=
wan1_auxstate_t=0
wan1_clientid=
wan1_clientid_type=0
wan1_desc=
wan1_dhcp_qry=1
wan1_dhcpenable_x=1
wan1_dns=192.168.10.1
wan1_dns1_x=1.1.1.1
wan1_dns2_x=8.8.8.8
wan1_dnsenable_x=1
wan1_enable=1
wan1_expires=92145
wan1_gateway=192.168.10.1
wan1_gateway_x=0.0.0.0
wan1_gw_ifname=eth5
wan1_gw_mac=04:D4:C4:B6:14:40
wan1_heartbeat_x=
wan1_hostname=
wan1_hwaddr=24:4B:FE:2F:D7:D1
wan1_hwaddr_x=
wan1_hwname=
wan1_ifname=eth5
wan1_ipaddr=192.168.10.189
wan1_ipaddr_x=0.0.0.0
wan1_is_usb_modem_ready=0
wan1_lease=86400
wan1_mroute=
wan1_mtu=1500
wan1_nat_x=1
wan1_netmask=255.255.255.0
wan1_netmask_x=0.0.0.0
wan1_phytype=
wan1_ppp_echo=1
wan1_ppp_echo_failure=10
wan1_ppp_echo_interval=6
wan1_pppoe_ac=
wan1_pppoe_auth=
wan1_pppoe_hostuniq=
wan1_pppoe_idletime=0
wan1_pppoe_ifname=
wan1_pppoe_mru=1492
wan1_pppoe_mtu=1492
wan1_pppoe_options_x=
wan1_pppoe_passwd=
wan1_pppoe_relay=0
wan1_pppoe_service=
wan1_pppoe_username=
wan1_pptp_options_x=
wan1_primary=0
wan1_proto=dhcp
wan1_proto_t=dhcp
wan1_realip_ip=
wan1_realip_state=0
wan1_route=
wan1_s46_ealen_x=0
wan1_s46_offset_x=6
wan1_s46_peer_x=
wan1_s46_prefix4_x=
wan1_s46_prefix4len_x=0
wan1_s46_prefix6_x=
wan1_s46_prefix6len_x=0
wan1_s46_psid_x=0
wan1_s46_psidlen_x=0
wan1_sbstate_t=0
wan1_state_t=2
wan1_unit=1
wan1_upnp_enable=1
wan1_vendorid=
wan1_vpndhcp=1
wan1_wins=
wan1_xgateway=192.168.10.1
wan1_xipaddr=0.0.0.0
wan1_xnetmask=0.0.0.0
 
Its hot, and wan1_state_t shows 2, and wan1_realip_state shows 2, but wan1_realip_ip is empty, even after it restarts it. I assume this is just cosmetic, just letting you know
Yea it's because you are Double NAT and your IP for that WAN interface is a Private IP Address so it's not a Real IP. It's cosmetic and should work fine, I can further expand on the checks later but functionality wise it doesn't change anything other than making the interface restart prior to monitoring.

Edit: After looking at the logic, the interface may not be state 2 until it restarts and then it goes into state 2. If it is not State 2 OR Real IP State is not 2 & there is no Real IP it will say it is not connected. If it is State 2 OR Real IP State is 2 or there is a Real IP it will show Connected.
 
Yea it's because you are Double NAT and your IP for that WAN interface is a Private IP Address so it's not a Real IP. It's cosmetic and should work fine, I can further expand on the checks later but functionality wise it doesn't change anything other than making the interface restart prior to monitoring.

Edit: After looking at the logic, the interface may not be state 2 until it restarts and then it goes into state 2. If it is not State 2 OR Real IP State is not 2 & there is no Real IP it will say it is not connected. If it is State 2 OR Real IP State is 2 or there is a Real IP it will show Connected.
I do notice that it also says wan1 100% packetloss in the log, but if I type in the ping -I eth5 command manually it works fine, so maybe WANPREFIX isnt being set there also. *shrug*. I think alot of people may be in doublenat on the secondary, as many use hotspots,etc.
If Im bugging you, sorry. Kind of learning the dualwan stuff with your script myself. Ty
 
I do notice that it also says wan1 100% packetloss in the log, but if I type in the ping -I eth5 command manually it works fine, so maybe WANPREFIX isnt being set there also. *shrug*. I think alot of people may be in doublenat on the secondary, as many use hotspots,etc.
If Im bugging you, sorry. Kind of learning the dualwan stuff with your script myself. Ty
Does it show that during WAN Status or another function? You're fine, I would like to work out the issues with the script so it works for everyone and is more universal.
 
05/23/22 @ 12:20:43: ./wanfail.sh - WAN Status: wan0 is connected...
05/23/22 @ 12:20:43: ./wanfail.sh - WAN Status: Route exists for 8.8.8.8 via 100.64.0.1 dev eth0...
05/23/22 @ 12:20:47: ./wanfail.sh - WAN Status: wan0 has 0% packet loss...
05/23/22 @ 12:20:47: ./wanfail.sh - WAN Status: wan1 enabled...
05/23/22 @ 12:20:47: ./wanfail.sh - WAN Status: wan1 is not connected, attempting to restart interface...
05/23/22 @ 12:20:50: ./wanfail.sh - WAN Status: Creating route 8.8.4.4 via 0.0.0.0 dev eth5...
05/23/22 @ 12:20:50: ./wanfail.sh - WAN Status: Created route 8.8.4.4 via 0.0.0.0 dev eth5.
05/23/22 @ 12:20:55: ./wanfail.sh - WAN Status: wan1 has 100% packet loss...
05/23/22 @ 12:20:55: ./wanfail.sh - WAN0 Active: Verifying WAN0...
05/23/22 @ 12:20:55: ./wanfail.sh - WAN0 Monitor: Monitoring WAN0 via 8.8.8.8 for Failure...
 
05/23/22 @ 12:20:43: ./wanfail.sh - WAN Status: wan0 is connected...
05/23/22 @ 12:20:43: ./wanfail.sh - WAN Status: Route exists for 8.8.8.8 via 100.64.0.1 dev eth0...
05/23/22 @ 12:20:47: ./wanfail.sh - WAN Status: wan0 has 0% packet loss...
05/23/22 @ 12:20:47: ./wanfail.sh - WAN Status: wan1 enabled...
05/23/22 @ 12:20:47: ./wanfail.sh - WAN Status: wan1 is not connected, attempting to restart interface...
05/23/22 @ 12:20:50: ./wanfail.sh - WAN Status: Creating route 8.8.4.4 via 0.0.0.0 dev eth5...
05/23/22 @ 12:20:50: ./wanfail.sh - WAN Status: Created route 8.8.4.4 via 0.0.0.0 dev eth5.
05/23/22 @ 12:20:55: ./wanfail.sh - WAN Status: wan1 has 100% packet loss...
05/23/22 @ 12:20:55: ./wanfail.sh - WAN0 Active: Verifying WAN0...
05/23/22 @ 12:20:55: ./wanfail.sh - WAN0 Monitor: Monitoring WAN0 via 8.8.8.8 for Failure...
Ok, it may be trying to do the initial ping test too quick after it restarts the interface, and giving you the 100% packet loss result. Probably shortly after that log happens it is working. I'll come up with a solution for that.
 
Ok, it may be trying to do the initial ping test too quick after it restarts the interface, and giving you the 100% packet loss result. Probably shortly after that log happens it is working. I'll come up with a solution for that.
I added a sleep, didnt work. I may have manually added the route when I tried the ping to that interface and it worked. now it doesnt after a reboot. I need to quit messing with it while on the phone,etc.. So I can give more valid info.
 
Last edited:
I added a sleep, didnt work. I may have manually added the route when I tried the ping to that interface and it worked. now it doesnt after a reboot. I need to quit messing with it while on the phone,etc.. So I can give more valid info.
Let me know, it is suppose to add the route before trying to ping so it won't fail.
 
Let me know, it is suppose to add the route before trying to ping so it won't fail.
If I get rid of the variables, and just add

fi
ip route add 8.8.4.4 via 192.168.10.1 dev eth5
WAN1PACKETLOSS="$(ping -I eth5 8.8.4.4 -c 3 -W 1 | grep -e "packet loss" | awk '{print $7}')"

Everything works.

5/23/22 @ 14:22:06: ./wanfail.sh - WAN Status: wan0 is connected...
05/23/22 @ 14:22:06: ./wanfail.sh - WAN Status: Route exists for 8.8.8.8 via 100.64.0.1 dev eth0...
05/23/22 @ 14:22:10: ./wanfail.sh - WAN Status: wan0 has 0% packet loss...
05/23/22 @ 14:22:10: ./wanfail.sh - WAN Status: wan1 enabled...
05/23/22 @ 14:22:10: ./wanfail.sh - WAN Status: wan1 is connected...
05/23/22 @ 14:22:10: ./wanfail.sh - WAN Status: Creating route 8.8.4.4 via 192.168.10.1 dev eth5...
05/23/22 @ 14:22:10: ./wanfail.sh - WAN Status: Created route 8.8.4.4 via 192.168.10.1 dev eth5.
05/23/22 @ 14:22:12: ./wanfail.sh - WAN Status: wan1 has 0% packet loss...
05/23/22 @ 14:22:12: ./wanfail.sh - WAN0 Active: Verifying WAN0...
05/23/22 @ 14:22:12: ./wanfail.sh - WAN0 Monitor: Monitoring WAN0 via 8.8.8.8 for Failure...
 
If I get rid of the variables, and just add

fi
ip route add 8.8.4.4 via 192.168.10.1 dev eth5
WAN1PACKETLOSS="$(ping -I eth5 8.8.4.4 -c 3 -W 1 | grep -e "packet loss" | awk '{print $7}')"

Everything works.

5/23/22 @ 14:22:06: ./wanfail.sh - WAN Status: wan0 is connected...
05/23/22 @ 14:22:06: ./wanfail.sh - WAN Status: Route exists for 8.8.8.8 via 100.64.0.1 dev eth0...
05/23/22 @ 14:22:10: ./wanfail.sh - WAN Status: wan0 has 0% packet loss...
05/23/22 @ 14:22:10: ./wanfail.sh - WAN Status: wan1 enabled...
05/23/22 @ 14:22:10: ./wanfail.sh - WAN Status: wan1 is connected...
05/23/22 @ 14:22:10: ./wanfail.sh - WAN Status: Creating route 8.8.4.4 via 192.168.10.1 dev eth5...
05/23/22 @ 14:22:10: ./wanfail.sh - WAN Status: Created route 8.8.4.4 via 192.168.10.1 dev eth5.
05/23/22 @ 14:22:12: ./wanfail.sh - WAN Status: wan1 has 0% packet loss...
05/23/22 @ 14:22:12: ./wanfail.sh - WAN0 Active: Verifying WAN0...
05/23/22 @ 14:22:12: ./wanfail.sh - WAN0 Monitor: Monitoring WAN0 via 8.8.8.8 for Failure...
Which variables are you bypassing?
 
Which variables are you bypassing?
This line:
ip route add $WAN1TARGET via $(nvram get ${WANPREFIX}_gateway) dev $(nvram get ${WANPREFIX}_ifname)
And:
WAN1PACKETLOSS="$(ping -I $(nvram get ${WANPREFIX}_ifname) $WAN0TARGET -c $PINGCOUNT -W $PINGTIMEOUT | grep -e "packet loss" | awk '{print $7}')"
 
This line:
ip route add $WAN1TARGET via $(nvram get ${WANPREFIX}_gateway) dev $(nvram get ${WANPREFIX}_ifname)
And:
WAN1PACKETLOSS="$(ping -I $(nvram get ${WANPREFIX}_ifname) $WAN0TARGET -c $PINGCOUNT -W $PINGTIMEOUT | grep -e "packet loss" | awk '{print $7}')"
Are you bypassing the setvariables function somehow? What mode are you running in? Send me a copy of your config file please.
 
Are you bypassing the setvariables function somehow? What mode are you running in? Send me a copy of your config file please.
This is the stock script (besides when I changed those two lines) running manual



WAN0TARGET=8.8.8.8
WAN1TARGET=8.8.4.4
PINGCOUNT=5
PINGTIMEOUT=1
WANDISABLEDSLEEPTIMER=3
WAN0_QOS_IBW=0
WAN1_QOS_IBW=0
WAN0_QOS_OBW=0
WAN1_QOS_OBW=0
WAN0_QOS_OVERHEAD=48
WAN1_QOS_OVERHEAD=48
WAN0_QOS_ATM=
WAN1_QOS_ATM=0
 
It would be very nice for everyone to make use of CODE blocks when pasting code into a post. Makes code much easier to read.

1653331996564.png
 

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top