WANFailover Dual WAN Failover Script

[Ranger802004]

Thanks, makes sense, what are good values to start with for Ping Count and Ping Timeout?
Or do those default to something reasonable/sensible as well?
Just trying to pre-plan and minimise downtime when I finally get a "window" to play ...

I personally use a 1 second timeout per ping with 3 ping counts to consider failure. But that doesn't work for everyone such as people on high latent connections like satellite where the ping could take 2-3 seconds to reply. Ping count is preference, you will get a faster failover with a lower count but a minor bump in the connection for a few seconds could cause failovers and failbacks really fast.

 

[JAX1337]

I have been thinking about it, would it be possible to add a command that will switch the WAN to WAN 1 and hold it in WAN 1 without switching back to WAN 0

/jffs/scripts/wan-failover.sh switchwan

this code would switch back immediately, if there is no loss on WAN 0

it is for special cases, when we need to switch to WAN1 without turning off the WAN0 modem

 

[Ranger802004]

I have been thinking about it, would it be possible to add a command that will switch the WAN to WAN 1 and hold it in WAN 1 without switching back to WAN 0

/jffs/scripts/wan-failover.sh switchwan

this code would switch back immediately, if there is no loss on WAN 0

it is for special cases, when we need to switch to WAN1 without turning off the WAN0 modem

What about disabling WAN0 in the GUI?

 

[JAX1337]

What about disabling WAN0 in the GUI?

Yea, that would do, lol

 

[Ranger802004]

Yea, that would do, lol

You could kill the failover monitor and then pass the switch command and that would do the same as well. I put that argument in there for when failovers had issues and you needed to manually switch.

 

[JAX1337]

You could kill the failover monitor and then pass the switch command and that would do the same as well. I put that argument in there for when failovers had issues and you needed to manually switch.

That would also work

 

[Ranger802004]

That would also work

I just think adding a hardcoded setting for that will make it too complicated and just using the GUI switch is simple and has same effect.

 

[Ranger802004]

I assume the quietness means everything is working well for everyone? lol

 

[Viktor Jaep]

That's what I'm assuming too... unless they're +12hrs from our timezone.

 

[Viktor Jaep]

You must be near my timezone. Lol

 

[Ranger802004]

That's what I'm assuming too... unless they're +12hrs from our timezone.

US Central

 

[Viktor Jaep]

US Central

US East representing

 

[JAX1337]

I assume the quietness means everything is working well for everyone? lol

Yup, I had multiple fail-overs this week and all went well without me even knowing. Appreciate the work you have put into this script.

Btw, I'm still on the stable release, didn't get time to test the betas @Viktor Jaep and life has been keeping me pretty busy

 

[Ranger802004]

v1.5.5 has been officially published! Review Original Post in this thread for updating. Thank you to everyone who helped test the beta releases.

 

[JAX1337]

Ran into this after update

 

[Ranger802004]

Ran into this after update

View attachment 42786

Let me make sure I uploaded without it messing up the format.

 

[Ranger802004]

Let me make sure I uploaded without it messing up the format.

Somehow that did happen, update again. It should be fixed now.

Use this command to correct that issue:

/usr/sbin/curl -s "https://raw.githubusercontent.com/Ranger802004/asusmerlin/main/wan-failover.sh" -o "/jffs/scripts/wan-failover.sh" && chmod 755 /jffs/scripts/wan-failover.sh && sh /jffs/scripts/wan-failover.sh restart

 

[JAX1337]

Somehow that did happen, update again. It should be fixed now.

Use this command to correct that issue:

/usr/sbin/curl -s "https://raw.githubusercontent.com/Ranger802004/asusmerlin/main/wan-failover.sh" -o "/jffs/scripts/wan-failover.sh" && chmod 755 /jffs/scripts/wan-failover.sh && sh /jffs/scripts/wan-failover.sh restart

It worked, testing now


don't know what this means

Edit:

Other than that

Tested all kinds of Fail-Overs Manually : Everything works as intended. Now, only real life will tell if anything will break down.

Another wonderful upgrade to an already smooth running script

 

[JohnSmith]

v1.5.5 has been officially published! Review Original Post in this thread for updating. Thank you to everyone who helped test the beta releases.

Any chance you can move the trigger for YazFi to be detected to the end of your script, after a Failover or Failback has completed?

# Trigger YazFi if installed
logger -p 6 -t "${0##*/}" "Debug - Checking if YazFi is installed"
if [ ! -z "$(cru l | grep -w "YazFi")" ] && [ -f "/jffs/scripts/YazFi" ] >/dev/null;then
  logger -p 4 -st "${0##*/}" "Service Restart - Triggering YazFi to update"
  sh /jffs/scripts/YazFi check &
fi

Ran the test twice, both failover and failback, and three times YazFi had to wait until it checked itself via its preset 10 minute Cron Job.

The fourth time on failback, I invoked the command only a couple of minutes after failback occured:

sh /jffs/scripts/YazFi check

and I got this response via YazFi:

YazFi firewall rules not detected during persistence check, re-applying rules

YazFi v4.4.2 starting up

wl0.1 has FORCEDNS enabled, setting DNS2 to match DNS1...

wl0.1 passed validation

wl0.2 passed validation

wl0.1 (SSID: XXXXXXX) - sending all interface internet traffic over WAN interface

wl0.2 (SSID: XXXXX) - sending all interface internet traffic over WAN interface

Forcing YazFi Guest WiFi clients to reauthenticate

YazFi v4.4.2 completed successfully

At this point, the wl0.2 IOT devices were connected and usable.

Otherwise all FailOver and Failback tests were successful for ISP01 and ISP02.

 

[Ranger802004]

Any chance you can move the trigger for YazFi to be detected to the end of your script, after a Failover or Failback has completed?

# Trigger YazFi if installed
logger -p 6 -t "${0##*/}" "Debug - Checking if YazFi is installed"
if [ ! -z "$(cru l | grep -w "YazFi")" ] && [ -f "/jffs/scripts/YazFi" ] >/dev/null;then
  logger -p 4 -st "${0##*/}" "Service Restart - Triggering YazFi to update"
  sh /jffs/scripts/YazFi check &
fi

Ran the test twice, both failover and failback, and three times YazFi had to wait until it checked itself via its preset 10 minute Cron Job.

The fourth time on failback, I invoked the command only a couple of minutes after failback occured:

sh /jffs/scripts/YazFi check

and I got this response via YazFi:

YazFi firewall rules not detected during persistence check, re-applying rules

YazFi v4.4.2 starting up

wl0.1 has FORCEDNS enabled, setting DNS2 to match DNS1...

wl0.1 passed validation

wl0.2 passed validation

wl0.1 (SSID: XXXXXXX) - sending all interface internet traffic over WAN interface

wl0.2 (SSID: XXXXX) - sending all interface internet traffic over WAN interface

Forcing YazFi Guest WiFi clients to reauthenticate

YazFi v4.4.2 completed successfully

At this point, the wl0.2 IOT devices were connected and usable.

Otherwise all FailOver and Failback tests were successful for ISP01 and ISP02.

YazFi is triggered post Failover already in the service restarts.