MerlinAU MerlinAU v1.2.2 - The Ultimate Firmware Auto-Updater (Now available in AMTM)

[visortgw]

This is fantastic news, and honestly you went above and beyond for me tonight so I really appreciate that. A+ for sure!

I'll be updating the list now and honestly at this point it's up to you if you want to keep it installed but for my purposes this was more than enough validation.

Thanks again!

AiMesh nodes are low risk. Worst case, you factory reset and re-pair it to primary router.

 

[ExtremeFiretop]

AiMesh nodes are low risk. Worst case, you factory reset and re-pair it to primary router.

Fully agreed, it's why I do all my development work on the node AXE11000 instead of the primary one lol.

My primary router does run MerlinAU, but it gets updated along with everyone else whenever I rollout a new update and that's it

 

[ExtremeFiretop]

I also have a decommissioned RT-AX68U that I can test when I get home mid-week.

That would be fantastic, again no rush and I realize this isn't top of the line hardware, but this is why those models will be important to test since they would have weaker specs than your AXE16000.

Whenever you get a chance I would be so grateful!

 

[visortgw]

Hey @visortgw i literally just noticed in this message you had a GT-AXE16000 listed.
This model is still listed as an "untested" model on our Github:

• GT-AXE16000 (Untested)
• GT-AC2900 (Untested)
• RT-AX68U (Untested)
• RT-AX56U (Untested)
• RT-AX3000 (Untested)

Did you happen to ever install MerlinAU on that node for testing? Based on the specs of that beast I don't expect an issue but just figured I'd ask.
Actually while I'm bringing this up, if anyone is using MerlinAU on any of the models listed above feel free to report

You can also list the RT-AX3000 as tested since it is hardware identical to the RT-AX58U — the difference was simply a marketing ploy by Asus in different markets or with different resellers (I forget the specifics).

 

[ExtremeFiretop]

You can also list the RT-AX3000 as tested since it is hardware identical to the RT-AX58U — the difference was simply a marketing ploy by Asus in different markets or with different resellers (I forget the specifics).

Oh very good!

Yes doing a Google search on that specific model, I do see they appear to be identical. (Thanks Asus) One is a Bestbuy specific model hahaha that's not adding to confusion.

Thanks for the clarification!

 

[ExtremeFiretop]

You can also list the RT-AX3000 as tested since it is hardware identical to the RT-AX58U — the difference was simply a marketing ploy by Asus in different markets or with different resellers (I forget the specifics).

Okay lists updated both here and on Github.
Remaining devices would be:

• GT-AC2900 (Untested)
• RT-AX68U (Untested)
• RT-AX56U (Untested)

And when you get to test the RT-AX68U that will leave only 2!

 

[visortgw]

Oh very good!

Yes doing a Google search on that specific model, I do see they appear to be identical. (Thanks Asus) One is a Bestbuy specific model hahaha that's not adding to confusion.

Thanks for the clarification!

Yes, I remembered that one of the two was exclusive to Best Buy.

 

[jksmurf]

You can also list the RT-AX3000 as tested since it is hardware identical to the RT-AX58U

Yup, I have both; might want to put RT-AX3000 (v1) as a suffix though just to be sure.

[EDIT] Had to fix the antennae of the RT-AX3000 once too.

 

[visortgw]

Yup, I have both; might want to put RT-AX3000 (v1) as a suffix though just to be sure.

RT-AX58U v1, as well. Hardware v2 of either device is not compatible with Merlin firmware.

 

[vlord]

I might be in the wrong thread but anyone seeing a spacing misalignment when pulling the MerlinaU cronjob list from amtm?

 

[ExtremeFiretop]

I might be in the wrong thread but anyone seeing a spacing misalignment when pulling the MerlinaU cronjob list from amtm?

View attachment 58977

Nothing from this code in AMTM is dynamic, It's all static:

As you can see, most of my crons don't line up correctly. (Even the ones from thelonelycoder)
"20" or "45" has more character than "*" in the examples above, so trying to line most of this up seems pointless to me

 

[ExtremeFiretop]

RT-AX58U v1, as well. Hardware v2 of either device is not compatible with Merlin firmware.

I added the V1 suffix to the RT-AX58U and AX3000 (for now),
although I may remove it soon once we support GNUTON firmware, as GNUTON supports the RT-AX58U V2 and AX3000 V2

 

[ExtremeFiretop]

I've just experienced the "high-risk phrases" workflow, and have some gentle suggestions for improvement.

I'd prefer if the change-log scan happened before the postponement period. Postpone the flash only, not the download and scan. This will allow you to inform me right away that the flash is blocked. I'll have the rest of the postponement period to review the change-log and register my approval.

What happened instead is, I had already reviewed the change-log and didn't notice anything of concern or high-risk. After the postponement period had passed, I was puzzled that no update had occurred. I ran the update check to see what was wrong and only then was I told that I need to approve the update. So I reviewed the change-log again and still could not tell what the high risk item is. So I approved the update, and it proceeded to flash immediately, interrupting my network. I need to approve during the day and flash later in the night at cron time.

