WANFailover Dual WAN Failover Script

[Ranger802004]

Dear Ranger 802004, thank you for your help and an excellent script, I made a rollback to 1.5.6. I realized one thing that you can't talk about script errors here if someone works, but you don't, since it is perceived negatively by users, you need to speak only in a positive way even if something does not work as it should. Thanks again for your scripts, you are doing the right thing, good luck with new developments.

I am 100% for my users to find errors and report them to me, what I’m trying to get at though with this particular issue is that 90% of it to work involves proper configuration in Scribe.

 

[lbtboy]

I am 100% for my users to find errors and report them to me, what I’m trying to get at though with this particular issue is that 90% of it to work involves proper configuration in Scribe.

This is your opinion, and users are only for singing praises to you, so I will silently monitor the development of your projects, even if there are mistakes in them.

P.S I showed you that Scribe is configured correctly

 

[Ranger802004]

This is your opinion, and users are only for singing praises to you, so I will silently monitor the development of your projects, even if there are mistakes in them.

P.S I showed you that Scribe is configured correctly

Did you verify the logs are going to the file you specified? Perhaps you could open the file and verify there are logs being generated in it?

 

[lbtboy]

Did you verify the logs are going to the file you specified? Perhaps you could open the file and verify there are logs being generated in it?

Of course I checked, it's empty. Let's close this topic so as not to annoy other users who have it working, otherwise they will perceive it as negative criticism from my side. Thanks again for the help.

 

[Stephen Harrington]

And so it goes …

 

[Ranger802004]

Of course I checked, it's empty. Let's close this topic so as not to annoy other users who have it working, otherwise they will perceive it as negative criticism from my side. Thanks again for the help.

Ok @lbtboy, you have to get Scribe properly configured where your logs are going to that file you specified (This is a function of Scribe, not WAN Failover). Once you get the logs going to that file properly the CUSTOMLOGPATH Option in WAN Failover should read that file for logs when using Monitor Mode. I'm not asking for praises or anything of such, if there was an issue with my tool I'd like to resolve it and I'm sure you are aware of this from our previous interactions, however, as stated before with this particular case you need to have Scribe properly configured before proceeding forward on testing. That's not an opinion that is the 3rd party tool you are using for log management on your device and it is what you use to manage your log files, my script doesn't manage your system logger, I simply added an option for you to monitor a custom log path if one is properly configured. If your log file is empty that means Scribe is not forwarding your logs there as desired.

 

[VIper_Rus]

I don’t understand a little what is at stake, but scribe works for me, I didn’t have to specify the path to the log in the script.

p.s. I sort of understood. This option is needed in order not to write the log to another place, but for the monitor mode to see the recorded log

p.s.s Yes, it's true. Until I wrote down the path to the config new path to the log, the monitor mode did not work. Now works. Why does it keep saying "Removing deprecated option: PACKETSIZE from /jffs/configs/wan-failover.conf" ? I no longer have such a parameter in the config.

 

[Ranger802004]

View attachment 43823

I don’t understand a little what is at stake, but scribe works for me, I didn’t have to specify the path to the log in the script.

p.s. I sort of understood. This option is needed in order not to write the log to another place, but for the monitor mode to see the recorded log

p.s.s Yes, it's true. Until I wrote down the path to the config new path to the log, the monitor mode did not work. Now works. Why does it keep saying "Removing deprecated option: PACKETSIZE from /jffs/configs/wan-failover.conf" ? I no longer have such a parameter in the config.

View attachment 43822

That's actually a minor bug I found and already fixed, just reinstall the updated revision, your reported version will show as v1.5.7-beta1c

 

[VIper_Rus]

That's actually a minor bug I found and already fixed, just reinstall the updated revision, your reported version will show as v1.5.7-beta1c

I understand that the bug is minor, I just saw it and asked I just made a /jffs/scripts/wan-failover.sh update and then ran /jffs/scripts/wan-failover.sh monitor, the bug is present.

 

[Ranger802004]

I understand that the bug is minor, I just saw it and asked I just made a /jffs/scripts/wan-failover.sh update and then ran /jffs/scripts/wan-failover.sh monitor, the bug is present.

Let me double check it, I know I was working on this and believed I remedied it but I'll take a second look.

 

[ttgapers]

All good this time around. Had to manually switch off QoS again though.

Cheers

 

[Ranger802004]

All good this time around. Had to manually switch off QoS again though.

View attachment 43838

Cheers

During initial start or failover?

 

[ttgapers]

During initial start or failover?

