[beta] Dual WAN helper script (discontinued)

[thelonelycoder]

Hmmm i was to fast.
Failback is not working.

Aug 11 19:20:54 WAN(1)_Connection: WAN was restored.

dual wan settings are 9 / 2 / 99

now it is 19:43 - but failback didn't happen.

19:20 + 99 is more than 19:45...
Blame Asus, I do nothing unless ping times out for longer than the ping timeout.

 

[stylish_me]

That's really strange. Timeout is not for secondary wan. And it is not switching back to primary. I think you mixed two wan types..

/jffs/scripts$ /jffs/scripts/dual-wan-helper kill
Terminated
/jffs/scripts$ /jffs/scripts/dual-wan-helper

---------------------------------------------
Settings used for dual-wan-helper 1.0 beta 3

WANDOG_INTERVAL = 9 (real setting 9)
WANDOG_MAXFAIL = 2 (2)
WANDOG_FB_COUNT = 99 (99)

SLEEP_TIMEOUT = 9
PING_COUNT = 27
WAN_SUCCESSFUL = 71

SEND_MAIL = on

NTP Timeout = 36
NTP Sleep = 4
Ping Domain = 8.8.8.8
---------------------------------------------

Secondary-WAN reported
ping OK, Secondary-WAN, 192.168.0.111, WAN test in 71, Progressive timeout 0
ping OK, Secondary-WAN, 192.168.0.111, WAN test in 62, Progressive timeout 0
ping OK, Secondary-WAN, 192.168.0.111, WAN test in 53, Progressive timeout 0
ping OK, Secondary-WAN, 192.168.0.111, WAN test in 44, Progressive timeout 0
ping OK, Secondary-WAN, 192.168.0.111, WAN test in 35, Progressive timeout 0
ping OK, Secondary-WAN, 192.168.0.111, WAN test in 26, Progressive timeout 0
ping OK, Secondary-WAN, 192.168.0.111, WAN test in 17, Progressive timeout 0
ping OK, Secondary-WAN, 192.168.0.111, WAN test in 8, Progressive timeout 0

WAN type change on Fri, 11 Aug 2017 19:45:18 +0300
WAN type = Secondary-WAN, sending WAN change mail

dual-wan-helper.cfg found and verified, using it as source

% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 0 0 0 0 0 0 0 0 --:--:-- 0:00:01 --:--:-- 0100 433 0 0 100 433 0 175 0:00:02 0:00:02 --:--:-- 181100 433 0 0 100 433 0 175 0:00:02 0:00:02 --:--:-- 181

ping OK, Secondary-WAN, 192.168.0.111, WAN test in 71, Progressive timeout 0
ping OK, Secondary-WAN, 192.168.0.111, WAN test in 62, Progressive timeout 0
ping OK, Secondary-WAN, 192.168.0.111, WAN test in 53, Progressive timeout 0
ping OK, Secondary-WAN, 192.168.0.111, WAN test in 44, Progressive timeout 0
ping OK, Secondary-WAN, 192.168.0.111, WAN test in 35, Progressive timeout 0
ping OK, Secondary-WAN, 192.168.0.111, WAN test in 26, Progressive timeout 0
ping OK, Secondary-WAN, 192.168.0.111, WAN test in 17, Progressive timeout 0
ping OK, Secondary-WAN, 192.168.0.111, WAN test in 8, Progressive timeout 0
No WAN type change to report
ping OK, Secondary-WAN, 192.168.0.111, WAN test in 80, Progressive timeout 9

 

[stylish_me]

19:20 + 99 is more than 19:45...

19.20 + 99*9 = 19.20 + 891 sec = 19.20 + 14 min 51 sec = 19.35

 

[thelonelycoder]

19.20 + 99*9 = 19.20 + 891 sec = 19.20 + 14 min 51 sec = 19.35

I know, just a jest.
WAN types are correct, no doubt about that.
Blame Asus not to switch when it should.

 

[stylish_me]

I know, just a jest.
WAN types are correct, no doubt about that.
Blame Asus not to switch when it should.

I think problem is here:

Settings used for dual-wan-helper 1.0 beta 3

WANDOG_INTERVAL = 9 (real setting 9)
WANDOG_MAXFAIL = 2 (2)
WANDOG_FB_COUNT = 99 (99)

SLEEP_TIMEOUT = 9
PING_COUNT = 27
WAN_SUCCESSFUL = 71

SEND_MAIL = on

NTP Timeout = 36
NTP Sleep = 4
Ping Domain = 8.8.8.8
---------------------------------------------

