Fix ROG and TUG Build Type Selection from WebUI

[ExtremeFiretop]

@Martinski4GitHub

Sorry for the delay buddy, been busy with work and personal life things, I totally just realized I never even messaged you the crazy story I wanted to tell you. I'll do that shortly! I hope everything is going well with you! Did you manage to get everything setup at home now with the new hardware?

Anyways, this PR is to fix the ROG and TUF build type selection; small bug really.
The key names were wrong (compared to what the script is expecting) and same with the values. Instead of outputting "ROG" or "Pure" it should be outputting "ENABLED" or "DISABLED" since the new Migrate_Settings function changes the values.

That's more or less the end of my testing with the ROG and TUF builds, the only thing I noticed remaining with these tests is that the WebUI did not display the Build options unless I first selected one in the script.

So for example, a fresh install of the script would have the build values as "TBD" or missing from the file completely. In such an instance the WebUI does not detect or display the build options, it seems to be related to this line in the .asp file:

if (!isTUFModel || !hasTUFWBuildType)
or
if (!isROGModel || !hasROGFWBuildType)

Which is requiring the build type to already be in the file.
I could of course remove the requirement for !hasROGFWBuildType or !hasTUFWBuildType; however, just because the model is a GT or a TUF model does not mean it will have TUF or ROG builds (i.e RMerlin has dropped support for ROG builds on GT models on 3006 firmware)

So this I believe is why I made it dependent on there being a value already inside. (So it was determined by the script) Now this isn't a real problem because likely setting the build type would be done right away post install, even if it wasn't on and the user forgot to set it; the script on first flash would populate the settings file with a default built type, and then it would show on the WebUI.

But maybe best we look into a way to detect and populate that file as soon as the script is loaded. Similar to backupmon with this code:

currentBackupOption="$(Get_Custom_Setting "FW_Auto_Backupmon")"
if [ -f "/jffs/scripts/backupmon.sh" ]
then
    # If setting is empty, add it to the configuration file #
    if [ "$currentBackupOption" = "TBD" ]
    then
        Update_Custom_Settings FW_Auto_Backupmon "ENABLED"
    fi
else
    # If the configuration setting exists, delete it #
    if [ "$currentBackupOption" != "TBD" ]
    then
        Delete_Custom_Settings "FW_Auto_Backupmon"
    fi
fi

Thoughts or opinions bud?

[ExtremeFiretop]

Things remaining to test:

1. Changelog approval functionality.
2. Updating from 1.3.10 to 1.4.0 version.

[Martinski4GitHub]

@Martinski4GitHub

Sorry for the delay buddy, been busy with work and personal life things, I totally just realized I never even messaged you the crazy story I wanted to tell you. I'll do that shortly! I hope everything is going well with you!

No worries, bud; I completely understand. I've been very busy myself since the workload picked up significantly in February with a deadline for our next update release on April 11th. So the long work days have begun, and I need to rest & unwind by the time I get home.

Did you manage to get everything setup at home now with the new hardware?

Yeah, I finally set up the RT-AX86U_PRO as the main home router, and the RT-AC86U is in my home office as a secondary router (i.e. double NAT). This allows me to use the old router for development and testing purposes while providing a very good WiFi signal to the back patio and the backyard all the way to the back fence. It's been working well - so far no complaints.

Anyways, this PR is to fix the ROG and TUF build type selection; small bug really. The key names were wrong (compared to what the script is expecting) and same with the values. Instead of outputting "ROG" or "Pure" it should be outputting "ENABLED" or "DISABLED" since the new Migrate_Settings function changes the values.

That's more or less the end of my testing with the ROG and TUF builds, the only thing I noticed remaining with these tests is that the WebUI did not display the Build options unless I first selected one in the script.

So for example, a fresh install of the script would have the build values as "TBD" or missing from the file completely. In such an instance the WebUI does not detect or display the build options, it seems to be related to this line in the .asp file:

if (!isTUFModel || !hasTUFWBuildType) or if (!isROGModel || !hasROGFWBuildType)

Which is requiring the build type to already be in the file. I could of course remove the requirement for !hasROGFWBuildType or !hasTUFWBuildType; however, just because the model is a GT or a TUF model does not mean it will have TUF or ROG builds (i.e RMerlin has dropped support for ROG builds on GT models on 3006 firmware)

So this I believe is why I made it dependent on there being a value already inside. (So it was determined by the script) Now this isn't a real problem because likely setting the build type would be done right away post install, even if it wasn't on and the user forgot to set it; the script on first flash would populate the settings file with a default built type, and then it would show on the WebUI.

Upon a fresh installation of the script, I've always assumed that there's a way to know whether the current F/W build type is "ROG" or "TUF" or the "Standard" Merlin. I don't have a way to test & verify this, but I'm assuming that there's some NVRAM value that has this information, is this assumption correct?

If I'm incorrect and there's no such a built-in indication of the currently installed F/W build type, and the only way to know with certainty is via the F/W image binary file that contains the "ROG" or "TUF" tags (like the "Gnuton" builds) then it makes it more challenging to initialize the corresponding configuration setting appropriately.

But maybe best we look into a way to detect and populate that file as soon as the script is loaded. Similar to backupmon with this code:

currentBackupOption="$(Get_Custom_Setting "FW_Auto_Backupmon")"
if [ -f "/jffs/scripts/backupmon.sh" ]
then
    # If setting is empty, add it to the configuration file #
    if [ "$currentBackupOption" = "TBD" ]
    then
        Update_Custom_Settings FW_Auto_Backupmon "ENABLED"
    fi
