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!

3:1 which should be right on the money. No QoS here. As far as I understand, it's not bandwidth balancing, so 50+ connections should saturate the secondary wan, even if the primary was not being saturated (depending on the speed of each connection).

Was just about to edit my previous post again, everything looks to be running fine now. I'm seeing good throughput on both connections simultaneously. Cheers.
Glad to hear! I published a minor update to beta9 if you want to reinstall. It will create the balance rules for Load Balancer for Guest Networks
 
v1.5.5-beta10 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.5-beta10.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

***NOTICE: This is the last planned beta release for v1.5.5 for resolved issues and enhancements. Please report any issues discovered with this beta with debug logging enabled on your Router***

***Highlight: While in Load Balancing Mode, OpenVPN Split Tunneling can be Disabled defaulting to WAN0 and failover to WAN1 if WAN0 fails***

***Highlight: Email Notifications will be sent for Load Balancing Mode if a WAN failure occurs.***

***Highlight: YazFi will be triggered to update if installed and running during Failover.***

***Highlight: Debug Logs can be generated to help diagnose issues. To enable set System Log > Log only messages more urgent than: debug***

***Highlight: When running script in console, Packet Loss is actively displayed. 0% will be displayed in Green, 100% will be displayed in Red, and 1% - 99% will be displayed in Yellow.***

Example: Load Balance Mode actively monitoring both WAN0 and WAN.
1657524379668.png


***WARNING: Kill Mode will now delete cron job, use restart mode to schedule script to restart***


Release Notes:
v1.5.5-beta10
- General optimization of script logic
- If AdGuard is running or AdGuard Local is enabled, Switch WAN function will not update the resolv.conf file. (Collaboration with SomeWhereOverTheRainbow)
- Optimized the way script loads configuration variables.
- Service restarts will dynamically check which services need to be restarted.
- Optimized Boot Delay Timer functionality and changed logging messages to clarify how the Boot Delay Timer effects the script startup.
- WAN Status will now check if a cable is unplugged.
- Resolved issues with Load Balancing Mode introduced in v1.5.4
- Enhancements to Load Balancing Mode
- When in Load Balancing Mode, OpenVPN Split Tunneling can be disabled where remote addresses will default to WAN0 and failover to WAN1 if WAN0 fails and back to WAN0 when it is restored. This can be changed in Configuration file using the Setting: OVPNSPLITTUNNEL (1 = Enabled / 0 = Disabled).
- Corrected issue with Cron Job creation.
- Corrected issues with IP Rules creation for Target IP Addresses.
- When in Load Balance Mode, script will create IPTables Mangle rules for marking packets if they are missing. This is to correct an issue with the firmware.
- Increased email skip default delay to 180 seconds additional to Boot Delay Timer. Adjustable in configuration file using Setting: SKIPEMAILSYSTEMUPTIME (Value is in seconds).
- Script will check for supported ASUS Merlin Firmware Versions
- Script will verify System Binaries are used over Optional Binaries
- Added email functionality for Load Balancing Mode. If a WAN Interface fails, an email notification will be sent if enabled.
- Corrected issue where temporary file for mail would not have correct write permissions to create email for notification.
- Script will now create NAT Rules for services that are enabled.
- Load Balancing Rule Priority, WAN0/WAN1 Route Tables, FW Marks/Masks, IP Rule Priorities, and OpenVPN WAN Priority (Split Tunneling Disabled) are now all customizable using the configuration file. Recommended to leave default unless necessary to change.
- WAN Interface restarts during WAN Status checks will only wait 30 seconds maximum to check status again.
- Corrected issue where Monitor mode would stay running in background, now will exit background process when escaped with Ctrl + C.
- Added a restart mode to reload WAN Failover, use argument "restart". Config, Update, and Restart Mode will wait before cronjob cycle to kill script and allow cron job to reload script.
- Kill Mode will now delete the cron job to prevent WAN Failover from relaunching.
- If YazFi is installed and has a scheduled Cron Job, WAN Failover will trigger YazFi to update if installed in default location (/jffs/scripts/YazFi).
- Configured debug logging, to enable debug logging, set System Log > Log only messages more urgent than: debug
- Load Balancer will now work with Guest Networks created.
- Fixed issue where email would fail to send if --insecure flag was removed from amtm configuration.
- When running WAN Failover from the Console, the script will actively display the current Packet Loss. 0% will be displayed in Green, 100% will be displayed in Red, and 1% - 99% will be displayed in Yellow.
 

Attachments

  • 1657524550432.png
    1657524550432.png
    7.4 KB · Views: 47
Last edited:
v1.5.5-beta10 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.5-beta10.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

***NOTICE: This is the last planned beta release for v1.5.5 for resolved issues and enhancements. Please report any issues discovered with this beta with debug logging enabled on your Router***

***Highlight: While in Load Balancing Mode, OpenVPN Split Tunneling can be Disabled defaulting to WAN0 and failover to WAN1 if WAN0 fails***

***Highlight: Email Notifications will be sent for Load Balancing Mode if a WAN failure occurs.***

***Highlight: YazFi will be triggered to update if installed and running during Failover.***

***Highlight: Debug Logs can be generated to help diagnose issues. To enable set System Log > Log only messages more urgent than: debug***

***Highlight: When running script in console, Packet Loss is actively displayed. 0% will be displayed in Green, 100% will be displayed in Red, and 1% - 99% will be displayed in Yellow.***

Example: Load Balance Mode actively monitoring both WAN0 and WAN.
View attachment 42645

***WARNING: Kill Mode will now delete cron job, use restart mode to schedule script to restart***