Secondary-WAN reported
ping OK, Secondary-WAN, 192.168.0.111, WAN test in 71, Progressive timeout 0
ping OK, Secondary-WAN, 192.168.0.111, WAN test in 62, Progressive timeout 0
ping OK, Secondary-WAN, 192.168.0.111, WAN test in 53, Progressive timeout 0
ping OK, Secondary-WAN, 192.168.0.111, WAN test in 44, Progressive timeout 0
ping OK, Secondary-WAN, 192.168.0.111, WAN test in 35, Progressive timeout 0
ping NOK, restarting WAN in 27
Primary-WAN reported
ping: sendto: Network is unreachable
ping NOK, restarting WAN in 18
ping OK, Primary-WAN, 10.13.70.222, WAN test in 71, Progressive timeout 0
ping OK, Primary-WAN, 10.13.70.222, WAN test in 62, Progressive timeout 0
ping OK, Primary-WAN, 10.13.70.222, WAN test in 53, Progressive timeout 0
ping OK, Primary-WAN, 10.13.70.222, WAN test in 44, Progressive timeout 0
ping OK, Primary-WAN, 10.13.70.222, WAN test in 35, Progressive timeout 0
ping OK, Primary-WAN, 10.13.70.222, WAN test in 26, Progressive timeout 0
ping OK, Primary-WAN, 10.13.70.222, WAN test in 17, Progressive timeout 0
ping OK, Primary-WAN, 10.13.70.222, WAN test in 8, Progressive timeout 0


i don't understand why failback timeout is 71 when it should be 99*9 = 891
and it used to be 891 in previous beta

 

[thelonelycoder]

I cap the timeout if it is over 80, else you woud have to wait 99*9 until the WAN type change is sent.
As I said, I do nothing if ping works.
When ping fails, the counter starts for the wan service restart. Should ping be successful again before counter runs out then the counter is reset.

This all is a game between what Asus does and I think ought to be done.
If Asus does not restore WAN in the time set then shortly after I restart wan service.
Depending on what you set this may take longer, I just hope I made the right calculations.
And from extensive testing I believe they are as close to being helpful to WAN as possible.

 

[stylish_me]

It happends like this and WinSCP starts saying that it cannot ping the router for more then 15 sec

ping OK, Primary-WAN, 10.13.70.222, WAN test in 71, Progressive timeout 0
ping OK, Primary-WAN, 10.13.70.222, WAN test in 62, Progressive timeout 0
ping OK, Primary-WAN, 10.13.70.222, WAN test in 53, Progressive timeout 0
ping OK, Primary-WAN, 10.13.70.222, WAN test in 44, Progressive timeout 0
ping OK, Primary-WAN, 10.13.70.222, WAN test in 35, Progressive timeout 0
ping OK, Primary-WAN, 10.13.70.222, WAN test in 26, Progressive timeout 0
ping OK, Primary-WAN, 10.13.70.222, WAN test in 17, Progressive timeout 0
ping OK, Primary-WAN, 10.13.70.222, WAN test in 8, Progressive timeout 0
No WAN type change to report
ping OK, Primary-WAN, 10.13.70.222, WAN test in 80, Progressive timeout 9
ping OK, Primary-WAN, 10.13.70.222, WAN test in 71, Progressive timeout 9
ping OK, Primary-WAN, 10.13.70.222, WAN test in 62, Progressive timeout 9
ping OK, Primary-WAN, 10.13.70.222, WAN test in 53, Progressive timeout 9
ping OK, Primary-WAN, 10.13.70.222, WAN test in 44, Progressive timeout 9
ping OK, Primary-WAN, 10.13.70.222, WAN test in 35, Progressive timeout 9
ping OK, Primary-WAN, 10.13.70.222, WAN test in 26, Progressive timeout 9
ping OK, Primary-WAN, 10.13.70.222, WAN test in 17, Progressive timeout 9
No WAN type change to report
ping OK, Primary-WAN, 10.13.70.222, WAN test in 89, Progressive timeout 18
ping OK, Primary-WAN, 10.13.70.222, WAN test in 80, Progressive timeout 18
ping OK, Primary-WAN, 10.13.70.222, WAN test in 71, Progressive timeout 18
ping OK, Primary-WAN, 10.13.70.222, WAN test in 62, Progressive timeout 18
ping OK, Primary-WAN, 10.13.70.222, WAN test in 53, Progressive timeout 18
ping OK, Primary-WAN, 10.13.70.222, WAN test in 44, Progressive timeout 18
ping OK, Primary-WAN, 10.13.70.222, WAN test in 35, Progressive timeout 18
ping OK, Primary-WAN, 10.13.70.222, WAN test in 26, Progressive timeout 18
No WAN type change to report
ping OK, Primary-WAN, 10.13.70.222, WAN test in 98, Progressive timeout 27
ping OK, Primary-WAN, 10.13.70.222, WAN test in 89, Progressive timeout 27

 

