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!

You happen to have a link to the last version, this one isnt working at all, doesnt even make the secondary hot. I should of saved it, until I can see whats going on.
EDIT: found it on github
That is strange, is the script running for you? Did you do configure?
 
Why don't you use email conf from amtm?
As soon as they have been implemented, I stopped using AiProtection email alerts.
I’ll look into this and see, the built in alerts are easy to check if they are enabled and to use them if they are so I just added that in there.
 
That is strange, is the script running for you? Did you do configure?
I did a clean install and configure after it wasnt working, same thing. It would hang at configuring route at secondary. When I manually made it hot, it would go to monitoring wan0, but if i made it failover it would never go back. Today i dont have alot of time to mess with it, but i will. Just a fyi, before i upgraded this morning, my starlink went up and down about 15minutes in a hour. 1.4.1 worked so well i would have never noticed the swapping back and forth if it wasnt for the logs
 
I did a clean install and configure after it wasnt working, same thing. It would hang at configuring route at secondary. When I manually made it hot, it would go to monitoring wan0, but if i made it failover it would never go back. Today i dont have alot of time to mess with it, but i will.
When you get some time send me the logging you are getting, I’m trying to figure out what is causing your issue because the only thing I changed in that regard was the check for the packet loss logging whether to log it or not.
 
When you get some time send me the logging you are getting, I’m trying to figure out what is causing your issue because the only thing I changed in that regard was the check for the packet loss logging whether to log it or not.
When i looked at your changelog I thought, he probably didnt even touch the wan1 restart code, so doesnt make sense. I did do a few cold boots through testing earlier just to make sure it wasnt some fluke. Ill try to mess with it tonight.
 
When i looked at your changelog I thought, he probably didnt even touch the wan1 restart code, so doesnt make sense. I did do a few cold boots through testing earlier just to make sure it wasnt some fluke. Ill try to mess with it tonight.
I found the problem, it was related to running install mode not asking for or setting WAN1Target, working on fix now.
 
I found the problem, it was related to running install mode not asking for or setting WAN1Target, working on fix now.
I noticed that at first, but then I think I did config maybe, and it asked. Was still having some issues after. And the config file looked correct
 
I noticed that at first, but then I think I did config maybe, and it asked. Was still having some issues after. And the config file looked correct
My apologies, yea it was set to only prompt for that setting in config mode instead of both install and config.

EDIT:
v1.4.3 is published.

v1.4.3
- Fixed issue where Installation Mode would not set WAN1 Target IP Address.
- Fixed issue where Packet Loss Logging was not properly logging if enabled.
- During WAN Status Check, the log to message "***Verify (Target IP) is a valid server for ICMP Echo Requests***" will only occur if there is 100% loss on the initial check.
 
Last edited:
no worries, maybe your at the point to have a "devel" mode, like some of the scripts do
Or beta releases and beta testers....lol. Let me know if v1.4.3 resolves your issues.
 
Or beta releases and beta testers....lol. Let me know if v1.4.3 resolves your issues.
Ill definitely try every release, youve been working hard on it, and addressing every issue found, and as I said, this morning was amazing the amount of times Starlink went down and the swapover was so fast and seamless I would have never of known. Let me know how beta testers would work easiest for you, I dont even care if you just emailed a script to try. Ill try this one in a few hours.
 
Ill definitely try every release, youve been working hard on it, and addressing every issue found, and as I said, this morning was amazing the amount of times Starlink went down and the swapover was so fast and seamless I would have never of known. Let me know how beta testers would work easiest for you, I dont even care if you just emailed a script to try. Ill try this one in a few hours.
I will work on that and maybe collaborate with some others who would like to assist? I will say another upcoming script I’m going to build and release will be domain/host named based routing for VPN tunnels. I have a private proof of concept script for this I know it works just gotta write a public formatted one.
 
I will work on that and maybe collaborate with some others who would like to assist? I will say another upcoming script I’m going to build and release will be domain/host named based routing for VPN tunnels. I have a private proof of concept script for this I know it works just gotta write a public formatted one.
Your cybersecurity, maybe you can help me get my damn FB account back :). Its linked to my business page, was hacked about a week ago. Meta is a joke. I had paid for a ad for employment that I cant even access.
 
Your cybersecurity, maybe you can help me get my damn FB account back :). Its linked to my business page, was hacked about a week ago. Meta is a joke. I had paid for a ad for employment that I cant even access.
Sorry, I actually couldn’t help you with that. But I’ve heard the same thing with others from Meta.
 
I can't test the script at the moment, but if it works reliably and doesn't break something else - this is a MAJOR fix for Asuswrt users!

Thank you, @Ranger802004 for sharing your work!
Thank you! When I originally made this script, it was a personal project to fix my issue with the ASUS Failover logic. Once I saw others on here who disliked their methodology I decided to help everyone with developing a universal solution to resolve this gap so everyone who needs it could have proper Failover/Failback. As far as the script, it doesn't cause issues with anything else as far as I'm aware (I like to resolve these when they come up). I also made it adjustable for everyone's environment so it can be tweaked/tune to fit your needs. For example, @rlj2 is using Starlink as his Primary and a Double NATed DSL as a backup. He is able to adjust this tool to work properly for him with just the user config changes and I'm sure more options are going to be requested later on but I try and create solutions for the things the guys have found so far.
 
My apologies, yea it was set to only prompt for that setting in config mode instead of both install and config.

EDIT:
v1.4.3 is published.

