scMerlin scMerlin 2.5.41 - Service and script control menu for Asuswrt-Merlin

[Tarek Yag]

I also get this though on the development version when I failover, whereas I would have expected a low number for WAN1, as in counting from when it "took over"?

Logically you're talking totally right. But as I myself understood from lots of reading in this forum, the Asus Dual WAN feature is so unreliable and full of bugs, and that's why there's Ranger's script WAN Failover.
So, I guess this issue has nothing to do with scMerlin or AMTM in general.

Probably just display issues as you say?

So, no! Probably stock firmware issues as I just explained.

No doubt @ExtremeFiretop will chime in and clarify all this and tell me what an idiot I am...

LOL! Don't say that.
I'm waiting for @ExtremeFiretop's reply to assure my understandings too.

 

[ExtremeFiretop]

@Stephen Harrington

Sorry for the delay, I've been mentally tired recently after work and passed out early last night.
There was a few things cleaned up last night can I have you re-test and advise? Make sure do download the latest develop version

Thank you!

 

[ExtremeFiretop]

I also get this though on the development version when I failover, whereas I would have expected a low number for WAN1, as in counting from when it "took over"?
Probably just display issues as you say?

View attachment 67798

View attachment 67799

No doubt @ExtremeFiretop will chime in and clarify all this and tell me what an idiot I am...

@Stephen Harrington
To be specific, this is what I'd like you to re-test and advise about found above

 

[Stephen Harrington]

There was a few things cleaned up last night can I have you re-test and advise? Make sure do download the latest develop version

Ok, @ExtremeFiretop, I did a "uf" force update and re-tested ...

Starting state:

After Failover (and waiting a bit):

After Fallback (and waiting a bit):

So it looks like this version happily "re-starts the clock" on WAN0 but the same thing does not appear to be happening on WAN1 ... it just continues the cumulative time as per what was already the count for WAN0?

Is that what I'm meant to be seeing?

If on the Failover the time on WAN1 likewise started from zero that would be a useful compromise I guess?
Would let you know how long you'd been on backup WAN etc ...

Not sure what you have in mind though.

 

[ExtremeFiretop]

Ok, @ExtremeFiretop, I did a "uf" force update and re-tested ...

Starting state:

View attachment 67821

After Failover (and waiting a bit):

View attachment 67822

After Fallback (and waiting a bit):

View attachment 67823

So it looks like this version happily "re-starts the clock" on WAN0 but the same thing does not appear to be happening on WAN1 ... it just continues the cumulative time as per what was already the count for WAN0?

Is that what I'm meant to be seeing?

If on the Failover the time on WAN1 likewise started from zero that would be a useful compromise I guess?
Would let you know how long you'd been on backup WAN etc ...

Not sure what you have in mind though.

No not what I had in mind it should reset everytime for both interfaces as they become the "active" interface...

Let me dive a little deeper and I'll PM you if I need any additional information.
I just wanted to see how it was functioning now after the last tweaks.

I hope to have progress soon, don't go too far!

 

[Stephen Harrington]

I hope to have progress soon, don't go too far!

Looks like you are halfway there then ... out running errands for next couple of hours but I'll check in here after that and respond.
I'm GMT+10 Sydney Australia timezone.

 

[Tarek Yag]

Good luck for both of you, get it perfect this time!
If you need any feedback from a load-balance user just DM me.

 

[Ranger802004]

Not sure if I'm misunderstanding (as usual) where you have gotten to in development @ExtremeFiretop as I've not had my eye on this thread for a week or so but I just tried latest development version and after a reboot etc get no uptime showing for my WAN1, even though it is very much alive

RT-AX86U, running in Dual WAN Failover, WAN1 is a 5G device plugged in via ethernet (not USB) on LAN Port 4. Details as per my signature.

View attachment 67797

All showing "alive" in @Ranger802004 wan-failover script status ...

Let me know if you want anything tested?

Hot-Standby means the connection is in an active state and traffic can be passed through it if you routed it that way with scripting or Domain VPN Routing. My WAN Failover script is what forces it in this state whereas without the firmware does not do this unless the traditional failover mechanism is failing over to it. @Stephen Harrington is leading you down the correct path here in this thread. You need to get WAN1 in the correct state in order for it to show the proper status.

 

[ExtremeFiretop]

Hot-Standby means the connection is in an active state and traffic can be passed through it if you routed it that way with scripting or Domain VPN Routing. My WAN Failover script is what forces it in this state whereas without the firmware does not do this unless the traditional failover mechanism is failing over to it. @Stephen Harrington is leading you down the correct path here in this thread. You need to get WAN1 in the correct state in order for it to show the proper status.

Hey @Ranger802004 thanks for the comment and confirmation. We actually solved this yesterday for @Stephen Harrington in the DMs.

Just waiting to pump out a new release. The issue seemed related to your script initially, or at least related to the setup your script requires with "Allow Failback" to be disabled in the Dual-WAN settings, since in my instance with the stock failback, it worked without issue, but we managed to work around it.

Otherwise I may have poked you for more info but it wasn't required in the end.

Appreciate the confirmation though!

 

[Ranger802004]

Hey @Ranger802004 thanks for the comment and confirmation. We actually solved this yesterday for @Stephen Harrington in the DMs.

Just waiting to pump out a new release. The issue seemed related to your script initially, or at least related to the setup your script requires with "Allow Failback" to be disabled in the Dual-WAN settings, since in my instance with the stock failback, it worked without issue, but we managed to work around it.