[stylish_me]

And from extensive testing I believe they are as close to being helpful to WAN as possible.

For now it took more then 33 minutes to switch back from secondary to primary. It is ok for me. Need to test it again to be sure that it was not faulty asus that didn't switch back - but it was the timeout set in the script. Because it switched back only in verbose mode. May be because i manually called the script or may be because timeout turned to be smth like 33 minutes.
Anyway i feel that there is a bud that doubles the timeout..

 

[thelonelycoder]

It happends like this and WinSCP starts saying that it cannot ping the router for more then 15 sec

ping OK, Primary-WAN, 10.13.70.222, WAN test in 71, Progressive timeout 0
ping OK, Primary-WAN, 10.13.70.222, WAN test in 62, Progressive timeout 0
ping OK, Primary-WAN, 10.13.70.222, WAN test in 53, Progressive timeout 0
ping OK, Primary-WAN, 10.13.70.222, WAN test in 44, Progressive timeout 0
ping OK, Primary-WAN, 10.13.70.222, WAN test in 35, Progressive timeout 0
ping OK, Primary-WAN, 10.13.70.222, WAN test in 26, Progressive timeout 0
ping OK, Primary-WAN, 10.13.70.222, WAN test in 17, Progressive timeout 0
ping OK, Primary-WAN, 10.13.70.222, WAN test in 8, Progressive timeout 0
No WAN type change to report
ping OK, Primary-WAN, 10.13.70.222, WAN test in 80, Progressive timeout 9
ping OK, Primary-WAN, 10.13.70.222, WAN test in 71, Progressive timeout 9
ping OK, Primary-WAN, 10.13.70.222, WAN test in 62, Progressive timeout 9
ping OK, Primary-WAN, 10.13.70.222, WAN test in 53, Progressive timeout 9
ping OK, Primary-WAN, 10.13.70.222, WAN test in 44, Progressive timeout 9
ping OK, Primary-WAN, 10.13.70.222, WAN test in 35, Progressive timeout 9
ping OK, Primary-WAN, 10.13.70.222, WAN test in 26, Progressive timeout 9
ping OK, Primary-WAN, 10.13.70.222, WAN test in 17, Progressive timeout 9
No WAN type change to report
ping OK, Primary-WAN, 10.13.70.222, WAN test in 89, Progressive timeout 18
ping OK, Primary-WAN, 10.13.70.222, WAN test in 80, Progressive timeout 18
ping OK, Primary-WAN, 10.13.70.222, WAN test in 71, Progressive timeout 18
ping OK, Primary-WAN, 10.13.70.222, WAN test in 62, Progressive timeout 18
ping OK, Primary-WAN, 10.13.70.222, WAN test in 53, Progressive timeout 18
ping OK, Primary-WAN, 10.13.70.222, WAN test in 44, Progressive timeout 18
ping OK, Primary-WAN, 10.13.70.222, WAN test in 35, Progressive timeout 18
ping OK, Primary-WAN, 10.13.70.222, WAN test in 26, Progressive timeout 18
No WAN type change to report
ping OK, Primary-WAN, 10.13.70.222, WAN test in 98, Progressive timeout 27
ping OK, Primary-WAN, 10.13.70.222, WAN test in 89, Progressive timeout 27

This all looks perfect to me, Primary WAN has been reported and subsequent pings are successful.
Since there is no WAN type change, there is nothing to report.

 

[stylish_me]

This all looks perfect to me,

Ok i'll check once more how many minutes will it take to failback from secondary to primary.
It should be 99*9 = almost 15 minutes if i am not mistaken..

 

[thelonelycoder]

Basically, the script pings the set domain.
- if nvram reports a WAN type change progressive timout is reset as well as WAN test and ping timeout, a new cycle starts
- if ping fails the same as above happens and the restart counter starts counting
- when ping succeeds, all counters are reset and a new cycle begins
- if the WAN type has changed since last full cycle then the email is sent, if not then "No WAN type change to report" is all you see.

 

[stylish_me]

Basically, the script pings the set domain.

I still don't understand one thing. If wan test time is 71 and it repeats cycles - so where is the counter for that failback timeout 99*9?
As far as i see it can repeat these cycles forever - but we need to repeat them untill 99*9 timeout runs out. I am sure that you programmed everything right - but i still don't see that failback timeout..
Before i saw 891...882...873...864 and so on.

 

