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!

Hmmm ok, let me think on this for a few.
@VIper_Rus , try increasing your ping count to something really high like 20-30 and your ping timeout to atleast 2 seconds. I want to see if this is a timing issue with adding the IP rule and see if the pings start working.
 
PINGCOUNT=20
PINGTIMEOUT=4

Wow you already did what I just asked lol ironic. Ok so do you agree this appears to be a timing issue from when the IP Rules are added for monitoring then?
 
PINGCOUNT=20
PINGTIMEOUT=4


The only thing I don't understand is why:
88: Jul 17 23:04:35 wan-failover.sh : Debug - wan0 Status: Disconnected

but otherwise it seems to be fine. But it would still be more correct to solve the problem with a set timer.
It's because it didn't get 0% returned. During initial checks it has to be 0% to be considered good but during active monitoring for Failover it would only flag that as packet loss.
 
Это потому, что он не вернул 0%. Во время первоначальных проверок он должен быть равен 0%, чтобы считаться хорошим, но во время активного мониторинга отказоустойчивости он будет помечать это только как потерю пакетов.
ПИНГКАУНТ=40
PINGTIMEOUT=2


Параллельно пинговал 1.1.1.1 в веб интерфейсе. Потерь нет вообще.
 
It's because it didn't get 0% returned. During initial checks it has to be 0% to be considered good but during active monitoring for Failover it would only flag that as packet loss.
I don't understand what's going on while I was writing the post, the script detected a failure, BUT all the pings continued to go fine in the web interface. But I want to check this again, I'm not sure exactly.
 
what kinds of IP addresses do you see on your secondary WAN side when it says "cold standby" or "hot standby"?
@Viktor Jaep

Cold-standby, none, same as your screenshot. Hot-standby for this Huawei “wingle” I get a private IP and gateway etc from the device (so double-NAT, and no way of bridging apparently). Early on I had to change the subnet it was handing out to 192.168.2.x so it wasn’t the same as the Asus LAN - got a warning from the RT-AX86U. So this thing also has its own Wifi and web interface as well, just to clarify.

I think your borrowed device may not be compatible for some reason?
 
It's because it didn't get 0% returned. During initial checks it has to be 0% to be considered good but during active monitoring for Failover it would only flag that as packet loss.
No, I think I still have problems. Through the web interface, it also showed partial packet losses right now. I also noticed that if I try to ping 77.88.8.8, then the first ping is lost all the time. It can implement not a time delay, but ignoring a given number of initial pings.
 
No, I think I still have problems. Through the web interface, it also showed partial packet losses right now. I also noticed that if I try to ping 77.88.8.8, then the first ping is lost all the time. It can implement not a time delay, but ignoring a given number of initial pings.
The ping in the Web UI isn't hardcoded to WAN specific interfaces like the script either, it's not really a good test to compare.
 
The ping in the Web UI isn't hardcoded to WAN specific interfaces like the script either, it's not really a good test to compare.
In short, a strange situation. I connected to the router via ssh, tried to ping. Very often, when you run the ping command from the first time, the pings do not go. But if you press CTRL-C and start again, everything is OK. If i wait for some time and run it again, it's the same thing again. The most interesting thing is that there is no such problem on the clients of this router. A strange situation. I can only try another provider.
 
In short, a strange situation. I connected to the router via ssh, tried to ping. Very often, when you run the ping command from the first time, the pings do not go. But if you press CTRL-C and start again, everything is OK. If i wait for some time and run it again, it's the same thing again. The most interesting thing is that there is no such problem on the clients of this router. A strange situation. I can only try another provider.
I am working on a solution, standby.
 
I am working on a solution, standby.
I also had a thought, you can make an additional check. I.e., let's say a result other than zero was obtained on the initial initialization, then this result is checked twice. when the additional check option is enabled.
i.e. the ping is interrupted and started again. something like that. I think this will help for sure.
 
@Viktor Jaep

Cold-standby, none, same as your screenshot. Hot-standby for this Huawei “wingle” I get a private IP and gateway etc from the device (so double-NAT, and no way of bridging apparently). Early on I had to change the subnet it was handing out to 192.168.2.x so it wasn’t the same as the Asus LAN - got a warning from the RT-AX86U. So this thing also has its own Wifi and web interface as well, just to clarify.

I think your borrowed device may not be compatible for some reason?
OK... so that's exactly the kind of thing I was experiencing then. Thanks for the info!
 