Release Notes:
v1.5.5-beta10
- General optimization of script logic
- If AdGuard is running or AdGuard Local is enabled, Switch WAN function will not update the resolv.conf file. (Collaboration with SomeWhereOverTheRainbow)
- Optimized the way script loads configuration variables.
- Service restarts will dynamically check which services need to be restarted.
- Optimized Boot Delay Timer functionality and changed logging messages to clarify how the Boot Delay Timer effects the script startup.
- WAN Status will now check if a cable is unplugged.
- Resolved issues with Load Balancing Mode introduced in v1.5.4
- Enhancements to Load Balancing Mode
- When in Load Balancing Mode, OpenVPN Split Tunneling can be disabled where remote addresses will default to WAN0 and failover to WAN1 if WAN0 fails and back to WAN0 when it is restored. This can be changed in Configuration file using the Setting: OVPNSPLITTUNNEL (1 = Enabled / 0 = Disabled).
- Corrected issue with Cron Job creation.
- Corrected issues with IP Rules creation for Target IP Addresses.
- When in Load Balance Mode, script will create IPTables Mangle rules for marking packets if they are missing. This is to correct an issue with the firmware.
- Increased email skip default delay to 180 seconds additional to Boot Delay Timer. Adjustable in configuration file using Setting: SKIPEMAILSYSTEMUPTIME (Value is in seconds).
- Script will check for supported ASUS Merlin Firmware Versions
- Script will verify System Binaries are used over Optional Binaries
- Added email functionality for Load Balancing Mode. If a WAN Interface fails, an email notification will be sent if enabled.
- Corrected issue where temporary file for mail would not have correct write permissions to create email for notification.
- Script will now create NAT Rules for services that are enabled.
- Load Balancing Rule Priority, WAN0/WAN1 Route Tables, FW Marks/Masks, IP Rule Priorities, and OpenVPN WAN Priority (Split Tunneling Disabled) are now all customizable using the configuration file. Recommended to leave default unless necessary to change.
- WAN Interface restarts during WAN Status checks will only wait 30 seconds maximum to check status again.
- Corrected issue where Monitor mode would stay running in background, now will exit background process when escaped with Ctrl + C.
- Added a restart mode to reload WAN Failover, use argument "restart". Config, Update, and Restart Mode will wait before cronjob cycle to kill script and allow cron job to reload script.
- Kill Mode will now delete the cron job to prevent WAN Failover from relaunching.
- If YazFi is installed and has a scheduled Cron Job, WAN Failover will trigger YazFi to update if installed in default location (/jffs/scripts/YazFi).
- Configured debug logging, to enable debug logging, set System Log > Log only messages more urgent than: debug
- Load Balancer will now work with Guest Networks created.
- Fixed issue where email would fail to send if --insecure flag was removed from amtm configuration.
- When running WAN Failover from the Console, the script will actively display the current Packet Loss. 0% will be displayed in Green, 100% will be displayed in Red, and 1% - 99% will be displayed in Yellow.
Hi,

First I would like to thank you for continuous improvement to this script.
Second: starting with the beta you included this way of update, in my case, the last step is failing.
It is only my case? I am talking about last row from below log.

Thank you!

Code:
Jul 11 15:19:13 src@B88X wan-failover.sh: Debug - Script Mode: restart
Jul 11 15:19:13 src@B88X wan-failover.sh: Debug - Function: killscript
Jul 11 15:19:13 src@B88X wan-failover.sh: Restart - Restarting wan-failover.sh ***This can take up to approximately 1 minute***
Jul 11 15:19:13 src@B88X wan-failover.sh: Debug - Calling CronJob to be rescheduled
Jul 11 15:19:13 src@B88X wan-failover.sh: Debug - Function: cronjob
Jul 11 15:19:14 src@B88X wan-failover.sh: Debug - Waiting to kill script until seconds into the minute are above 45 seconds or below 50 seconds
Jul 11 15:19:46 src@B88X wan-failover.sh: Debug - Selecting PIDs to kill
Jul 11 15:19:47 src@B88X wan-failover.sh: Debug - Checking if PIDs array is null ***Process ID:
Jul 11 15:19:47 src@B88X wan-failover.sh: Restart - Waiting for wan-failover.sh to restart from CronJob
Jul 11 15:19:47 src@B88X wan-failover.sh: Debug - System Uptime: 72404 Seconds
Jul 11 15:19:47 src@B88X wan-failover.sh: Debug - Restart Timeout is in 90 Seconds
Jul 11 15:21:18 src@B88X wan-failover.sh: Debug - System Uptime: 72495 Seconds
Jul 11 15:21:18 src@B88X wan-failover.sh: Debug - Checking if wan-failover.sh restarted
Jul 11 15:21:18 src@B88X wan-failover.sh: Debug - Checking if PIDs array is null ***Process ID:
Jul 11 15:21:18 src@B88X wan-failover.sh: Restart - Failed to restart wan-failover.sh ***Check Logs***
 
Hi,

First I would like to thank you for continuous improvement to this script.
Second: starting with the beta you included this way of update, in my case, the last step is failing.
It is only my case? I am talking about last row from below log.

Thank you!

Code:
Jul 11 15:19:13 src@B88X wan-failover.sh: Debug - Script Mode: restart
Jul 11 15:19:13 src@B88X wan-failover.sh: Debug - Function: killscript
Jul 11 15:19:13 src@B88X wan-failover.sh: Restart - Restarting wan-failover.sh ***This can take up to approximately 1 minute***
Jul 11 15:19:13 src@B88X wan-failover.sh: Debug - Calling CronJob to be rescheduled
Jul 11 15:19:13 src@B88X wan-failover.sh: Debug - Function: cronjob
Jul 11 15:19:14 src@B88X wan-failover.sh: Debug - Waiting to kill script until seconds into the minute are above 45 seconds or below 50 seconds
Jul 11 15:19:46 src@B88X wan-failover.sh: Debug - Selecting PIDs to kill
Jul 11 15:19:47 src@B88X wan-failover.sh: Debug - Checking if PIDs array is null ***Process ID:
Jul 11 15:19:47 src@B88X wan-failover.sh: Restart - Waiting for wan-failover.sh to restart from CronJob
Jul 11 15:19:47 src@B88X wan-failover.sh: Debug - System Uptime: 72404 Seconds
Jul 11 15:19:47 src@B88X wan-failover.sh: Debug - Restart Timeout is in 90 Seconds
Jul 11 15:21:18 src@B88X wan-failover.sh: Debug - System Uptime: 72495 Seconds
Jul 11 15:21:18 src@B88X wan-failover.sh: Debug - Checking if wan-failover.sh restarted
Jul 11 15:21:18 src@B88X wan-failover.sh: Debug - Checking if PIDs array is null ***Process ID:
Jul 11 15:21:18 src@B88X wan-failover.sh: Restart - Failed to restart wan-failover.sh ***Check Logs***

