Test WebGUI Support in AP Mode.

[Martinski4GitHub]

Just made a tweak to test/validate WebGUI support when router is in AP Mode.

[Martinski4GitHub]

@ExtremeFiretop.

This PR is just a simple change to test & validate the WebGUI when the router is in AP mode.
I believe it should work fine, but perhaps it might need a couple more tweaks.

P.S.
We can ask users to test this in their APs (if they have them).

[ExtremeFiretop]

Did you get the value of 3 from your AP?
I don't have any routers in AP mode to test but we can merge this in and ask the user to test asap.

It's a small change and logically it should be fine as long as that value is standard

[Martinski4GitHub]

Did you get the value of 3 from your AP? I don't have any routers in AP mode to test but we can merge this in and ask the user to test asap.

It's a small change and logically it should be fine as long as that value is standard

I don't have any APs in my home network, but my parents have their old RT-AC68U in AP mode, and that's where I got the value from. AFAIK, the NVRAM value should be standard in all AC- and AX-class routers, but I don't know about the BE routers. It's likely OK, but it needs to be verified.

[ExtremeFiretop]

Did you get the value of 3 from your AP? I don't have any routers in AP mode to test but we can merge this in and ask the user to test asap.
It's a small change and logically it should be fine as long as that value is standard

I don't have any APs in my home network, but my parents have their old RT-AC68U in AP mode, and that's where I got the value from. AFAIK, the NVRAM value should be standard in all AC- and AX-class routers, but I don't know about the BE routers. It's likely OK, but it needs to be verified.

That's good for me my friend, merged it in.
Did you want me to make the post or you, explaining to test to validate the functionality?

Basically none of us can really test or validate but it should work. I am trying to identify anything that wouldn't work if it was an AP with the script in router mode.

My only concern would maybe be what the AiMesh nodes info menu would try to do for the primary router? But if I remember correctly we also factored in logic to ignore the primary router. Or maybe that was to ignore its own address. I'm not sure as I don't remember anymore. It's been a while.

Will need to be tested

[Martinski4GitHub]

Did you get the value of 3 from your AP? I don't have any routers in AP mode to test but we can merge this in and ask the user to test asap.
It's a small change and logically it should be fine as long as that value is standard

I don't have any APs in my home network, but my parents have their old RT-AC68U in AP mode, and that's where I got the value from. AFAIK, the NVRAM value should be standard in all AC- and AX-class routers, but I don't know about the BE routers. It's likely OK, but it needs to be verified.

That's good for me my friend, merged it in. Did you want me to make the post or you, explaining to test to validate the functionality?

I just made a post to the user and asked them to test this latest change.

Basically none of us can really test or validate but it should work. I am trying to identify anything that wouldn't work if it was an AP with the script in router mode.

My only concern would maybe be what the AiMesh nodes info menu would try to do for the primary router? But if I remember correctly we also factored in logic to ignore the primary router. Or maybe that was to ignore its own address. I'm not sure.

Will need to be tested

Yes, absolutely, more testing will be needed with AiMesh nodes. I think a handful of little tweaks might be needed to make sure APs work well, but no major changes.

[ExtremeFiretop]

Did you get the value of 3 from your AP? I don't have any routers in AP mode to test but we can merge this in and ask the user to test asap.
It's a small change and logically it should be fine as long as that value is standard

I don't have any APs in my home network, but my parents have their old RT-AC68U in AP mode, and that's where I got the value from. AFAIK, the NVRAM value should be standard in all AC- and AX-class routers, but I don't know about the BE routers. It's likely OK, but it needs to be verified.

That's good for me my friend, merged it in. Did you want me to make the post or you, explaining to test to validate the functionality?

I just made a post to the user and asked them to test this latest change.

Basically none of us can really test or validate but it should work. I am trying to identify anything that wouldn't work if it was an AP with the script in router mode.
My only concern would maybe be what the AiMesh nodes info menu would try to do for the primary router? But if I remember correctly we also factored in logic to ignore the primary router. Or maybe that was to ignore its own address. I'm not sure.
Will need to be tested

Yes, absolutely, more testing will be needed with AiMesh nodes. I think a handful of little tweaks might be needed to make sure APs work well, but no major changes.

