Improvements to support APs#426
Conversation
Improvements to support APs Made changes so that we can handle specific functionality or features based on whether the router is in "Router Mode" (i.e. Primary router) or in "AP Mode." This allows us to determine whether the WebGUI should be mounted or whether the AiMesh nodes should be handled only by the Primary router.
Improvements to detect AP Mode.
|
I'm good with this. the only part that confuses me is his lastest report just an hour ago says it still had the issues: https://www.snbforums.com/threads/merlinau-v1-3-10-the-ultimate-firmware-auto-updater-gnuton-support.91326/post-948454 |
|
Do you get any returned values on the AP for nvram get asus_device_list? |
|
My guess is hes having issues with the Mount_WebUI function on the AP? I'm only guessing because I don't have a screenshot of the issue or any logs. |
This user has not provided enough data and context to understand the problem he's seeing. I don't know if it's just laziness, carelessness, or simple ignorance, but he refuses to attach screenshots of the update process, which you have already requested him to provide. This is not rocket science level stuff to do. Taking clear and readable screenshots is more like an arithmetic level of difficulty. Also, his reply to my request to test & validate the PR change was this:
No logs, no screenshots, no context!! What does he expect us to do with that response??? BTW, I asked my friend from work if he had any APs on his network where he could test the latest MerlinAU 1.4.0 version (including my latest PR), and he said he had a spare router he could set up as an AP for testing purposes. Well, this evening he reported that he had tested it briefly, but so far the WebGUI page was working well on his AP. Here's a screenshot.
|
I don't have any APs in my home network, and the only APs I have direct access to are the 10-year-old RT-AC68Us, which are not supported by MerlinAU so I cannot test anything on those models. |
As mentioned, without any relevant info & context, you're just shooting in the dark while blindfolded. |
That's being generous! I said as much in my reply to the user. Asking for screenshots twice. |
|
I also just realized he completely did not address my request to test the AiMesh nodes options menu in his reply lol! |
Yeah, I know you've asked and tried, but for some reason, he's refusing.
I'm about to send a reply with the screenshot. |
Yeah maybe showing it's working for someone else might give him the kick needed to provide some logs or screenshots cause just guessing I can only assume what flow he is taking and the script is taking. |
No worries, basically reviewing the code today and following some logic I realized that menu option won't display if that value is not populated, now I know on an AIMesh node it does get populated, and I would guess it's the same for an AP. But if it's not that would automatically limit the AiMesh functionality. |
Yeah, asking this user for something is like pulling teeth... |
This weekend, when I set up my RT-AC86U as an AP, I will check those NVRAM values, but since I don't have any AiMesh nodes in my network, I wonder if the values will be meaningful. |
Well it will be meaningful in 2 ways (to me anyways)
Actually that's something I forgot to review today. Maybe I can still quickly check that part of the code. |
OK, I got it. So I don't need to have actual AiMesh nodes for the NVRAM value to possibly contain the primary router. If it does, it may cause issues between the AP & the primary router; if it does not, we're good to go. Either way, I assume that setting the variable to false for the AP should take care of any issues? I guess we'll need to find out and verify. |
Exactly. I just want an answer to this. I expect we will want to set this to false if it works exactly the same as the AiMesh Nodes with how it populates these values.
Exactly. I was hoping the user would help clarify some of these values and functions but seems I'll have to wait hahah |
|
User replied and is still ignoring my requests. |
|
This evening, my friend asked me if there was anything else I wanted to check before he took down the ASUS AP, so I asked him to check 2 things. Below are the results.
So it seems that your theory is correct: from MerlinAU's viewpoint, the AP would look and act like another "primary" router WRT AiMesh Nodes. P.S. |
I agree. Based on my friend's feedback from his AP, I think it would be best to set it to false. |
Let's send it! I replied to the user in the forums but I think I need a break to step away for a bit haha |
|
P.S tell your friend we appreciate the testing to confirm the theory that MerlinAU is running in "primary router" mode on the AP. Was one of those technicalities I couldn't verify since I didn't know if the nvram values populated the same. |
DONE. |
Yes, exactly. There should be only one router acting as the "primary."
I hear you!!! |
Will do for sure. |
2 participants
Made changes so that we can handle specific functionality or features based on whether the router is operating in "Router Mode" (i.e. Primary router) or in "AP Mode." This allows us to determine whether the WebGUI should be mounted or whether the AiMesh nodes should be handled only by the Primary router.
Added WebUI Tab URL info to the CLI "About" page.