MerlinAU MerlinAU v1.4.7 - The Ultimate Firmware Auto-Updater (WEBUI + GNUTON SUPPORT!)

[micka57]

Il semble que @visortgw vous ait aidé, mais je vous recommande de lire l'intégralité du Wiki pour toutes les questions afin de voir si elles ont déjà reçu une réponse :

https://github.com/ExtremeFiretop/M...l-comment-configurer-les-identifiants-de-mail

La question 4 concerne les options de courrier électronique

Bonjour,

Oui il m'as aidé, je m'excuse je débute avec asuswrtmerlin j'avais pas vu l'option -em

 

[ExtremeFiretop]

Bonjour,

Oui il m'as aidé, je m'excuse je débute avec asuswrtmerlin j'avais pas vu l'option -em

Salut, pas de problème...
je voulais juste te diriger vers le Wiki pour les question de configuration.

FYI this is an English only forum; but I appreciate the sentiment of you using my native Gatineau French

 

[Ripshod]

Small niggle.
If MerlinAU is installed and setup before BACKUPMON the backup option remains greyed out, surviving reboots. BACKUPMON needs to be installed first if you want to make use of it.
That's my experience anyways

 

[ExtremeFiretop]

Small niggle.
If MerlinAU is installed and setup before BACKUPMON the backup option remains greyed out, surviving reboots. BACKUPMON needs to be installed first if you want to make use of it.
That's my experience anyways

Thanks for reporting @Ripshod

MerlinAU got put on the back burner a bit, while we focused on OSR but now that it's mostly done, we are focusing on MerlinAU again.

Merging some PRs in today, and I'll look into this report as well

 

[ExtremeFiretop]

Small niggle.
If MerlinAU is installed and setup before BACKUPMON the backup option remains greyed out, surviving reboots. BACKUPMON needs to be installed first if you want to make use of it.
That's my experience anyways

Okay I managed to re-create this report.

You must be specifically speaking about the WebUI for MerlinAU right? When you say "greyed out" I'm assuming that is what you mean?
In my case I noticed it as well only in the WebUI; the shell script correctly reflects any changes to the BACKUPMON install.

In-fact if I start the MerlinAU CLI script after I installed Backupmon; then it updates the WebUI and makes the option available. (ungreyed)

So my theory at this moment is the following:
1. You installed MerlinAU
2. Then installed Backupmon
3. Then checked the WebUI for MerlinAU (But without actually starting the MerlinAU CLI script first)

This causes the WebUI to not reflect the new state of the BACKUPMON install.
The 3 quick workarounds are simple and you already found one of them:

1. Start the MerlinAU CLI from SSH to set the value for BACKUPMON.
2. Wait until the overnight cron job runs.
3. Install Backupmon first and then MerlinAU so it can set it on first install.

 

[Ripshod]

#3 is what I did, after uninstalling MerlinAU.
Just something I never expected to see

 

[ExtremeFiretop]

MerlinAU 1.4.7 Released!

What's Changed/Fixed?:

PR: [ #475 ] - Patch WebUI

• Resolves issues reported by @TheS1R / @visortgw
• Added Grey out for the "Install Script" checkbox (only if Auto updates is enabled for the script)
• Changed the wording if Auto updates for the script are enabled to clarify it will update NOW.
• Added ability to navigate the F/W Changelog in the WebUI by direction keys as requested by @kriukas
• Allow Changelog viewing function to detect migration of code base from 3004 to 3006 firmware.

PR: [ #476 ] - Fix Web-Access Restrictions, Changelog Verification, WebUI Selections, and Firmware Run Estimates

• All issues reported by: @kriukas
• Added missing changelog patch to force the proper changelog verification in an upgrade from 3004 to 3006
• Modified the changelog verification to be more universal. Previously it only checked between 2 matching firmware versions tags, (the currently installed and update version) which won't exist in firmware changelogs in upgrades from 388.8 and 3006.
• Also previously did not flatten the change log content so line breaks are missed such as:
  "any additionnal GN must be
  manually reconfigured."
• Fix Web Access Restrictions by modifying the regex to accept subnets larger than /20
• Fix issue with postpone calculations. Previously changing the postpone period in the WebUI did not correctly recalculate the new estimate flash time. Now we force it too.
• Now correctly sets the "Firmware Run Estimates" to TBD when disabling "built-in firmware update checks"
• Fixed emails showing an estimated date when the "Enable Automatic F/W Update Checks" is DISABLED
• Fix the WebUI Password Focus on Edge/Chrome, which is stealing focus even when the password is valid

PR: [ #478 ] - Fixes and Improvements

• Improved WebUI Access Restrictions to check for valid CIDR IP address blocks.
• Fix for changelog tag check going from NG to 3006.
• Coding improvements and fine-tuning.
• (Thanks @Martinski4GitHub )

PR: [ #479 ] - More Fixes and Improvements

• Fixed bug where the wrong tooltip message is displayed when the password status is INVALID due to a failed login attempt.
• Fixed missing tooltip messages for 2 password statuses: "Not Verified" and "Verified."
• Improved fix for the focus issue on WebGUI using MS Edge and Google Chrome browsers.
• (Thanks @Martinski4GitHub )

PR: [ #480 ] -Modified RAM Requirements for F/W Flash Process

• Resolve issue [BUG] - Update fails on RT-AX86S #477 reported on Github by @DrEthan77 with routers with 512MB of RAM or less.
• Essentially, for routers with 512MB RAM, the implementation has 2 fronts:
  a) Lower the initial required RAM overhead from 50% to 35% before the ZIP file is downloaded, and then lower it again to 25% after the F/W image is extracted.
  b) When trying to acquire more available RAM, the code attempts to disable some ASUS/TrendMicro services:
  AsusNat Tunnel, AiProtection, Traffic Analyzer/Monitor, and Bandwidth Monitor
• (Thanks @Martinski4GitHub )

As always, we highly recommend you update ASAP as this includes functional improvements and little bug fixes.
Thanks!

 

[JimbobJay]

Minor bug report:

In my setup, I have an RT-AX86U_Pro running as my main router, and then I have an AC86U running as an AP. Due to also having additional UniFi APs, I chose not to use AiMesh to manage the AC86U AP, so I could have more fine-tuned control over its Wireless settings, such as channels, transmit power, etc.

Due to the ASUS AP not being an AiMesh node and having its own manual setup via the web-ui, I also have a different web-ui password set for that AP as compared to my main AX86U_Pro router.

This setup seems to cause MerlinAU some confusion. It erroneously reports that my Router Login Password is wrong, with the CLI showing "[Currently Password is INVALID.]"

This isn't correct. The password set in MerlinAU is correct for my AX86U_Pro. The AP isn't an AiMesh Node, and isn't even running Merlin - I manually update its official ASUSWRT firmware every now and then, so I don't need MerlinAU to even interact with that device at all.

When I 'Set Router Login Password', MerlinAU will test it on the main router, see that it works, and go back to reporting the password is correct. But then as soon as it tries using that password to interact with the AP on an update check, it goes back to erroneously reporting the password as invalid, even though it is only invalid for the AP.

I think MerlinAU needs to improve its logic in checking whether ASUS APs on the network are actually running as AiMesh nodes, or just running in simple AP mode, so that it ignores them. Or perhaps it needs a toggle so as to only run checks on the main router it is running on, and ignore any other ASUS APs, MAiMesh or not?

Don't know what exactly the best solution is, just throwing ideas out there. It's not even a major bug tbh, because the update process still works for the main router, which is what's important - only a minor annoyance to see it say 'Password is INVALID' when it's not.

 

[ExtremeFiretop]

Minor bug report:

In my setup, I have an RT-AX86U_Pro running as my main router, and then I have an AC86U running as an AP. Due to also having additional UniFi APs, I chose not to use AiMesh to manage the AC86U AP, so I could have more fine-tuned control over its Wireless settings, such as channels, transmit power, etc.

Due to the ASUS AP not being an AiMesh node and having its own manual setup via the web-ui, I also have a different web-ui password set for that AP as compared to my main AX86U_Pro router.

This setup seems to cause MerlinAU some confusion. It erroneously reports that my Router Login Password is wrong, with the CLI showing "[Currently Password is INVALID.]"

This isn't correct. The password set in MerlinAU is correct for my AX86U_Pro. The AP isn't an AiMesh Node, and isn't even running Merlin - I manually update its official ASUSWRT firmware every now and then, so I don't need MerlinAU to even interact with that device at all.

When I 'Set Router Login Password', MerlinAU will test it on the main router, see that it works, and go back to reporting the password is correct. But then as soon as it tries using that password to interact with the AP on an update check, it goes back to erroneously reporting the password as invalid, even though it is only invalid for the AP.

I think MerlinAU needs to improve its logic in checking whether ASUS APs on the network are actually running as AiMesh nodes, or just running in simple AP mode, so that it ignores them. Or perhaps it needs a toggle so as to only run checks on the main router it is running on, and ignore any other ASUS APs, MAiMesh or not?

Don't know what exactly the best solution is, just throwing ideas out there. It's not even a major bug tbh, because the update process still works for the main router, which is what's important - only a minor annoyance to see it say 'Password is INVALID' when it's not.

You have not provided enough detail to investigate, please provide screenshots.
If the AP isn't running Merlin how could it be running MerlinAU?

If your talking about the primary AX86U_Pro; it only tests the login for the primary router under the option (2) to set a password; and it tests/does nothing to do with the nodes or the APs. So if it says Login failed it means login failed for the primary router. ( AX86U_Pro)
If your checking under option mn (AiMesh Nodes) from the primary router, then you can ignore the failed login. It will only work with officially joined Mesh nodes. That option shouldn't even be available to you.

Again, screenshots go a long way to better understanding what your talking about.

 

[JimbobJay]

You have not provided enough detail to investigate, please provide screenshots.
If the AP isn't running Merlin how could it be running MerlinAU?

If your talking about the primary AX86U_Pro; it only tests the login for the primary router under the option (2) to set a password; and it tests/does nothing to do with the nodes or the APs. So if it says Login failed it means login failed for the primary router. ( AX86U_Pro)
If your checking under option mn (AiMesh Nodes) from the primary router, then you can ignore the failed login. It will only work with officially joined Mesh nodes. That option shouldn't even be available to you.

Again, screenshots go a long way to better understanding what your talking about.

Thanks for the quick reply.

So, here is what I see when I meant MerlinAU reports Password is INVALID:



I can choose Option 2. and set the password again (using exactly the same credentials), and it works, so that this is what I will then (temporarily) see:


However, if MerlinAU then runs an FW check, whether manual or automatic, it attempts to login to my AP (which yes, as you say, is not running Merlin anyway, and so it shouldn't be trying to do this):



MerlinAU then goes back to reporting the password is INVALID, even though it is not invalid for the main router.

I don't know why MerlinAU is seeing the AP as an AiMesh Node when it is not an AiMesh Node.

If I select option mn. this is what I see:

If the AP isn't running Merlin how could it be running MerlinAU?

It's not running MerlinAU, only the primary router has Asuswrt-Merlin and MerlinAU installed.

Perhaps the issue is not with MerlinAU then, but with the router incorrectly reporting the AP to MerlinAU as being an AiMesh Node, when it's not?

I have no idea tbh - all I know is that the AP is not a Mesh node, it is running in AP mode, and nor is it running Merlin, it is running ASUSWRT, and so MerlinAU shouldn't be trying to login to it, and that the password is not invalid for the device I do actually want MerlinAU to interact with.

 

[ExtremeFiretop]

Thanks for the quick reply.

So, here is what I see when I meant MerlinAU reports Password is INVALID:
View attachment 66121


I can choose Option 2. and set the password again (using exactly the same credentials), and it works, so that this is what I will then (temporarily) see:
View attachment 66122

However, if MerlinAU then runs an FW check, whether manual or automatic, it attempts to login to my AP (which yes, as you say, is not running Merlin anyway, and so it shouldn't be trying to do this):
View attachment 66123


MerlinAU then goes back to reporting the password is INVALID, even though it is not invalid for the main router.

I don't know why MerlinAU is seeing the AP as an AiMesh Node when it is not an AiMesh Node.

If I select option mn. this is what I see:
View attachment 66124



It's not running MerlinAU, only the primary router has Asuswrt-Merlin and MerlinAU installed.

Perhaps the issue is not with MerlinAU then, but with the router incorrectly reporting the AP to MerlinAU as being an AiMesh Node, when it's not?

I have no idea tbh - all I know is that the AP is not a Mesh node, it is running in AP mode, and nor is it running Merlin, it is running ASUSWRT, and so MerlinAU shouldn't be trying to login to it, and that the password is not invalid for the device I do actually want MerlinAU to interact with.

Yes I now much better understand the situation you are facing, give me a bit of time to investigate and report back.
Sadly I don't have any AP's setup and only aiMesh nodes, but I will still do a code review to see what might be happening.

 

[ExtremeFiretop]

@JimbobJay

Can you run these for me on the primary router and report the results:

nvram get cfg_device_list
nvram get asus_device_list

Feel free to DM the results if you rather.

 

[JimbobJay]

@JimbobJay

Can you run these for me on the primary router and report the results:

nvram get cfg_device_list
nvram get asus_device_list

Feel free to DM the results if you rather.

DMed you. Thanks for looking into it