v1.4.3
- Fixed issue where Installation Mode would not set WAN1 Target IP Address.
- Fixed issue where Packet Loss Logging was not properly logging if enabled.
- During WAN Status Check, the log to message "***Verify (Target IP) is a valid server for ICMP Echo Requests***" will only occur if there is 100% loss on the initial check.
I didnt get a ton of time to mess with this, but this does not make my secondary hot. I still have to manually do a "service "restart_wan_if 1"

Code:
if [[ "$(nvram get $(echo $WANPREFIXES | awk '{print $2}')_enable)" == "1" ]] >/dev/null;then
    echo -e "${YELLOW}${0##*/} - Uninstall: Restarting interface $(echo $WANPREFIXES | awk '{print $2}')${NOCOLOR}"
    logger -t "${0##*/}" "Uninstall - Restarting interface $(echo $WANPREFIXES | awk '{print $2}')"
    nvram set "$(echo $WANPREFIXES | awk '{print $2}')"_state_t=0
    service "restart_wan_if 1" &
    echo -e "${GREEN}${0##*/} - Uninstall: Restarted interface $(echo $WANPREFIXES | awk '{print $2}')${NOCOLOR}"
    logger -t "${0##*/}" "Uninstall - Restarted interface $(echo $WANPREFIXES | awk '{print $2}')"
  fi

With 1.4.2 or 1.4.3 if it switches over to secondary, it will show connected for about 10 seconds, then goes to disconnected. And just sits there, internet doesnt work or does it switch back to primary. The logs really dont show anything. 1.4.1 works fine after secondary is hot, but it does the same, shows connected, this disconnects.. but eventually reconnects, the logs show this while disconnected..

Code:
May 31 12:38:20 wan-failover.sh: WAN Failover Disabled - wan0 and wan1 are enabled and connected
May 31 12:38:20 wan-failover.sh: WAN Failover Disabled - Returning to check WAN Status
May 31 12:38:20 wan-failover.sh: WAN Status - wan0 enabled
May 31 12:38:20 wan-failover.sh: WAN Status - Route already exists for 8.8.8.8 via 100.64.0.1 dev eth0
May 31 12:38:25 wan-failover.sh: WAN Status - wan0 has 100% packet loss ***Verify 8.8.8.8 is a valid server for ICMP Echo Requests***
May 31 12:38:25 wan-failover.sh: WAN Status - wan1 enabled
May 31 12:38:25 wan-failover.sh: WAN Status - Route already exists for 8.8.4.4 via 192.168.10.1 dev eth5
May 31 12:38:30 wan-failover.sh: WAN Status - wan1 has 100% packet loss ***Verify 8.8.4.4 is a valid server for ICMP Echo Requests***
May 31 12:38:30 wan-failover.sh: WAN Failover Disabled - WAN Failover is currently stopped, will resume when Dual WAN Failover Mode is enabled and WAN Links are enabled with an active connection
May 31 12:38:30 wan-failover.sh: WAN Failover Disabled - wan0 and wan1 are enabled and connected
May 31 12:38:30 wan-failover.sh: WAN Failover Disabled - Returning to check WAN Status
May 31 12:38:30 wan-failover.sh: WAN Status - wan0 enabled
May 31 12:38:30 wan-failover.sh: WAN Status - Route already exists for 8.8.8.8 via 100.64.0.1 dev eth0
May 31 12:38:35 wan-failover.sh: WAN Status - wan0 has 100% packet loss ***Verify 8.8.8.8 is a valid server for ICMP Echo Requests***
May 31 12:38:35 wan-failover.sh: WAN Status - wan1 enabled
May 31 12:38:35 wan-failover.sh: WAN Status - Route already exists for 8.8.4.4 via 192.168.10.1 dev eth5

Im going to factory reset later just to make sure everything is as it should be.
 
Last edited:
I didnt get a ton of time to mess with this, but this does not make my secondary hot. I still have to manually do a "service "restart_wan_if 1"

Code:
if [[ "$(nvram get $(echo $WANPREFIXES | awk '{print $2}')_enable)" == "1" ]] >/dev/null;then
    echo -e "${YELLOW}${0##*/} - Uninstall: Restarting interface $(echo $WANPREFIXES | awk '{print $2}')${NOCOLOR}"
    logger -t "${0##*/}" "Uninstall - Restarting interface $(echo $WANPREFIXES | awk '{print $2}')"
    nvram set "$(echo $WANPREFIXES | awk '{print $2}')"_state_t=0
    service "restart_wan_if 1" &
    echo -e "${GREEN}${0##*/} - Uninstall: Restarted interface $(echo $WANPREFIXES | awk '{print $2}')${NOCOLOR}"
    logger -t "${0##*/}" "Uninstall - Restarted interface $(echo $WANPREFIXES | awk '{print $2}')"
  fi

With 1.4.2 or 1.4.3 if it switches over to secondary, it will show connected for about 10 seconds, then goes to disconnected. And just sits there, internet doesnt work or does it switch back to primary. The logs really dont show anything. 1.4.1 works fine after secondary is hot.. With that being said, think im going to factory reset later, just to make sure things are as they should be.
Send me the logs, it can still give me a clue on what is happening.
 
just edited that with a log
It looks like both of your ping tests are going to 100% packet loss before it even gets to the failover monitoring. Yea the script will mark those as disconnected and go to a disabled state until they are no longer disconnected. Can you manually ping? If so how long does it take to get a response? What is your ping timeout setting?
 
Last edited:

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