WANFailover Dual WAN Failover Script

[Ranger802004]

But it didn't remove the cron entry - I did it by hand.

Did it remove from wan-event?

 

[Viktor Jaep]

Send me the debug logging so I can take a look at what is going on, this is the first test I have had with USB devices after my iteration of fixes in the current beta

Sorry... this was just a general question regarding the basic function of stock dual-wan... I had not installed your dual-wan script yet because I'm just trying to get the basics working first.

 

[Stephen Harrington]

I'm just trying to get the basics working first.

@Viktor Jaep Try the following command and see if it switches your Secondary to Hot-Standby? @Ranger802004 got me to do this whilst he was doing some info gathering a few days ago and it did the trick of at least getting me an IP on my 4G dongle.

service "restart_wan_if 1"

 

[Ranger802004]

@Viktor Jaep Try the following command and see if it switches your Secondary to Hot-Standby? @Ranger802004 got me to do this whilst he was doing some info gathering a few days ago and it did the trick of at least getting me an IP on my 4G dongle.

service "restart_wan_if 1"

Yes this command is incorporated into the script, you're not going to get proper WAN Failover with the stock settings especially using a USB Device. I definitely need testing and feedback regarding this configuration though.

 

[Ranger802004]

v1.5.6-beta5 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-beta5.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 6in4 Mode 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-beta5
- General optimization
- 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.
- 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 before determing a failure or packet loss. RECURSIVEPINGCHECK (Value is in # of iterations). Default: 1
- Resolved issues that prevented 4G USB Devices from properly working in Failover Mode.
- Moved WAN0_QOS_OVERHEAD, WAN1_QOS_OVERHEAD, WAN0_QOS_ATM, WAN1_QOS_ATM, BOOTDELAYTIMER, PACKETLOSSLOGGING and WANDISABLEDSLEEPTIMER to Optional Configuration and no longer are required to be set during Config or Installation. They will be given Default values that can be modified in the Configuration file.
- Created new Optional Configured Option to specify the ping packet size. PACKETSIZE specifes the packet size in Bytes, Default: 56 Bytes.
- Resolve issue where script would loop from WAN Status to Load Balance Monitor when an interface was disabled.
- Load Balance Mode will now dynamically update resolv.conf (DNS) for Disconnected WAN Interfaces.
- Fixed Cron Job deletion during Uninstallation.
- If IPv6 6in4 is being used, the script will perform a service restart.
- Corrected issue with Failure Detected log not logging if a device was unplugged or powered off from the Router while in Failover Mode.

 

[JohnSmith]

So the last two betas I have done some quick tests (hopefully Monday I can do some more thorough tests and document), but I noticed when my ISP#01 I turn off its modem, it fails over to ISP#02, but when I turn ISP#01 back on (which is my preferred ISP to use as it is 1GB Symmetrical), it does not failback.

It's almost like ISP#02 has to Fail, in order for the failback to happen.

System log shows:

Jul 24 14:24:42 wan-failover.sh: Install - /jffs/configs/wan-failover.conf already exists
Jul 24 14:25:15 wan-failover.sh: Restart - ***wan-failover.sh is not running*** No Process ID Detected
Jul 24 14:26:01 wan-failover.sh: Restart - Successfully Restarted wan-failover.sh Process ID(s):  26195 26196
Jul 24 14:26:07 wan-failover.sh: WAN Status - wan0 has 100% packet loss ***Verify 8.8.8.8 is a valid server for ICMP Echo Requests***
Jul 24 14:26:11 wan-failover.sh: WAN0 Failback Monitor - Monitoring wan1 via 8.8.4.4 for Failure
Jul 24 14:26:11 wan-failover.sh: WAN0 Failback Monitor - Monitoring wan0 via 8.8.8.8 for Restoration

But wan0, which is the Primary WAN, is in Hot-Standby, and has an WAN IP address, DNS Servers, and Gateway populated already, so that if ISP#02 is turned off, it comes on right away.

Has something changed in the script causing this?

I was going to go back to V1.5.5 to test but thought I would ask @Ranger802004 first.

 

[Ranger802004]

So the last two betas I have done some quick tests (hopefully Monday I can do some more thorough tests and document), but I noticed when my ISP#01 I turn off its modem, it fails over to ISP#02, but when I turn ISP#01 back on (which is my preferred ISP to use as it is 1GB Symmetrical), it does not failback.

It's almost like ISP#02 has to Fail, in order for the failback to happen.

System log shows:

Jul 24 14:24:42 wan-failover.sh: Install - /jffs/configs/wan-failover.conf already exists
Jul 24 14:25:15 wan-failover.sh: Restart - ***wan-failover.sh is not running*** No Process ID Detected
Jul 24 14:26:01 wan-failover.sh: Restart - Successfully Restarted wan-failover.sh Process ID(s):  26195 26196
Jul 24 14:26:07 wan-failover.sh: WAN Status - wan0 has 100% packet loss ***Verify 8.8.8.8 is a valid server for ICMP Echo Requests***
Jul 24 14:26:11 wan-failover.sh: WAN0 Failback Monitor - Monitoring wan1 via 8.8.4.4 for Failure
Jul 24 14:26:11 wan-failover.sh: WAN0 Failback Monitor - Monitoring wan0 via 8.8.8.8 for Restoration

But wan0, which is the Primary WAN, is in Hot-Standby, and has an WAN IP address, DNS Servers, and Gateway populated already, so that if ISP#02 is turned off, it comes on right away.

Has something changed in the script causing this?

I was going to go back to V1.5.5 to test but thought I would ask @Ranger802004 first.

Yea it's probably not adding the IP Rule back to validate it's not back online, I can add a check for this. Can you send over some debug logs first?

In the meantime you can make it manually switchback using this argument.
/jffs/scripts/wan-failover.sh switchwan

 

[JohnSmith]

Yea it's probably not adding the IP Rule back to validate it's not back online, I can add a check for this. Can you send over some debug logs first?

In the meantime you can make it manually switchback using this argument.
/jffs/scripts/wan-failover.sh switchwan

Here is the error message I get for switchwan:

admin@XXAX88U:/tmp/home/root# /jffs/scripts/wan-failover.sh switchwan
wan-failover.sh - Switch WAN Mode
***Switch WAN Mode is only available in Failover Mode***

and

admin@XXAX88U:/tmp/home/root# nvram get wans_mode
fo

 

[Ranger802004]

Here is the error message I get for switchwan:

admin@XXAX88U:/tmp/home/root# /jffs/scripts/wan-failover.sh switchwan
wan-failover.sh - Switch WAN Mode
***Switch WAN Mode is only available in Failover Mode***

Are you in Load Balancing Mode? I really need to get debug logging from you to diagnose this if not.

 

[JohnSmith]

Are you in Load Balancing Mode? I really need to get debug logging from you to diagnose this if not.

Nope, Fail Over Mode

 

[Ranger802004]

Nope, Fail Over Mode

View attachment 43047

Ok I will need debug logging, please.

EDIT: Once you collect the debug logs go ahead and fall back to 1.5.5 until I release a new beta to test. I found some issues with 1.5.6-beta4 that I'm ironing out now for next release, thank you.

 

[JohnSmith]

Ok I will need debug logging, please.

EDIT: Once you collect the debug logs go ahead and fall back to 1.5.5 until I release a new beta to test. I found some issues with 1.5.6-beta4 that I'm ironing out now for next release, thank you.

I have gone back to V1.5.5 and Failover and Failback works like it did before (YazFi was unsuccessful both Failover and Failback, but nothing a

/jffs/scripts/YazFi check

wouldn't cure.

Network getting busy again, so testing will have to be another day.

 

[Ranger802004]

I have gone back to V1.5.5 and Failover and Failback works like it did before (YazFi was unsuccessful both Failover and Failback, but nothing a

/jffs/scripts/YazFi check

wouldn't cure.

Network getting busy again, so testing will have to be another day.

Are you getting this log in your logs? Should just require Notice level logs.

"Service Restart - Triggering YazFi to update"

 

[JohnSmith]

Are you getting this log in your logs? Should just require Notice level logs.

"Service Restart - Triggering YazFi to update"

I never see that line in any of my logs, either V1.5.5 or V1.5.6 Beta4

 

[Ranger802004]

I never see that line in any of my logs, either V1.5.5 or V1.5.6 Beta4

What do you get when you run these commands?

cru l | grep -w "YazFi"
if [ -f "/jffs/scripts/YazFi" ];then echo "true";fi

 

[JohnSmith]

I never see that line in any of my logs, either V1.5.5 or V1.5.6 Beta4

What do you get when you run these commands?

cru l | grep -w "YazFi"
if [ -f "/jffs/scripts/YazFi" ];then echo "true";fi

V1.5.5 currently:

ASUSWRT-Merlin RT-AX88U 386.7_2 Sun Jul 24 21:39:14 UTC 2022
admin@XXAX88U:/tmp/home/root# cru l | grep -w "YazFi"
*/10 * * * * /jffs/scripts/YazFi check #YazFi#
admin@XXAX88U:/tmp/home/root# if [ -f "/jffs/scripts/YazFi" ];then echo "true";f
i
true

 

[Ranger802004]

V1.5.5 currently:

ASUSWRT-Merlin RT-AX88U 386.7_2 Sun Jul 24 21:39:14 UTC 2022
admin@XXAX88U:/tmp/home/root# cru l | grep -w "YazFi"
*/10 * * * * /jffs/scripts/YazFi check #YazFi#
admin@XXAX88U:/tmp/home/root# if [ -f "/jffs/scripts/YazFi" ];then echo "true";f
i
true

You're meeting the prereqs for it to trigger YazFi command so not sure why you are not getting the logs whenever your failover happens.

 

[Ranger802004]

Just an update guys, I'm working on the next beta release and have been busy but I expect to have the next beta out tonight or tomorrow. Just wanted to keep everyone in the loop. If you are having an issue please get me the debug logs ASAP so I can diagnose the problem as best as I can to resolve in the next release before it goes live, thank you.

 

[JohnSmith]

Just an update guys, I'm working on the next beta release and have been busy but I expect to have the next beta out tonight or tomorrow. Just wanted to keep everyone in the loop. If you are having an issue please get me the debug logs ASAP so I can diagnose the problem as best as I can to resolve in the next release before it goes live, thank you.

I'll wait for your next beta to give the newest beta version another try for failover and failback, and the network should be a little quieter to do some tests. Debug Logs will take a long time to get from me as it would be a lot of redacting for privacy purposes (Notice Logs are easier to redact).

 

[Ranger802004]

I'll wait for your next beta to give the newest beta version another try for failover and failback, and the network should be a little quieter to do some tests. Debug Logs will take a long time to get from me as it would be a lot of redacting for privacy purposes (Notice Logs are easier to redact).

No worries