It’s because it didn’t detect a new PID for the newly launched process, I assume it didn’t actually launch? Does the cron job exist?
Code:
cru l
 
It’s because it didn’t detect a new PID for the newly launched process, I assume it didn’t actually launch? Does the cron job exist?
Code:
cru l
The cron is there every time I checked:
Code:
/tmp/home/root#:cru l | grep  wan
*/1 * * * * /jffs/scripts/wan-failover.sh run #setup_wan_failover_run#
 
The cron is there every time I checked:
Code:
/tmp/home/root#:cru l | grep  wan
*/1 * * * * /jffs/scripts/wan-failover.sh run #setup_wan_failover_run#
Did it eventually launch from the cron job?
 
Did it eventually launch from the cron job?
Yes, it seems is running with a pid:

Code:
/tmp/home/root#:/jffs/scripts/wan-failover.sh run
wan-failover.sh - Run Mode
wan-failover.sh already running...

/tmp/home/root#:pidof wan-failover.sh
10711
 
Yes, it seems is running with a pid:

Code:
/tmp/home/root#:/jffs/scripts/wan-failover.sh run
wan-failover.sh - Run Mode
wan-failover.sh already running...

/tmp/home/root#:pidof wan-failover.sh
10711
Yea….there isn’t a clean way to relaunch a shell script that is detached from the console so this is as close as I got it, it probably wasn’t able to launch in time after being killed so I may have to increase the timeout.
 
Hi,

First I would like to thank you for continuous improvement to this script.
Second: starting with the beta you included this way of update, in my case, the last step is failing.
It is only my case? I am talking about last row from below log.

Thank you!

Code:
Jul 11 15:19:13 src@B88X wan-failover.sh: Debug - Script Mode: restart
Jul 11 15:19:13 src@B88X wan-failover.sh: Debug - Function: killscript
Jul 11 15:19:13 src@B88X wan-failover.sh: Restart - Restarting wan-failover.sh ***This can take up to approximately 1 minute***
Jul 11 15:19:13 src@B88X wan-failover.sh: Debug - Calling CronJob to be rescheduled
Jul 11 15:19:13 src@B88X wan-failover.sh: Debug - Function: cronjob
Jul 11 15:19:14 src@B88X wan-failover.sh: Debug - Waiting to kill script until seconds into the minute are above 45 seconds or below 50 seconds
Jul 11 15:19:46 src@B88X wan-failover.sh: Debug - Selecting PIDs to kill
Jul 11 15:19:47 src@B88X wan-failover.sh: Debug - Checking if PIDs array is null ***Process ID:
Jul 11 15:19:47 src@B88X wan-failover.sh: Restart - Waiting for wan-failover.sh to restart from CronJob
Jul 11 15:19:47 src@B88X wan-failover.sh: Debug - System Uptime: 72404 Seconds
Jul 11 15:19:47 src@B88X wan-failover.sh: Debug - Restart Timeout is in 90 Seconds
Jul 11 15:21:18 src@B88X wan-failover.sh: Debug - System Uptime: 72495 Seconds
Jul 11 15:21:18 src@B88X wan-failover.sh: Debug - Checking if wan-failover.sh restarted
Jul 11 15:21:18 src@B88X wan-failover.sh: Debug - Checking if PIDs array is null ***Process ID:
Jul 11 15:21:18 src@B88X wan-failover.sh: Restart - Failed to restart wan-failover.sh ***Check Logs***
Sorry, now that I've got some coffee I notice it isn't seeing the Process IDs running.
 
Hi,

First I would like to thank you for continuous improvement to this script.
Second: starting with the beta you included this way of update, in my case, the last step is failing.
It is only my case? I am talking about last row from below log.

Thank you!

Code:
Jul 11 15:19:13 src@B88X wan-failover.sh: Debug - Script Mode: restart
Jul 11 15:19:13 src@B88X wan-failover.sh: Debug - Function: killscript
Jul 11 15:19:13 src@B88X wan-failover.sh: Restart - Restarting wan-failover.sh ***This can take up to approximately 1 minute***
Jul 11 15:19:13 src@B88X wan-failover.sh: Debug - Calling CronJob to be rescheduled
Jul 11 15:19:13 src@B88X wan-failover.sh: Debug - Function: cronjob
Jul 11 15:19:14 src@B88X wan-failover.sh: Debug - Waiting to kill script until seconds into the minute are above 45 seconds or below 50 seconds
Jul 11 15:19:46 src@B88X wan-failover.sh: Debug - Selecting PIDs to kill
Jul 11 15:19:47 src@B88X wan-failover.sh: Debug - Checking if PIDs array is null ***Process ID:
Jul 11 15:19:47 src@B88X wan-failover.sh: Restart - Waiting for wan-failover.sh to restart from CronJob
Jul 11 15:19:47 src@B88X wan-failover.sh: Debug - System Uptime: 72404 Seconds
Jul 11 15:19:47 src@B88X wan-failover.sh: Debug - Restart Timeout is in 90 Seconds
Jul 11 15:21:18 src@B88X wan-failover.sh: Debug - System Uptime: 72495 Seconds
Jul 11 15:21:18 src@B88X wan-failover.sh: Debug - Checking if wan-failover.sh restarted
Jul 11 15:21:18 src@B88X wan-failover.sh: Debug - Checking if PIDs array is null ***Process ID:
Jul 11 15:21:18 src@B88X wan-failover.sh: Restart - Failed to restart wan-failover.sh ***Check Logs***

