WANFailover Dual WAN Failover Script

[Ranger802004]

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.

 

[Ranger802004]

PINGCOUNT=20
PINGTIMEOUT=4

Google Drive: Sign-in

Access Google Drive with a Google account (for personal use) or Google Workspace account (for business use).

drive.google.com

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?

 

[Ranger802004]

PINGCOUNT=20
PINGTIMEOUT=4

Google Drive: Sign-in

Access Google Drive with a Google account (for personal use) or Google Workspace account (for business use).

drive.google.com

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.

 

[VIper_Rus]

Это потому, что он не вернул 0%. Во время первоначальных проверок он должен быть равен 0%, чтобы считаться хорошим, но во время активного мониторинга отказоустойчивости он будет помечать это только как потерю пакетов.

ПИНГКАУНТ=40
PINGTIMEOUT=2

Google Drive: Sign-in

Access Google Drive with a Google account (for personal use) or Google Workspace account (for business use).

drive.google.com

Google Drive: Sign-in

Access Google Drive with a Google account (for personal use) or Google Workspace account (for business use).

drive.google.com

Параллельно пинговал 1.1.1.1 в веб интерфейсе. Потерь нет вообще.

 

[VIper_Rus]

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.

Google Drive: Sign-in

Access Google Drive with a Google account (for personal use) or Google Workspace account (for business use).

drive.google.com

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.

 

[Stephen Harrington]

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?

 

[VIper_Rus]

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.

 

[Ranger802004]

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.

 

[VIper_Rus]

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.

 

[Ranger802004]

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.

 

[VIper_Rus]

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]

@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!

 

[Ranger802004]

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.

 

[Ranger802004]

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***

/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:

/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.

 

[VIper_Rus]

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***

/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:

/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

Google Drive: Sign-in

Access Google Drive with a Google account (for personal use) or Google Workspace account (for business use).

drive.google.com

 

[Ranger802004]

Super

Google Drive: Sign-in

Access Google Drive with a Google account (for personal use) or Google Workspace account (for business use).

drive.google.com

Do you feel like that is a good solution for the problems you experience?

 

[VIper_Rus]

Do you feel like that is a good solution for the problems you experience?

This is a super solution.I'm reducing all the thayers and the number of pings right now. 2 times for verification is also enough, right now I'll post a log

 

[VIper_Rus]

Do you feel like that is a good solution for the problems you experience?

WAN0TARGET=1.1.1.1
WAN1TARGET=1.0.0.1
PINGCOUNT=5
PINGTIMEOUT=2
WANDISABLEDSLEEPTIMER=10
BOOTDELAYTIMER=60
RECURSIVEPINGCHECK=2

Google Drive: Sign-in

Access Google Drive with a Google account (for personal use) or Google Workspace account (for business use).

drive.google.com

 

[Ranger802004]

WAN0TARGET=1.1.1.1
WAN1TARGET=1.0.0.1
PINGCOUNT=5
PINGTIMEOUT=2
WANDISABLEDSLEEPTIMER=10
BOOTDELAYTIMER=60
RECURSIVEPINGCHECK=2

Google Drive: Sign-in

Access Google Drive with a Google account (for personal use) or Google Workspace account (for business use).

drive.google.com

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.

 

[VIper_Rus]

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

Google Drive: Sign-in

Access Google Drive with a Google account (for personal use) or Google Workspace account (for business use).

drive.google.com

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.