I hope this makes sense. Please let me know if I am doing something wrong, or if other users did not have this same problem.

Hi @nlurker

I started PR: 220 for this request here: https://github.com/ExtremeFiretop/MerlinAutoUpdate-Router/pull/220

 

[visortgw]

@ExtremeFiretop: You can add RT-AX68U to the tested/confirmed list. Steps I tooks:

1. Added RT-AX68U as AiMesh node with latest Asus baseline software.
2. Updated to Merlin 3004.388_6_2.
3. Installed MerlinAU.
4. Manually checked for available update.
5. Discovered 3004.388_7. Confirmed and executed upgrade successfully.

​

 

[ExtremeFiretop]

@ExtremeFiretop: You can add RT-AX68U to the tested/confirmed list. Steps I tooks:

1. Added RT-AX68U as AiMesh node with latest Asus baseline software.
2. Updated to Merlin 3004.388_6_2.
3. Installed MerlinAU.
4. Manually checked for available update.
5. Discovered 3004.388_7. Confirmed and executed upgrade successfully.

​

Your fantastic my friend! Thank you for going the extra mile for us. I'll update the lists shortly!

Just an FYI that we have 3 new PRs merged into the dev branch, so I expect a new release sometime this weekend

 

[visortgw]

Your fantastic my friend! Thank you for going the extra mile for us. I'll update the lists shortly!

Just an FYI that we have 3 new PRs merged into the dev branch, so I expect a new release sometime this weekend

I may not develop scripts, but I test (AND provide constructive feedback) with the best of them!

 

[ExtremeFiretop]

I may not develop scripts, but I test (AND provide constructive feedback) with the best of them!

Thank you! Lists updated

 

[ExtremeFiretop]

MerlinAU Version 1.1.5 released.

What's Changed/Fixed?:

PR: #220 - Allow Pre-Approval for Changelog Check

• This PR is to allow instant notifications to be sent within the postpone period if an update is found with high-risk phrases, and gives the user the option to pre-approve the changelog before the cron attempts to run:
• As requested by @nlurker here: https://www.snbforums.com/threads/m...w-available-in-amtm.88577/page-18#post-907514

PR: #221 - General Code changes & Improvements. (Thanks @Martinski4GitHub)!

• Adjusted some titles and messages to keep the wording as clear and as consistent as possible throughout the UI.
• Some minor code improvements.

PR: #222 - Fixed bug not filtering "Yes" responses properly. (Thanks @Martinski4GitHub)!

• Fixed a bug in the functions handling the following menu options where the "Yes" response from a user was not being filtered correctly.
  1. Toggle F/W Changelog Check
  2. Toggle F/W Update Changelog Approval
  3. Toggle Beta-to-Release F/W Updates
  4. Toggle Automatic Backups
• Here are screenshots showing an example where any string of chars following a "Y" was taken as a "Yes" answer which is not correct.

PR: #223 - Minor wording Improvements in relation to PR: 220

• Adjusted some titles and messages to keep the wording as clear and as consistent as possible throughout the UI.
• Some minor code improvements.

Tightening up some code & general code improvements.

Significant screenshots:

 

[visortgw]

@ExtremeFiretop: Thank you for continuing to update MerlinAU on a regular basis!

As I was updating MerlinAU on my primary GT-AX6000 and four (4) AiMesh nodes (GT-AXE16000, GT-AX6000, and two (2) RT-AX86U), I had a thought that you should consider changing the default firmware update check schedule for primary routers vs AiMesh nodes — just skew one or the other by 10 minutes. That way, there is no chance that the AiMesh nodes lose Internet connection while attempting to download an update because the primary router severed the connection during its own update. Just thinking aloud...

 

[ExtremeFiretop]

@ExtremeFiretop: Thank you for continuing to update MerlinAU on a regular basis!

Hey @visortgw

Happy to continue to work on this on my spare time
Considering I've always wanted an add-on that did all this for me, I'm happy to contribute to the community and give this addon some love when I can.

As I was updating MerlinAU on my primary GT-AX6000 and four (4) AiMesh nodes (GT-AXE16000, GT-AX6000, and two (2) RT-AX86U), I had a thought that you should consider changing the default firmware update check schedule for primary routers vs AiMesh nodes — just skew one or the other by 10 minutes. That way, there is no chance that the AiMesh nodes lose Internet connection while attempting to download an update because the primary router severed the connection during its own update. Just thinking aloud...

We actually did do this in release 1.1.3 as noted below here:

MerlinAU Version 1.1.3 released.

PR: #204 - Include New Logs Menu

• We added a 15 minute offset to the default schedule if MerlinAU is installed on a node.
  

  if "$inRouterSWmode"
  then
      readonly FW_Update_CRON_DefaultSchedule="0 0 * * *"
  else
      readonly FW_Update_CRON_DefaultSchedule="15 0 * * *"
  fi

The only thing is we changed the "defaults" post install.
So basically new installs will see the change, but existing installs would keep whichever schedule they had already set. (Unchanged)