I get the same type of info with V1.5.5-beta10:

Code:
Jul 11 11:30:16 wan-failover.sh: Debug - Script Mode: restart
Jul 11 11:30:16 wan-failover.sh: Debug - Function: killscript
Jul 11 11:30:16 wan-failover.sh: Restart - Restarting wan-failover.sh ***This can take up to approximately 1 minute***
Jul 11 11:30:16 wan-failover.sh: Debug - Calling CronJob to be rescheduled
Jul 11 11:30:16 wan-failover.sh: Debug - Function: cronjob
Jul 11 11:30:16 wan-failover.sh: Debug - Waiting to kill script until seconds into the minute are above 45 seconds or below 50 seconds
Jul 11 11:30:46 wan-failover.sh: Debug - Selecting PIDs to kill
Jul 11 11:30:46 wan-failover.sh: Debug - Checking if PIDs array is null ***Process ID:
Jul 11 11:30:46 wan-failover.sh: Restart - Waiting for wan-failover.sh to restart from CronJob
Jul 11 11:30:46 wan-failover.sh: Debug - System Uptime: 431628 Seconds
Jul 11 11:30:46 wan-failover.sh: Debug - Restart Timeout is in 90 Seconds
Jul 11 11:32:17 wan-failover.sh: Debug - System Uptime: 431719 Seconds
Jul 11 11:32:17 wan-failover.sh: Debug - Checking if wan-failover.sh restarted
Jul 11 11:32:17 wan-failover.sh: Debug - Checking if PIDs array is null ***Process ID:
Jul 11 11:32:17 wan-failover.sh: Restart - Failed to restart wan-failover.sh ***Check Logs***
 
I get the same type of info with V1.5.5-beta10:

Code:
Jul 11 11:30:16 wan-failover.sh: Debug - Script Mode: restart
Jul 11 11:30:16 wan-failover.sh: Debug - Function: killscript
Jul 11 11:30:16 wan-failover.sh: Restart - Restarting wan-failover.sh ***This can take up to approximately 1 minute***
Jul 11 11:30:16 wan-failover.sh: Debug - Calling CronJob to be rescheduled
Jul 11 11:30:16 wan-failover.sh: Debug - Function: cronjob
Jul 11 11:30:16 wan-failover.sh: Debug - Waiting to kill script until seconds into the minute are above 45 seconds or below 50 seconds
Jul 11 11:30:46 wan-failover.sh: Debug - Selecting PIDs to kill
Jul 11 11:30:46 wan-failover.sh: Debug - Checking if PIDs array is null ***Process ID:
Jul 11 11:30:46 wan-failover.sh: Restart - Waiting for wan-failover.sh to restart from CronJob
Jul 11 11:30:46 wan-failover.sh: Debug - System Uptime: 431628 Seconds
Jul 11 11:30:46 wan-failover.sh: Debug - Restart Timeout is in 90 Seconds
Jul 11 11:32:17 wan-failover.sh: Debug - System Uptime: 431719 Seconds
Jul 11 11:32:17 wan-failover.sh: Debug - Checking if wan-failover.sh restarted
Jul 11 11:32:17 wan-failover.sh: Debug - Checking if PIDs array is null ***Process ID:
Jul 11 11:32:17 wan-failover.sh: Restart - Failed to restart wan-failover.sh ***Check Logs***
Was the script actively running when you guys were trying to restart? I wrote the logic with it already running in mind but I am adjusting it now to schedule the Cron Job regardless and then kill the old process IDs if it is running prior to schedule.
 
Last edited:
Was the script actively running when you guys were trying to restart? I wrote the logic with it already running in mind but I am adjusting it now to schedule the Cron Job regardless and then kill the old process IDs if it is running prior to schedule.
I had the same in the end I uninstalled and reinstalled.
 
Was the script actively running when you guys were trying to restart? I wrote the logic with it already running in mind but I am adjusting it now to schedule the Cron Job regardless and then kill the old process IDs if it is running prior to schedule.

yes the script was actively running already.
 
yes the script was actively running already.
Ok, I reworked some of the logic for restart so will send an extra beta release for testing before official update.
 
v1.5.5-beta11 Release: ***Disclaimer: This is a beta release and has been untested***

***This is an additional beta release due to unresolved issues in v1.5.5-beta10***


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.5-beta11.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

***Highlight: While in Load Balancing Mode, OpenVPN Split Tunneling can be Disabled defaulting to WAN0 and failover to WAN1 if WAN0 fails***

***Highlight: Email Notifications will be sent for Load Balancing Mode if a WAN failure occurs.***

***Highlight: YazFi will be triggered to update if installed and running during Failover.***


***Highlight: Debug Logs can be generated to help diagnose issues. To enable set System Log > Log only messages more urgent than: debug***

***Highlight: When running script in console, Packet Loss is actively displayed. 0% will be displayed in Green, 100% will be displayed in Red, and 1% - 99% will be displayed in Yellow.***

Example: Load Balance Mode actively monitoring both WAN0 and WAN.
View attachment 42645

***WARNING: Kill Mode will now delete cron job, use restart mode to schedule script to restart***