OK... so that's exactly the kind of thing I was experiencing then. Thanks for the info!
@Stephen Harrington provided me some data this morning and did some preliminary testing on how to get out of the no IP situation, I am working on the fixes now for my next beta as well as a Recursive Ping Check setting per @VIper_Rus 's issue.
 
v1.5.6-beta2 Release: ***Disclaimer: This is a beta release and has been untested***

Manually upgrade to this beta by running the following command" ***Allow for cronjob to relaunch the script***
Code:
/usr/sbin/curl -s "https://raw.githubusercontent.com/Ranger802004/asusmerlin/main/wan-failover_v1.5.6-beta2.sh" -o "/jffs/scripts/wan-failover.sh" && chmod 755 /jffs/scripts/wan-failover.sh && sh /jffs/scripts/wan-failover.sh restart

To revert back to Production Release:
Code:
/jffs/scripts/wan-failover.sh update

***WARNING: IPv6 issues may occur from new service restart logic during failover, please test and provide debug logging data if you experience issues***

Release Notes:
v1.5.6-beta2
- Added a confirmation prompt to Restart Mode.
- Fixed visual bugs when running Restart Mode.
- Load Balance Monitor now triggers Service Restart function during failover events.
- IPv6 services are restarted for Failover events.
- YazFi trigger during service restart will no longer run process in the background to prevent issues with script execution of YazFi.
- IP Rules should no longer create conflict with other scripts such as VPNMON.
- Target IPs for both interfaces can now be the same the Target IP.
- Added Recursive Ping Check feature. If packet loss is not 0% during a check, the Target IP Addresses will be checked again based on the number of iterations specified by this setting. RECURSIVEPINGCHECK (Value is in # of iterations). Default: 1
- Resolved issues that prevented 4G USB Devices from properly working in Failover Mode.
 
v1.5.6-beta2 Release: ***Disclaimer: This is a beta release and has been untested***

Manually upgrade to this beta by running the following command" ***Allow for cronjob to relaunch the script***
Code:
/usr/sbin/curl -s "https://raw.githubusercontent.com/Ranger802004/asusmerlin/main/wan-failover_v1.5.6-beta2.sh" -o "/jffs/scripts/wan-failover.sh" && chmod 755 /jffs/scripts/wan-failover.sh && sh /jffs/scripts/wan-failover.sh restart

To revert back to Production Release:
Code:
/jffs/scripts/wan-failover.sh update

***WARNING: IPv6 issues may occur from new service restart logic during failover, please test and provide debug logging data if you experience issues***

Release Notes:
v1.5.6-beta2
- Added a confirmation prompt to Restart Mode.
- Fixed visual bugs when running Restart Mode.
- Load Balance Monitor now triggers Service Restart function during failover events.
- IPv6 services are restarted for Failover events.
- YazFi trigger during service restart will no longer run process in the background to prevent issues with script execution of YazFi.
- IP Rules should no longer create conflict with other scripts such as VPNMON.
- Target IPs for both interfaces can now be the same the Target IP.
- Added Recursive Ping Check feature. If packet loss is not 0% during a check, the Target IP Addresses will be checked again based on the number of iterations specified by this setting. RECURSIVEPINGCHECK (Value is in # of iterations). Default: 1
- Resolved issues that prevented 4G USB Devices from properly working in Failover Mode.
Super :)
 
WAN0TARGET=1.1.1.1
WAN1TARGET=1.0.0.1
PINGCOUNT=5
PINGTIMEOUT=2
WANDISABLEDSLEEPTIMER=10
BOOTDELAYTIMER=60
RECURSIVEPINGCHECK=2



Looks like that works, keep in mind the recursive check effects active monitoring as well, if you get 0% packet loss, it will continue. If it doesn’t it will start the recursive check iterations and then fail or report packet loss.
 
Looks like that works, keep in mind the recursive check effects active monitoring as well, if you get 0% packet loss, it will continue. If it doesn’t it will start the recursive check iterations and then fail or report packet loss.
PINGCOUNT=5
PINGTIMEOUT=1
WANDISABLEDSLEEPTIMER=5
BOOTDELAYTIMER=60
5 points. I understand you write that the detect failure time increases by the number of times the check is performed, I think it's even better!!
I'll set up 2 checks on all routers right now, it's more reliable, it's better to reduce the number of pings and the response time, but let it check 2 times better! Super Thanks!

Only I'll check tomorrow night, at the moment of maximum loading, when I have the most glitches. I'll write the results.
 
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