else
    # If the configuration setting exists, delete it #
    if [ "$currentBackupOption" != "TBD" ]
    then
        Delete_Custom_Settings "FW_Auto_Backupmon"
    fi
fi

Thoughts or opinions bud?

Unfortunately, since I don't have a router with a "ROG" or "TUF" build type, I can't really be of much help trying to understand what the current behavior is to figure out the best solution.

[Martinski4GitHub]

Things remaining to test:

1. Changelog approval functionality.

2. Updating from 1.3.10 to 1.4.0 version.

Yeah, I have bullet point 2 in my to-do list as well. I think after those tests are done and completed to our satisfaction, we can issue the 1.3.10 production release, and then perhaps a couple of weeks later (to allow everyone to update their script, even those users that don't have automatic updates enabled) we could announce a Beta release of the WebGUI version.

[Martinski4GitHub]

Good to go.

[ExtremeFiretop]

Things remaining to test:

1. Changelog approval functionality.

2. Updating from 1.3.10 to 1.4.0 version.

Yeah, I have bullet point 2 in my to-do list as well. I think after those tests are done and completed to our satisfaction, we can issue the 1.3.10 production release, and then perhaps a couple of weeks later (to allow everyone to update their script, even those users that don't have automatic updates enabled) we could announce a Beta release of the WebGUI version.

Agreed! Nearing the end but not quite done yet. Still a bit more validating and tweaking to go but we are so close!

[ExtremeFiretop]

So the long work days have begun, and I need to rest & unwind by the time I get home.

I hear you there! The last 2 weeks have been work work work and then catching up on sleep, it was much required. My brain was starting to feel like scrambled egg! I needed to catch up on sleep and focus on other things for a while.

Yeah, I finally set up the RT-AX86U_PRO as the main home router, and the RT-AC86U is in my home office as a secondary router (i.e. double NAT). This allows me to use the old router for development and testing purposes while providing a very good WiFi signal to the back patio and the backyard all the way to the back fence. It's been working well - so far no complaints.

Fantastic news! So you didn't set it up as a node in the end? Sounds like it's really a router on router setup since you mentioned double nat? Was that specifically for development purposes or did the node cause issues? I'm just curious.

Upon a fresh installation of the script, I've always assumed that there's a way to know whether the current F/W build type is "ROG" or "TUF" or the "Standard" Merlin. I don't have a way to test & verify this, but I'm assuming that there's some NVRAM value that has this information, is this assumption correct?

If I'm incorrect and there's no such a built-in indication of the currently installed F/W build type, and the only way to know with certainty is via the F/W image binary file that contains the "ROG" or "TUF" tags (like the "Gnuton" builds) then it makes it more challenging to initialize the corresponding configuration setting appropriately.

So I can double check the nvram values but I didn't find any initially, which I think is why we use the tag in the file names currently. (As you described). If it finds a _rog file or a _tuf file, etc. and starts as a TBD value, and if remains unset when a flash is started, and a ROG file is present, it defaults to the pure build (if I remember the flow correctly, will double check quickly)

If I can find a nvram value it would make the job much easier.

Unfortunately, since I don't have a router with a "ROG" or "TUF" build type, I can't really be of much trying to understand what the current behavior is to figure out the best solution.

No worries, I'll poke at this and find a working and acceptable solution for us both, I've managed the ROG and TUF options from the start anyways it's probably fair I poke at revising this again. 😉

[Martinski4GitHub]

So the long work days have begun, and I need to rest & unwind by the time I get home.

I hear you there! The last 2 weeks have been work work work and then catching up on sleep, it was much required. My brain was starting to feel like scrambled egg! I needed to catch up on sleep and focus on other things for a while.

Yes, exactly.

Yeah, I finally set up the RT-AX86U_PRO as the main home router, and the RT-AC86U is in my home office as a secondary router (i.e. double NAT). This allows me to use the old router for development and testing purposes while providing a very good WiFi signal to the back patio and the backyard all the way to the back fence. It's been working well - so far no complaints.

Fantastic news! So you didn't set it up as a node in the end? Sounds like it's really a router on router setup since you mentioned double nat? Was that specifically for development purposes or did the node cause issues? I'm just curious.

I never even tried setting it up as a node. I prefer having the secondary router with separate LAN subnets, and access to the full webGUI to configure it as I want to which, as a bonus, provides a development & test environment. It's a win-win situation for me :>).

Upon a fresh installation of the script, I've always assumed that there's a way to know whether the current F/W build type is "ROG" or "TUF" or the "Standard" Merlin. I don't have a way to test & verify this, but I'm assuming that there's some NVRAM value that has this information, is this assumption correct?
If I'm incorrect and there's no such a built-in indication of the currently installed F/W build type, and the only way to know with certainty is via the F/W image binary file that contains the "ROG" or "TUF" tags (like the "Gnuton" builds) then it makes it more challenging to initialize the corresponding configuration setting appropriately.

So I can double check the nvram values but I didn't find any initially, which I think is why we use the tag in the file names currently. (As you described). If it finds a _rog file or a _tuf file, etc. and starts as a TBD value, and if remains unset when a flash is started, and a ROG file is present, it defaults to the pure build (if I remember the flow correctly, will double check quickly)

If I can find a nvram value it would make the job much easier.

Unfortunately, since I don't have a router with a "ROG" or "TUF" build type, I can't really be of much trying to understand what the current behavior is to figure out the best solution.

No worries, I'll poke at this and find a working and acceptable solution for us both, I've managed the ROG and TUF options from the start anyways it's probably fair I poke at revising this again. 😉