Release Notes:
v1.5.5-beta11
- General optimization of script logic
- If AdGuard is running or AdGuard Local is enabled, Switch WAN function will not update the resolv.conf file. (Collaboration with SomeWhereOverTheRainbow)
- Optimized the way script loads configuration variables.
- Service restarts will dynamically check which services need to be restarted.
- Optimized Boot Delay Timer functionality and changed logging messages to clarify how the Boot Delay Timer effects the script startup.
- WAN Status will now check if a cable is unplugged.
- Resolved issues with Load Balancing Mode introduced in v1.5.4
- Enhancements to Load Balancing Mode
- When in Load Balancing Mode, OpenVPN Split Tunneling can be disabled where remote addresses will default to WAN0 and failover to WAN1 if WAN0 fails and back to WAN0 when it is restored. This can be changed in Configuration file using the Setting: OVPNSPLITTUNNEL (1 = Enabled / 0 = Disabled).
- Corrected issue with Cron Job creation.
- Corrected issues with IP Rules creation for Target IP Addresses.
- When in Load Balance Mode, script will create IPTables Mangle rules for marking packets if they are missing. This is to correct an issue with the firmware.
- Increased email skip default delay to 180 seconds additional to Boot Delay Timer. Adjustable in configuration file using Setting: SKIPEMAILSYSTEMUPTIME (Value is in seconds).
- Script will check for supported ASUS Merlin Firmware Versions
- Script will verify System Binaries are used over Optional Binaries
- Added email functionality for Load Balancing Mode. If a WAN Interface fails, an email notification will be sent if enabled.
- Corrected issue where temporary file for mail would not have correct write permissions to create email for notification.
- Script will now create NAT Rules for services that are enabled.
- Load Balancing Rule Priority, WAN0/WAN1 Route Tables, FW Marks/Masks, IP Rule Priorities, and OpenVPN WAN Priority (Split Tunneling Disabled) are now all customizable using the configuration file. Recommended to leave default unless necessary to change.
- WAN Interface restarts during WAN Status checks will only wait 30 seconds maximum to check status again.
- Corrected issue where Monitor mode would stay running in background, now will exit background process when escaped with Ctrl + C.
- Added a restart mode to reload WAN Failover, use argument "restart". Config, Update, and Restart Mode will wait before cronjob cycle to kill script and allow cron job to reload script.
- Kill Mode will now delete the cron job to prevent WAN Failover from relaunching.
- If YazFi is installed and has a scheduled Cron Job, WAN Failover will trigger YazFi to update if installed in default location (/jffs/scripts/YazFi).
- Configured debug logging, to enable debug logging, set System Log > Log only messages more urgent than: debug
- Load Balancer will now work with Guest Networks created.
- Fixed issue where email would fail to send if --insecure flag was removed from amtm configuration.
- When running WAN Failover from the Console, the script will actively display the current Packet Loss. 0% will be displayed in Green, 100% will be displayed in Red, and 1% - 99% will be displayed in Yellow.
- Added email timeout option, adjusted in configuration using EMAILTIMEOUT setting.
- Moved ping process into seperate function and called by the failover monitors.
 
Installed V1.5.5-Beta11 Dual WAN Script over V1.5.5-Beta10 in a Dual WAN Failover mode:

Below is debugged system log after install (Appears to be good so far with IP's redacted, maybe couple spelling errors below). Will test Dual WAN Failover as per my previous steps when the network is quiet.....

Code:
Jul 12 00:24:06 wan-failover.sh: Debug - Script Mode: restart
Jul 12 00:24:06 wan-failover.sh: Debug - Function: killscript
Jul 12 00:24:06 wan-failover.sh: Debug - Selecting PIDs to kill
Jul 12 00:24:06 wan-failover.sh: Debug - Calling CronJob to be rescheduled
Jul 12 00:24:06 wan-failover.sh: Debug - Function: cronjob
Jul 12 00:24:06 wan-failover.sh: Debug - ***Checking if PIDs array is null*** Process ID:  31355
Jul 12 00:24:06 wan-failover.sh: Restart - Restarting wan-failover.sh ***This can take up to approximately 1 minute***
Jul 12 00:24:06 wan-failover.sh: Debug - Waiting to kill script until seconds into the minute are above 40 seconds or below 45 seconds
Jul 12 00:24:40 wan-failover.sh: Restart - Killing wan-failover.sh Process ID: 31355
Jul 12 00:24:40 wan-failover.sh: Restart - Killed wan-failover.sh Process ID: 31355
Jul 12 00:24:40 wan-failover.sh: Restart - Waiting for wan-failover.sh to restart from CronJob
Jul 12 00:24:40 wan-failover.sh: Debug - System Uptime: 478062 Seconds
Jul 12 00:24:40 wan-failover.sh: Debug - Restart Timeout is in 120 Seconds
Jul 12 00:25:00 wan-failover.sh: Debug - Locked File: /var/lock/wan-failover.lock
Jul 12 00:25:00 wan-failover.sh: Debug - Trap set to remove /var/lock/wan-failover.lock on exit
Jul 12 00:25:00 wan-failover.sh: Debug - Script Mode: run
Jul 12 00:25:00 wan-failover.sh: Debug - Function: systemcheck
Jul 12 00:25:00 wan-failover.sh: Debug - Log Level: 7
Jul 12 00:25:00 wan-failover.sh: Process ID - 10066
Jul 12 00:25:00 wan-failover.sh: Debug - Function: nvramcheck
Jul 12 00:25:00 wan-failover.sh: Debug - ***NVRAM Check Passed***
Jul 12 00:25:00 wan-failover.sh: Version - v1.5.5
Jul 12 00:25:00 wan-failover.sh: Debug - Firmware: 386.7
Jul 12 00:25:00 wan-failover.sh: Debug - Function: setvariables
Jul 12 00:25:00 wan-failover.sh: Debug - Reading /jffs/configs/wan-failover.conf
Jul 12 00:25:00 wan-failover.sh: Debug - Checking for missing configuration options
Jul 12 00:25:00 wan-failover.sh: Debug - Setting OVPNWAN1PRIORITY Default: Priority 200
Jul 12 00:25:00 wan-failover.sh: Debug - Reading /jffs/configs/wan-failover.conf
Jul 12 00:25:00 wan-failover.sh: Debug - Function: debuglog
Jul 12 00:25:00 wan-failover.sh: Debug - Function: nvramcheck
Jul 12 00:25:00 wan-failover.sh: Debug - ***NVRAM Check Passed***
Jul 12 00:25:00 wan-failover.sh: Debug - Dual WAN Mode: fo
Jul 12 00:25:00 wan-failover.sh: Debug - Dual WAN Interfaces: wan lan
Jul 12 00:25:00 wan-failover.sh: Debug - ASUS Factory Watchdog: 0
Jul 12 00:25:00 wan-failover.sh: Debug - Firewall Enabled: 1
Jul 12 00:25:00 wan-failover.sh: Debug - LEDs Disabled: 0
Jul 12 00:25:00 wan-failover.sh: Debug - QoS Enabled: 1
Jul 12 00:25:00 wan-failover.sh: Debug - DDNS Hostname: all.dnsomatic.com
Jul 12 00:25:00 wan-failover.sh: Debug - LAN Hostname: XXXXXXX
Jul 12 00:25:00 wan-failover.sh: Debug - WAN IPv6 Address:
Jul 12 00:25:00 wan-failover.sh: Debug - Default Route: default via X.X.X.X dev eth0
Jul 12 00:25:00 wan-failover.sh: Debug - WAN0 Enabled: 1
Jul 12 00:25:00 wan-failover.sh: Debug - WAN0 Routing Table Default Route: default via X.X.X.X dev eth0
Jul 12 00:25:00 wan-failover.sh: Debug - WAN0 Target IP Rule: 100: from all to 1.1.1.1 iif lo lookup wan0
Jul 12 00:25:00 wan-failover.sh: Debug - WAN0 IP Address: X.X.X.X
Jul 12 00:25:00 wan-failover.sh: Debug - WAN0 Real IP Address:
Jul 12 00:25:00 wan-failover.sh: Debug - WAN0 Real IP Address State: 0
Jul 12 00:25:00 wan-failover.sh: Debug - WAN0 Gateway IP: X.X.X.X
Jul 12 00:25:00 wan-failover.sh: Debug - WAN0 Gateway Interface: eth0
Jul 12 00:25:00 wan-failover.sh: Debug - WAN0 Interface: eth0
Jul 12 00:25:00 wan-failover.sh: Debug - WAN0 State: 2
Jul 12 00:25:00 wan-failover.sh: Debug - WAN0 Primary Status: 1
Jul 12 00:25:00 wan-failover.sh: Debug - WAN0 Target IP Address: 1.1.1.1
Jul 12 00:25:00 wan-failover.sh: Debug - WAN0 Routing Table: 100
Jul 12 00:25:00 wan-failover.sh: Debug - WAN0 IP Rule Priority: 100
Jul 12 00:25:00 wan-failover.sh: Debug - WAN0 Mark: 0x80000000
Jul 12 00:25:00 wan-failover.sh: Debug - WAN0 Mask: 0xf0000000
Jul 12 00:25:00 wan-failover.sh: Debug - WAN0 From WAN Priority: 200
Jul 12 00:25:00 wan-failover.sh: Debug - WAN0 To WAN Priority: 400
Jul 12 00:25:00 wan-failover.sh: Debug - WAN1 Enabled: 1
Jul 12 00:25:00 wan-failover.sh: Debug - WAN1 Routing Table Default Route: default via X.X.X.X dev eth4
Jul 12 00:25:01 wan-failover.sh: Debug - WAN1 Target IP Rule: 100: from all to 1.0.0.1 iif lo lookup wan1
Jul 12 00:25:01 wan-failover.sh: Debug - WAN1 IP Address: X.X.X.X
Jul 12 00:25:01 wan-failover.sh: Debug - WAN1 Real IP Address: X.X.X.X
Jul 12 00:25:01 wan-failover.sh: Debug - WAN1 Real IP Address State: 2
Jul 12 00:25:01 wan-failover.sh: Debug - WAN1 Gateway IP: X.X.X.X
Jul 12 00:25:01 wan-failover.sh: Debug - WAN1 Gateway Interface: eth4
Jul 12 00:25:01 wan-failover.sh: Debug - WAN1 Interface: eth4
Jul 12 00:25:01 wan-failover.sh: Debug - WAN1 State: 2
Jul 12 00:25:01 wan-failover.sh: Debug - WAN1 Primary Status: 0
Jul 12 00:25:01 wan-failover.sh: Debug - WAN1 Target IP Address: 1.0.0.1
Jul 12 00:25:01 wan-failover.sh: Debug - WAN1 Routing Table: 200
Jul 12 00:25:01 wan-failover.sh: Debug - WAN1 IP Rule Priority: 100
Jul 12 00:25:01 wan-failover.sh: Debug - WAN1 Mark: 0x90000000
Jul 12 00:25:01 wan-failover.sh: Debug - WAN1 Mask: 0xf0000000
Jul 12 00:25:01 wan-failover.sh: Debug - WAN1 From WAN Priority: 200
Jul 12 00:25:01 wan-failover.sh: Debug - WAN1 To WAN Priority: 400
Jul 12 00:25:01 wan-failover.sh: Debug - Function: wanstatus
Jul 12 00:25:01 wan-failover.sh: Debug - Function: nvramcheck
Jul 12 00:25:01 wan-failover.sh: Debug - ***NVRAM Check Passed***
Jul 12 00:25:01 wan-failover.sh: Debug - System Uptime: 478083 Seconds
Jul 12 00:25:01 wan-failover.sh: Debug - Boot Delay Timer: 30 Seconds
Jul 12 00:25:01 wan-failover.sh: WAN Status - wan0 enabled
Jul 12 00:25:01 wan-failover.sh: Debug - System Uptime: 478083 Seconds
Jul 12 00:25:01 wan-failover.sh: Debug - Checking if wan-failover.sh restarted
Jul 12 00:25:01 wan-failover.sh: Debug - ***Checking if PIDs array is null*** Process ID:  10065 10066
Jul 12 00:25:01 wan-failover.sh: Restart - Successfully Restarted wan-failover.sh Process ID:  10065 10066
Jul 12 00:25:05 wan-failover.sh: Debug - wan0 Packet Loss: 0%%
Jul 12 00:25:05 wan-failover.sh: WAN Status - wan0 has 0% packet loss
Jul 12 00:25:05 wan-failover.sh: Debug - wan0 Status: CONNECTED
Jul 12 00:25:05 wan-failover.sh: WAN Status - wan1 enabled
Jul 12 00:25:09 wan-failover.sh: Debug - wan1 Packet Loss: 0%%
Jul 12 00:25:09 wan-failover.sh: WAN Status - wan1 has 0% packet loss
Jul 12 00:25:09 wan-failover.sh: Debug - wan1 Status: CONNECTED
Jul 12 00:25:09 wan-failover.sh: Debug - Function: checkiprules
Jul 12 00:25:09 wan-failover.sh: Debug - Function: nvramcheck
Jul 12 00:25:09 wan-failover.sh: Debug - ***NVRAM Check Passed***
Jul 12 00:25:09 wan-failover.sh: Debug - wan0 UPNP Enabled: 1
Jul 12 00:25:09 wan-failover.sh: Debug - wan0 NAT Enabled: 1
Jul 12 00:25:09 wan-failover.sh: Debug - wan1 UPNP Enabled: 1
Jul 12 00:25:09 wan-failover.sh: Debug - wan1 NAT Enabled: 1
Jul 12 00:25:09 wan-failover.sh: Debug - WAN0STATUS: CONNECTED
Jul 12 00:25:09 wan-failover.sh: Debug - WAN1STATUS: CONNECTED
Jul 12 00:25:09 wan-failover.sh: Debug - Function: wan0active
Jul 12 00:25:09 wan-failover.sh: Debug - Function: nvramcheck
Jul 12 00:25:09 wan-failover.sh: Debug - ***NVRAM Check Passed***
Jul 12 00:25:09 wan-failover.sh: WAN0 Active - Verifying WAN0
Jul 12 00:25:09 wan-failover.sh: Debug - Function: wan0failovermonitor
Jul 12 00:25:09 wan-failover.sh: Debug - Function: nvramcheck
Jul 12 00:25:09 wan-failover.sh: Debug - ***NVRAM Check Passed***
Jul 12 00:25:09 wan-failover.sh: WAN0 Failover Monitor - Monitoring wan0 via 1.1.1.1 for Failure
 
v1.5.5-beta11 Release: ***Disclaimer: This is a beta release and has been untested***

***This is an additional beta release due to unresolved issues in v1.5.5-beta10***


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.5-beta11.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

***Highlight: While in Load Balancing Mode, OpenVPN Split Tunneling can be Disabled defaulting to WAN0 and failover to WAN1 if WAN0 fails***

***Highlight: Email Notifications will be sent for Load Balancing Mode if a WAN failure occurs.***

***Highlight: YazFi will be triggered to update if installed and running during Failover.***


***Highlight: Debug Logs can be generated to help diagnose issues. To enable set System Log > Log only messages more urgent than: debug***

***Highlight: When running script in console, Packet Loss is actively displayed. 0% will be displayed in Green, 100% will be displayed in Red, and 1% - 99% will be displayed in Yellow.***

Example: Load Balance Mode actively monitoring both WAN0 and WAN.
View attachment 42645

***WARNING: Kill Mode will now delete cron job, use restart mode to schedule script to restart***


Release Notes:
v1.5.5-beta11
- General optimization of script logic
- If AdGuard is running or AdGuard Local is enabled, Switch WAN function will not update the resolv.conf file. (Collaboration with SomeWhereOverTheRainbow)
- Optimized the way script loads configuration variables.
- Service restarts will dynamically check which services need to be restarted.
- Optimized Boot Delay Timer functionality and changed logging messages to clarify how the Boot Delay Timer effects the script startup.
- WAN Status will now check if a cable is unplugged.
- Resolved issues with Load Balancing Mode introduced in v1.5.4
- Enhancements to Load Balancing Mode
- When in Load Balancing Mode, OpenVPN Split Tunneling can be disabled where remote addresses will default to WAN0 and failover to WAN1 if WAN0 fails and back to WAN0 when it is restored. This can be changed in Configuration file using the Setting: OVPNSPLITTUNNEL (1 = Enabled / 0 = Disabled).
- Corrected issue with Cron Job creation.
- Corrected issues with IP Rules creation for Target IP Addresses.
- When in Load Balance Mode, script will create IPTables Mangle rules for marking packets if they are missing. This is to correct an issue with the firmware.
- Increased email skip default delay to 180 seconds additional to Boot Delay Timer. Adjustable in configuration file using Setting: SKIPEMAILSYSTEMUPTIME (Value is in seconds).
- Script will check for supported ASUS Merlin Firmware Versions
- Script will verify System Binaries are used over Optional Binaries
- Added email functionality for Load Balancing Mode. If a WAN Interface fails, an email notification will be sent if enabled.
- Corrected issue where temporary file for mail would not have correct write permissions to create email for notification.
- Script will now create NAT Rules for services that are enabled.
- Load Balancing Rule Priority, WAN0/WAN1 Route Tables, FW Marks/Masks, IP Rule Priorities, and OpenVPN WAN Priority (Split Tunneling Disabled) are now all customizable using the configuration file. Recommended to leave default unless necessary to change.
- WAN Interface restarts during WAN Status checks will only wait 30 seconds maximum to check status again.
- Corrected issue where Monitor mode would stay running in background, now will exit background process when escaped with Ctrl + C.
- Added a restart mode to reload WAN Failover, use argument "restart". Config, Update, and Restart Mode will wait before cronjob cycle to kill script and allow cron job to reload script.
- Kill Mode will now delete the cron job to prevent WAN Failover from relaunching.
- If YazFi is installed and has a scheduled Cron Job, WAN Failover will trigger YazFi to update if installed in default location (/jffs/scripts/YazFi).
- Configured debug logging, to enable debug logging, set System Log > Log only messages more urgent than: debug
- Load Balancer will now work with Guest Networks created.
- Fixed issue where email would fail to send if --insecure flag was removed from amtm configuration.
- When running WAN Failover from the Console, the script will actively display the current Packet Loss. 0% will be displayed in Green, 100% will be displayed in Red, and 1% - 99% will be displayed in Yellow.
- Added email timeout option, adjusted in configuration using EMAILTIMEOUT setting.
- Moved ping process into seperate function and called by the failover monitors.
Hi,

Even the job is running fine, the update kill-relaunch module is still failing:
Code:
Jul 12 10:04:52 src@B88X wan-failover.sh: Debug - Script Mode: restart
Jul 12 10:04:52 src@B88X wan-failover.sh: Debug - Function: killscript
Jul 12 10:04:52 src@B88X wan-failover.sh: Debug - Selecting PIDs to kill
Jul 12 10:04:52 src@B88X wan-failover.sh: Debug - Calling CronJob to be rescheduled
Jul 12 10:04:52 src@B88X wan-failover.sh: Debug - Function: cronjob
Jul 12 10:04:52 src@B88X wan-failover.sh: Debug - ***Checking if PIDs array is null*** Process ID:
Jul 12 10:04:52 src@B88X wan-failover.sh: Restart - ***wan-failover.sh is not running*** No Process ID Detected
Jul 12 10:04:52 src@B88X wan-failover.sh: Restart - Waiting for wan-failover.sh to restart from CronJob
Jul 12 10:04:52 src@B88X wan-failover.sh: Debug - System Uptime: 40568 Seconds
Jul 12 10:04:52 src@B88X wan-failover.sh: Debug - Restart Timeout is in 120 Seconds
Jul 12 10:06:53 src@B88X wan-failover.sh: Debug - System Uptime: 40689 Seconds
Jul 12 10:06:53 src@B88X wan-failover.sh: Debug - Checking if wan-failover.sh restarted
Jul 12 10:06:53 src@B88X wan-failover.sh: Debug - ***Checking if PIDs array is null*** Process ID:
Jul 12 10:06:53 src@B88X wan-failover.sh: Restart - Failed to restart wan-failover.sh ***Check Logs***

Code:
/tmp/home/root#:pidof wan-failover.sh
15724
 
Hi,

Even the job is running fine, the update kill-relaunch module is still failing:
Code:
Jul 12 10:04:52 src@B88X wan-failover.sh: Debug - Script Mode: restart
Jul 12 10:04:52 src@B88X wan-failover.sh: Debug - Function: killscript
Jul 12 10:04:52 src@B88X wan-failover.sh: Debug - Selecting PIDs to kill
Jul 12 10:04:52 src@B88X wan-failover.sh: Debug - Calling CronJob to be rescheduled
Jul 12 10:04:52 src@B88X wan-failover.sh: Debug - Function: cronjob
Jul 12 10:04:52 src@B88X wan-failover.sh: Debug - ***Checking if PIDs array is null*** Process ID:
Jul 12 10:04:52 src@B88X wan-failover.sh: Restart - ***wan-failover.sh is not running*** No Process ID Detected
Jul 12 10:04:52 src@B88X wan-failover.sh: Restart - Waiting for wan-failover.sh to restart from CronJob
Jul 12 10:04:52 src@B88X wan-failover.sh: Debug - System Uptime: 40568 Seconds
Jul 12 10:04:52 src@B88X wan-failover.sh: Debug - Restart Timeout is in 120 Seconds
Jul 12 10:06:53 src@B88X wan-failover.sh: Debug - System Uptime: 40689 Seconds
Jul 12 10:06:53 src@B88X wan-failover.sh: Debug - Checking if wan-failover.sh restarted
Jul 12 10:06:53 src@B88X wan-failover.sh: Debug - ***Checking if PIDs array is null*** Process ID:
Jul 12 10:06:53 src@B88X wan-failover.sh: Restart - Failed to restart wan-failover.sh ***Check Logs***

Code:
/tmp/home/root#:pidof wan-failover.sh
15724
Do you have debug logs from when the script script originally launched?
 
Hi,

Even the job is running fine, the update kill-relaunch module is still failing:
Code:
Jul 12 10:04:52 src@B88X wan-failover.sh: Debug - Script Mode: restart
Jul 12 10:04:52 src@B88X wan-failover.sh: Debug - Function: killscript
Jul 12 10:04:52 src@B88X wan-failover.sh: Debug - Selecting PIDs to kill
Jul 12 10:04:52 src@B88X wan-failover.sh: Debug - Calling CronJob to be rescheduled
Jul 12 10:04:52 src@B88X wan-failover.sh: Debug - Function: cronjob
Jul 12 10:04:52 src@B88X wan-failover.sh: Debug - ***Checking if PIDs array is null*** Process ID:
Jul 12 10:04:52 src@B88X wan-failover.sh: Restart - ***wan-failover.sh is not running*** No Process ID Detected
Jul 12 10:04:52 src@B88X wan-failover.sh: Restart - Waiting for wan-failover.sh to restart from CronJob
Jul 12 10:04:52 src@B88X wan-failover.sh: Debug - System Uptime: 40568 Seconds
Jul 12 10:04:52 src@B88X wan-failover.sh: Debug - Restart Timeout is in 120 Seconds
Jul 12 10:06:53 src@B88X wan-failover.sh: Debug - System Uptime: 40689 Seconds
Jul 12 10:06:53 src@B88X wan-failover.sh: Debug - Checking if wan-failover.sh restarted
Jul 12 10:06:53 src@B88X wan-failover.sh: Debug - ***Checking if PIDs array is null*** Process ID:
Jul 12 10:06:53 src@B88X wan-failover.sh: Restart - Failed to restart wan-failover.sh ***Check Logs***

Code:
/tmp/home/root#:pidof wan-failover.sh
15724

Try running the code a second time, as I believe I had the same issue, but running it a second time the script ran successfully. Not sure that is what @Ranger802004 wants to hear... ;)
 
Do you have debug logs from when the script script originally launched?
No, I saved only from update moment. Right after I checked the pid (second command window in my post).
 

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