On initial start after update, it re-enabled QoS on my primary WAN0 connection although config says to keep it disabled on WAN0.

 

[amplatfus]

Hi Ranger802004,

I didn't tested for a while, even I did updated on every update and thank you for all improvements.
I did a update to v1.5.7-beta1c too. I did a restart of RT-AX88U router.

I switched off the modem of Primary WAN (PPPoE) and status of Secondary WAN (4G USB stick) became for few moments Disconected or for a few moments Hot-Standby but never Connected.

Could you please take a look?

When entering in monitor mode I get:

/tmp/home/root#:/jffs/scripts/wan-failover.sh monitor
wan-failover.sh - Monitor Mode
Cannot find device "ppp0"

In logs all I can find is this, nothing from now is Aug 26 20:57:

May  5 08:05:37 wan-failover.sh: Debug - Script Mode: cron
May  5 08:05:37 wan-failover.sh: Debug - Function: cronjob
May  5 08:05:52 wan-failover.sh: Debug - Script Mode: cron
May  5 08:05:52 wan-failover.sh: Debug - Function: cronjob
Aug 26 01:57:19 src@B88X wan-failover.sh: Packet Loss Detected - WAN0 Packet Loss: 10%
Aug 26 01:57:29 src@B88X wan-failover.sh: Packet Loss Detected - WAN0 Packet Loss: 50%
Aug 26 01:57:39 src@B88X wan-failover.sh: Packet Loss Detected - WAN0 Packet Loss: 20%
Aug 26 01:59:21 src@B88X wan-failover.sh: Packet Loss Detected - WAN0 Packet Loss: 10%
Aug 26 01:59:31 src@B88X wan-failover.sh: Packet Loss Detected - WAN0 Packet Loss: 40%

When entering in switchwan mode I get:

/tmp/home/root#:/jffs/scripts/wan-failover.sh switchwan
wan-failover.sh - Switch WAN Mode
Are you sure you want to switch Primary WAN? ***Enter Y for Yes or N for No***y
Cannot find device "ppp0"
wan-failover.sh: WAN Switch - Switching wan1 to Primary WAN
wan-failover.sh: WAN Switch - WAN IP Address: 192.168.7.122
wan-failover.sh: WAN Switch - WAN Gateway IP: 192.168.7.1
wan-failover.sh: WAN Switch - WAN Interface: eth8
Cannot find device "ppp0"
wan-failover.sh: WAN Switch - Adding default route via 192.168.7.1 dev eth8
wan-failover.sh: WAN Switch - Added default route via 192.168.7.1 dev eth8
wan-failover.sh: WAN Switch - Disabling QoS Bandwidth Settings

Done.
wan-failover.sh: WAN Switch - Stopped qos service
wan-failover.sh: WAN Switch - Switching wan1 to Primary WAN
wan-failover.sh: WAN Switch - WAN IP Address: 192.168.7.122
wan-failover.sh: WAN Switch - WAN Gateway IP: 192.168.7.1
wan-failover.sh: WAN Switch - WAN Interface: eth8
Cannot find device "ppp0"
wan-failover.sh: WAN Switch - Adding default route via 192.168.7.1 dev eth8
wan-failover.sh: WAN Switch - Added default route via 192.168.7.1 dev eth8
wan-failover.sh: WAN Switch - Disabling QoS Bandwidth Settings

Done.
wan-failover.sh: WAN Switch - Stopped qos service
Cannot find device "ppp0"
wan-failover.sh: Service Restart - Restarting dnsmasq service

Done.
wan-failover.sh: Service Restart - Restarted dnsmasq service
wan-failover.sh: Service Restart - Restarting firewall service

Done.
wan-failover.sh: Service Restart - Restarted firewall service
wan-failover.sh: Service Restart - Restarting OpenVPN Server 1

Done.
wan-failover.sh: Service Restart - Restarted OpenVPN Server 1
iptables: Resource temporarily unavailable.

BR,
amplatfus

 

[Ranger802004]

Hi Ranger802004,

I didn't tested for a while, even I did updated on every update and thank you for all improvements.
I did a update to v1.5.7-beta1c too. I did a restart of RT-AX88U router.

I switched off the modem of Primary WAN (PPPoE) and status of Secondary WAN (4G USB stick) became for few moments Disconected or for a few moments Hot-Standby but never Connected.

Could you please take a look?

When entering in monitor mode I get:

/tmp/home/root#:/jffs/scripts/wan-failover.sh monitor
wan-failover.sh - Monitor Mode
Cannot find device "ppp0"

In logs all I can find is this, nothing from now is Aug 26 20:57:

May  5 08:05:37 wan-failover.sh: Debug - Script Mode: cron
May  5 08:05:37 wan-failover.sh: Debug - Function: cronjob
May  5 08:05:52 wan-failover.sh: Debug - Script Mode: cron
May  5 08:05:52 wan-failover.sh: Debug - Function: cronjob
Aug 26 01:57:19 src@B88X wan-failover.sh: Packet Loss Detected - WAN0 Packet Loss: 10%
Aug 26 01:57:29 src@B88X wan-failover.sh: Packet Loss Detected - WAN0 Packet Loss: 50%
Aug 26 01:57:39 src@B88X wan-failover.sh: Packet Loss Detected - WAN0 Packet Loss: 20%
Aug 26 01:59:21 src@B88X wan-failover.sh: Packet Loss Detected - WAN0 Packet Loss: 10%
Aug 26 01:59:31 src@B88X wan-failover.sh: Packet Loss Detected - WAN0 Packet Loss: 40%

When entering in switchwan mode I get:

/tmp/home/root#:/jffs/scripts/wan-failover.sh switchwan
wan-failover.sh - Switch WAN Mode
Are you sure you want to switch Primary WAN? ***Enter Y for Yes or N for No***y
Cannot find device "ppp0"
wan-failover.sh: WAN Switch - Switching wan1 to Primary WAN
wan-failover.sh: WAN Switch - WAN IP Address: 192.168.7.122
wan-failover.sh: WAN Switch - WAN Gateway IP: 192.168.7.1
wan-failover.sh: WAN Switch - WAN Interface: eth8
Cannot find device "ppp0"
wan-failover.sh: WAN Switch - Adding default route via 192.168.7.1 dev eth8
wan-failover.sh: WAN Switch - Added default route via 192.168.7.1 dev eth8
wan-failover.sh: WAN Switch - Disabling QoS Bandwidth Settings

Done.
wan-failover.sh: WAN Switch - Stopped qos service
wan-failover.sh: WAN Switch - Switching wan1 to Primary WAN
wan-failover.sh: WAN Switch - WAN IP Address: 192.168.7.122
wan-failover.sh: WAN Switch - WAN Gateway IP: 192.168.7.1
wan-failover.sh: WAN Switch - WAN Interface: eth8
Cannot find device "ppp0"
wan-failover.sh: WAN Switch - Adding default route via 192.168.7.1 dev eth8
wan-failover.sh: WAN Switch - Added default route via 192.168.7.1 dev eth8
wan-failover.sh: WAN Switch - Disabling QoS Bandwidth Settings

Done.
wan-failover.sh: WAN Switch - Stopped qos service
Cannot find device "ppp0"
wan-failover.sh: Service Restart - Restarting dnsmasq service

Done.
wan-failover.sh: Service Restart - Restarted dnsmasq service
wan-failover.sh: Service Restart - Restarting firewall service

Done.
wan-failover.sh: Service Restart - Restarted firewall service
wan-failover.sh: Service Restart - Restarting OpenVPN Server 1

Done.
wan-failover.sh: Service Restart - Restarted OpenVPN Server 1
iptables: Resource temporarily unavailable.

BR,
amplatfus

When you unplug the device it probably disappears as an actual interface and that’s the reason for the error. I have logic it in to handle this for USB Devices they are unplugged but this is a little different for PPPoE so I’ll have to make some revisions.

 

[Ranger802004]

On initial start after update, it re-enabled QoS on my primary WAN0 connection although config says to keep it disabled on WAN0.

Do you have logs you can forward for me?

 

[amplatfus]

When you unplug the device it probably disappears as an actual interface and that’s the reason for the error. I have logic it in to handle this for USB Devices they are unplugged but this is a little different for PPPoE so I’ll have to make some revisions.

I would like to add that some versions ago it worked when tested the same.
For instance I rollback to v1.5.6-beta14b and no issue found doing the same test.
Thank you!

 

[Ranger802004]

I would like to add that some versions ago it worked when tested the same.
For instance I rollback to v1.5.6-beta14b and no issue found doing the same test.
Thank you!

Yea there’s a lot of moving parts but when I publish an update in the next few days I’ll revise for this.

 

[ttgapers]

Do you have logs you can forward for me?

Let me re-run the latest update and send it over. Might not be until later tonight though.

 

[Ranger802004]

Let me re-run the latest update and send it over. Might not be until later tonight though.

No worries I have my son this weekend so I’m probably not even going to touch this until later tonight. The debug logs help me break down things are going wrong to remediate.