[stylish_me]

Hmm now it made failback within 17 minutes. Really interesting lol
But where did it take that final number?

ping OK, Secondary-WAN, 192.168.0.111, WAN test in 71, Progressive timeout 36
Primary-WAN reported

 

[thelonelycoder]

I still don't understand one thing. If wan test time is 71 and it repeats cycles - so where is the counter for that failback timeout 99*9?
As far as i see it can repeat these cycles forever - but we need to repeat them untill 99*9 timeout runs out. I am sure that you programmed everything right - but i still don't see that failback timeout..
Before i saw 891...882...873...864 and so on.

This is the timeout when ping fails: Detect Interval * Failover Execution Time + Detect Interval
PING_COUNT=$(($WANDOG_INTERVAL * $WANDOG_MAXFAIL + $WANDOG_INTERVAL))
If this is over 80, then PING_COUNT=80 + Detect Interval

This is the cycle counter: Detect Interval * Failback Execution Time - Detect Interval
WAN_SUCCESSFUL=$(($WANDOG_INTERVAL * $WANDOG_FB_COUNT - $WANDOG_INTERVAL))
If this is over 80, then WAN_SUCCESSFUL=80 - Detect Interval --> your 71
The 99*9 Asus timeout is not of interest to me as long as ping works.

 

[stylish_me]

The 99*9 Asus timeout is not of interest to me as long as ping works.

Well i feel how dumb i sound at this moment but this is smth out of my understanding
I understand that you used some walkaround not to get email notification after 9*99 timeout. That's clear.
But i don't understand why you are not using 99*9 as a separate failback timeout. Just tell me that your script calculates smth close to 99*9 and i will be happy. Because as far as i understand - router needs to switch back to primary every XXX seconds to make ping. And stay on primary if ping is ok or switch back to secondary for XXX seconds if ping is not ok. So i hope you are trying to tell me that XXX is calculated by your script and XXX is somewhere close to 99*9 sec.
As for failover time i hope it is somewhere near 2*9 sec lol

 

[stylish_me]

No smth is still wrong.
I rebooted router after all those tests in verbose mode, now router shows that it is on primary wan, but script gives me this right after reboot
Aug 11 21:02:14 crond[301]: time disparity of 1068121 minutes detected
Aug 11 21:02:39 admin: dual-wan-helper: WAN type change detected, WAN type = Secondary-WAN, via /jffs/scripts/dual-wan-helper
Aug 11 21:02:42 admin: dual-wan-helper: WAN type change detected, notification sent to avoronkov@gmail.com via /jffs/scripts/dual-wan-helper
And it sends old ip's and so on.

Made second reboot - but still same old info about secondary wan althhough it is on primary for sure.

 

[thelonelycoder]

Well i feel how dumb i sound at this moment but this is smth out of my understanding
I understand that you used some walkaround not to get email notification after 9*99 timeout. That's clear.
But i don't understand why you are not using 99*9 as a separate failback timeout. Just tell me that your script calculates smth close to 99*9 and i will be happy. Because as far as i understand - router needs to switch back to primary every XXX seconds to make ping. And stay on primary if ping is ok or switch back to secondary for XXX seconds if ping is not ok. So i hope you are trying to tell me that XXX is calculated by your script and XXX is somewhere close to 99*9 sec.
As for failover time i hope it is somewhere near 2*9 sec lol

That makes sense to add an overall counter, let me go find my keyboard, it's gone dusty since I last used it...

 

[stylish_me]

Now it sends secondary wan notification every time i reboot it. But works on pimary wan. Hmmm

 

[thelonelycoder]

Now it sends secondary wan notification every time i reboot it. But works on pimary wan. Hmmm

Check syslog what it says before the email is sent.
wan0 or wan1?

 

[stylish_me]

Check syslog what it says before the email is sent.
wan0 or wan1?

I don't see anything about wan before this (neither does ctrl+F):
many attempts:
Aug 1 03:00:11 admin: dual-wan-helper: NTP not ready, cycle 0 of 36 via /jffs/scripts/dual-wan-helper

and then:
Aug 11 21:09:16 admin: dual-wan-helper: WAN type change detected, WAN type = Secondary-WAN, via /jffs/scripts/dual-wan-helper
Aug 11 21:09:19 admin: dual-wan-helper: WAN type change detected, notification sent to avoronkov@gmail.com via /jffs/scripts/dual-wan-helper

But router is 10000% on primary.