I'll review the code when i'm up tomorrow since I have the day off. (Last paid personal day of the fiscal year so I may as well use it, they don't bank between years)

Currently in bed, my car is having power steering issues so I have an appointment with the dealership tomorrow to check it out. Under warranty but I'm just hoping it doesn't take too long.

My only thought is i don't want the AP trying to login to the WebUI and get info from the primary router.
But I think we factored that in when we originally designed the solution. I'll have to validate... Even if it's not factored in now we can probably work around it like you said with minimal tweaks

[Martinski4GitHub]

Did you get the value of 3 from your AP? I don't have any routers in AP mode to test but we can merge this in and ask the user to test asap.
It's a small change and logically it should be fine as long as that value is standard

I don't have any APs in my home network, but my parents have their old RT-AC68U in AP mode, and that's where I got the value from. AFAIK, the NVRAM value should be standard in all AC- and AX-class routers, but I don't know about the BE routers. It's likely OK, but it needs to be verified.

That's good for me my friend, merged it in. Did you want me to make the post or you, explaining to test to validate the functionality?

I just made a post to the user and asked them to test this latest change.

Basically none of us can really test or validate but it should work. I am trying to identify anything that wouldn't work if it was an AP with the script in router mode.
My only concern would maybe be what the AiMesh nodes info menu would try to do for the primary router? But if I remember correctly we also factored in logic to ignore the primary router. Or maybe that was to ignore its own address. I'm not sure.
Will need to be tested

Yes, absolutely, more testing will be needed with AiMesh nodes. I think a handful of little tweaks might be needed to make sure APs work well, but no major changes.

I'll review the code when i'm up tomorrow since I have the day off. (Last paid personal day of the fiscal year so I may as well use it, they don't bank between years)

This coming weekend, I can set my RT-AC86U in AP mode for testing purposes to see if it works well with the script and the WebGUI page. I don't have time during the work week to do that.

Currently in bed, my car is having power steering issues so I have an appointment with the dealership tomorrow to check it out. Under warranty but I'm just hoping it doesn't take too long.

Good luck with your car. I hope it's only a minor repair.

My only thought is i don't want the AP trying to login to the WebUI and get info from the primary router. But I think we factored that in when we originally designed the solution. I'll have to validate... Even if it's not factored in now we can probably work around it like you said with minimal tweaks

Yes, all good points.

[Martinski4GitHub]

@ExtremeFiretop>

"Also if you could please report back if the "AiMesh Node(s) Info" menu option works as designed from the AP."

Does the above mean that you can have AiMesh nodes associated with an AP?
I've never set up an AiMesh node, so I have no idea what's possible.

[ExtremeFiretop]

@ExtremeFiretop>

"Also if you could've please report back if the "AiMesh Node(s) Info" menu option works as designed from the AP."

Does the above mean that you can have AiMesh nodes associated with an AP? I've never set up an AiMesh node, so I have no idea what's possible.

I'm not exactly sure how it will work until I review the code.
But yes and no, AiMesh can connect to any other node. It doesn't have to directly connect to the primary router. AiMesh can daisy chain.

Now, how that works with an AP in the mix I'm not sure. What I do know is that the menu will become available to him because of this change on his AP. That menu by design is supposed to login to every node, regardless of which it's paired too, and grab the version information.

I'm expecting that means the AP will start to do that, as well as the primary, and potentially cause a conflict, if say, they were scheduled at the same time.

Also the primary router shouldn't get logged into at all by nodes since the primary router is always expected to have MerlinAU installed by design to grab the node information regardless of if it's installed on the nodes. (And we don't want to have users unable to login to due checks done by the nodes. The more nodes the longer that WebUi would be unavailable)

[ExtremeFiretop]

I guess my concern stems from the fact that the logic was originally designed with this in mind:

1. Master router with a Master copy of MerlinAU
2. Child nodes with child versions of MerlinAU, stripped down missing the functionality of the node checks and the WebUI, etc.

But with this change, we can essentially have 2 "Master" versions of MerlinAU on the network, both installed on the primary router and AP, and I don't want those features and logic to clash

[Martinski4GitHub]

I guess my concern stems from the fact that the logic was originally designed with this in mind:

1. Master router with a Master copy of MerlinAU

2. Child nodes with child versions of MerlinAU, stripped down missing the functionality of the node checks and the WebUI, etc.

But with this change, we can essentially have 2 "Master" versions of MerlinAU on the network, both installed on the primary router and AP, and I don't want those features and logic to clash

Ah, yes, I understand your concern.

[Martinski4GitHub]

I guess my concern stems from the fact that the logic was originally designed with this in mind:

1. Master router with a Master copy of MerlinAU

2. Child nodes with child versions of MerlinAU, stripped down missing the functionality of the node checks and the WebUI, etc.

But with this change, we can essentially have 2 "Master" versions of MerlinAU on the network, both installed on the primary router and AP, and I don't want those features and logic to clash

To begin to address your concerns, I just submitted PR #426, which includes changes so that if necessary, we can selectively handle certain features or functionalities (e.g. AiMesh nodes) based on whether the router is operating in "Router Mode" or in "AP Mode." This will make more sense as you review the PR changes.