Otherwise I may have poked you for more info but it wasn't required in the end.

Appreciate the confirmation though!

Just contributing my 2 cents since I got tagged and the resolution wasn't spelled out in the comments here. If any updates to WAN Failover need to be made as part of integrations with other tools feel free to reach out.

 

[ExtremeFiretop]

Just contributing my 2 cents since I got tagged and the resolution wasn't spelled out in the comments here. If any updates to WAN Failover need to be made as part of integrations with other tools feel free to reach out.

Oh absolutely if we ever need anything we won't be shy! I just wanted you to know it was actually nailed down.

The only question I had remaining was "why" we weren't getting a WAN1 Connected event through the wan-event script but the "why" doesn't matter much once we know that was the cause of his issues.

 

[Tarek Yag]

I see great team work, thanks everybody!
@ExtremeFiretop, did any of the recent changes involve any modifications to balance-mode uptime monitoring algorithm?

 

[ExtremeFiretop]

I see great team work, thanks everybody!
@ExtremeFiretop, did any of the recent changes invole any modifications to the balance mode connection detection algorithms?

No changes should be expected, however if you would like to test to revalidate that I would not be against it (as I've only been testing in fail over mode recently.)
You just simply need to run:

sh /jffs/scripts/scmerlin develop

sh /jffs/scripts/scmerlin forceupdate

 

[ExtremeFiretop]

If any updates to WAN Failover need to be made as part of integrations with other tools feel free to reach out.

@Ranger802004 I actually do have a question for you considering you made the comment to cooperate.
I am currently investigating an issue with @Tarek Yag which in short seems related to the nvram values of wan1_state_t and wan0_state_t not flipping as expected on his Dual-WAN setup with Load-Balancing.

Can you explain your current understanding between wan(x)_state_t and wan(x)_auxstate_t which I see is the nvram you seem to use in your script.

1. Why use wan1_auxstate_t over wan1_state_t? is it more reliable than wan1_state_t?
2. Most importantly, does this value update as expected under all setups? (i.e not using Dual-WAN?)
3. Do these nvram values have different behavior in any sense to determine "connected" status?

I'm currently doing some testing with this nvram value, but would like your feedback or understanding considering you have been playing in the DUAL-WAN environment longer than myself, and don't want to have a conflicting understanding/logic.

For regular "WAN is connected" checks we do:

        if [ "$(nvram get "wan${iFaceNum}_primary")" = "1" ] && \
           [ "$(nvram get "wan${iFaceNum}_state_t")" = "2" ]

However it seems that wan(x)_state_t maybe too unreliable for a DUAL-WAN setup...
(At least with Load Balancing, Fail-over seems to work okay for me and @Stephen Harrington )

 

[Ranger802004]

@Ranger802004 I actually do have a question for you considering you made the comment to cooperate.
I am currently investigating an issue with @Tarek Yag which in short seems related to the nvram values of wan1_state_t and wan0_state_t not flipping as expected on his Dual-WAN setup with Load-Balancing.

Can you explain your current understanding between wan(x)_state_t and wan(x)_auxstate_t which I see is the nvram you seem to use in your script.

1. Why use wan1_auxstate_t over wan1_state_t? is it more reliable than wan1_state_t?
2. Most importantly, does this value update as expected under all setups? (i.e not using Dual-WAN?)
3. Do these nvram values have different behavior in any sense to determine "connected" status?

I'm currently doing some testing with this nvram value, but would like your feedback or understanding considering you have been playing in the DUAL-WAN environment longer than myself, and don't want to have a conflicting understanding/logic.

For regular "WAN is connected" checks we do:

        if [ "$(nvram get "wan${iFaceNum}_primary")" = "1" ] && \
           [ "$(nvram get "wan${iFaceNum}_state_t")" = "2" ]

However it seems that wan(x)_state_t maybe too unreliable for a DUAL-WAN setup...
(At least with Load Balancing, Fail-over seems to work okay for me and @Stephen Harrington )

Aux state is the physical interface state as if it is unplugged, etc. The other is the actual connection state, both are necessary for true monitoring in a combination. He has an open issue on GitHub with me to back fill support for the older router to work with the binary versions it has. I already made this change in Domain VPN Routing but WAN Failover is going to be in progress soon for this update.

 

[Tarek Yag]

Aux state is the physical interface state as if it is unplugged, etc. The other is the actual connection state, both are necessary for true monitoring in a combination.

I'm very grateful for your public explanation of this. You just hit the core issue that I'm facing with RT-AC68U firmware's Dual WAN feature as it's messing the wan*_state_t making it connected whlie the cable is not plugged in, this is exactly what we've been investigating for the uptime feature in scMerlin to work well with load-balance mode.

[EDIT] I also noticed that link_wan and link_wan1 variables switch states accordingly too. Would it add any benefit if we use these two variables for true monitoring of the connection state? Or are the other variables completely enough?

He has an open issue on GitHub with me to back fill support for the older router to work with the binary versions it has. I already made this change in Domain VPN Routing but WAN Failover is going to be in progress soon for this update.

Very grateful again, and I'm still eagerly awaiting any updates on the matter, even though I'll no longer need the load-balance mode anymore, but I will be using Failover/Failback mode very soon, and willing for sure to use your WAN Failover script whenever you're done with the needed changes.