Update MerlinAU.sh

[ExtremeFiretop]

Lets dynamically add the overhead based on the zip size using a percentage.

[Martinski4GitHub]

Lets dynamically add the overhead based on the zip size using a percentage.

Yeah, that makes more sense. I'd say at least 50% overhead when not using a USB-attached drive for downloading the F/W ZIP file.

[ExtremeFiretop]

Lets dynamically add the overhead based on the zip size using a percentage.

Yeah, that makes more sense. I'd say at least 50% overhead when not using a USB-attached drive for downloading the F/W ZIP file.

So for example. My zip file is usually about 150MB plus 50% brings us up to 225MB of free memory to do the flash?
Are we sure we need that much memory free? I don't want the script to be too "heavy" for lower grade routers that don't have more than 256MB of RAM.

Thinking of something like the ASUS RT-AC87U router comes equipped with 256 MB of RAM and 128 MB of flash.
Now I realize that router might be a bad example because it hasn't received merlin updates since 2019.

But that zip file is about 40MB.
So 40MB plus 50% brings it up to 90MB.

But the RT-AC1900/RT-AC68U is another one for example still getting updates as of this year, it only has 256MB of RAM and it's zip file is currently 90MB brings it up to 135MB of it's available 256MB.

That leaves ~120MB of play room for the router or the update won't start. I just want to make sure we don't make the script too demanding for some of the lower end routers.

[ExtremeFiretop]

Lets dynamically add the overhead based on the zip size using a percentage.

Yeah, that makes more sense. I'd say at least 50% overhead when not using a USB-attached drive for downloading the F/W ZIP file.

Speaking of routers that no longer receive updates.
I added all these to the blocked list, since they no longer seem to have received updates in the last 3 to 4 years.

RT-AC87U (Blocked)
RT-AC56U (Blocked)
RT-AC66U (Blocked)
RT-AC3200 (Blocked)
RT-N66U (Blocked)

Plus these were all older models "(Single image models) - i.e. Any model that uses a .trx file"

Also added:
RT-AC66U_B1 (Blocked)
RT-AC1900 (Blocked)

Because they are based on the same RT-AC68U which we had already blocked.

(Although I want to have Yota re-test this now with the better memory management). I've sent a message in the forums hoping he does retest.

[Martinski4GitHub]

Lets dynamically add the overhead based on the zip size using a percentage.

Yeah, that makes more sense. I'd say at least 50% overhead when not using a USB-attached drive for downloading the F/W ZIP file.

So for example. My zip file is usually about 150MB plus 50% brings us up to 225MB of free memory to do the flash? Are we sure we need that much memory free? I don't want the script to be too "heavy" for lower grade routers that don't have more than 256MB of RAM.

Thinking of something like the ASUS RT-AC87U router comes equipped with 256 MB of RAM and 128 MB of flash...

But that zip file is about 40MB. So 40MB plus 50% brings it up to 90MB.

But the RT-AC1900/RT-AC68U is another one for example still getting updates as of this year, it only has 256MB of RAM and it's zip file is currently 90MB brings it up to 135MB of it's available 256MB.

That leaves ~120MB of play room for the router or the update won't start. I just want to make sure we don't make the script too demanding for some of the lower end routers.

My recommendation was based on what I know about the RT-AC86U & RT-AC68U routers & what I've experienced when doing manual F/W updates using the webGUI.

For example, in the case of the RT-AC86U F/W 386.12_0 version, the ZIP file size is 74,260,951 bytes (~71MB). The F/W Image file size is 83,099,668 bytes (~79MB). This means that if both files are stored on the $HOME directory (which is under tmpfs - the virtual disk filesystem allocated from RAM), the storage requirement would be 157,360,619 bytes (~150MB) right at the moment that both files exists on the $HOME directory. The RT-AC86U can handle this scenario because it has 512MB RAM, with ~200MB dynamically allocated for tmpfs. When doing manual F/W Updates, they go well (i.e. no prior reboots necessary) as long as available RAM is ~100MB.

However, in the case of the RT-AC68U F/W 386.12_0 version, the ZIP file size is 95,688,114 bytes (~91MB), and the F/W Image file size is 98,447,380 bytes (~94MB), for a total storage requirement of 194,135,494 bytes (~185MB). The RT-AC68U has only 256MB RAM, with ~125MB dynamically allocated for tmpfs, which means that it cannot handle the scenario where both "ZIP + Image" files are stored on the $HOME directory, even if only temporarily.

I'd say most (likely all?) routers with 256MB RAM cannot handle such a scenario (even with each file size in the ~60MB range) so for these cases the only possible way it might work is to use a USB-attached drive to store the ZIP file.

For routers with 512MB RAM, as long as available RAM is at least "ZIP file size + 50%" with tmpfs dynamically allocated size from RAM in the ~200MB, it works fine. Routers with 1GB RAM should have no problem at all, especially since tmpfs size is usually > 450MB, unless the router happens to be running some kind of service or custom script that eats up quite a lot of RAM after many days/weeks of uptime.

My 2 cents.

[ExtremeFiretop]

Lets dynamically add the overhead based on the zip size using a percentage.

Yeah, that makes more sense. I'd say at least 50% overhead when not using a USB-attached drive for downloading the F/W ZIP file.

So for example. My zip file is usually about 150MB plus 50% brings us up to 225MB of free memory to do the flash? Are we sure we need that much memory free? I don't want the script to be too "heavy" for lower grade routers that don't have more than 256MB of RAM.
Thinking of something like the ASUS RT-AC87U router comes equipped with 256 MB of RAM and 128 MB of flash...
But that zip file is about 40MB. So 40MB plus 50% brings it up to 90MB.
But the RT-AC1900/RT-AC68U is another one for example still getting updates as of this year, it only has 256MB of RAM and it's zip file is currently 90MB brings it up to 135MB of it's available 256MB.
That leaves ~120MB of play room for the router or the update won't start. I just want to make sure we don't make the script too demanding for some of the lower end routers.

My recommendation was based on what I know about the RT-AC86U & RT-AC68U routers & what I've experienced when doing manual F/W updates using the webGUI.

For example, in the case of the RT-AC86U F/W 386.12_0 version, the ZIP file size is 74,260,951 bytes (~71MB). The F/W Image file size is 83,099,668 bytes (~79MB). This means that if both files are stored on the $HOME directory (which is under tmpfs - the virtual disk filesystem allocated from RAM), the storage requirement would be 157,360,619 bytes (~150MB) right at the moment that both files exists on the $HOME directory. The RT-AC86U can handle this scenario because it has 512MB RAM, with ~200MB dynamically allocated for tmpfs. When doing manual F/W Updates, they go well (i.e. no prior reboots necessary) as long as available RAM is ~100MB.

However, in the case of the RT-AC68U F/W 386.12_0 version, the ZIP file size is 95,688,114 bytes (~91MB), and the F/W Image file size is 98,447,380 bytes (~94MB), for a total storage requirement of 194,135,494 bytes (~185MB). The RT-AC68U has only 256MB RAM, with ~125MB dynamically allocated for tmpfs, which means that it cannot handle the scenario where both "ZIP + Image" files are stored on the $HOME directory, even if only temporarily.

I'd say most (likely all?) routers with 256MB RAM cannot handle such a scenario (even with each file size in the ~60MB range) so for these cases the only possible way it might work is to use a USB-attached drive to store the ZIP file.

For routers with 512MB RAM, as long as available RAM is at least "ZIP file size + 50%" with tmpfs dynamically allocated size from RAM in the ~200MB, it works fine. Routers with 1GB RAM should have no problem at all, especially since tmpfs size is usually > 450MB, unless the router happens to be running some kind of service or custom script that eats up quite a lot of RAM after many days/weeks of uptime.

My 2 cents.

Makes me want to integrate a way to check if your router is a 256MB model, and if it is, force a USB mount point to run the script. Else the run function tells you to bugger off and get a USB.

[Martinski4GitHub]

Makes me want to integrate a way to check if your router is a 256MB model, and if it is, force a USB mount point to run the script. Else the run function tells you to bugger off and get a USB.

The RT-AC68U router is likely the worst-case scenario due to the large ZIP & Image file sizes because of the many variants for that model. Other routers with 256MB RAM might fare a little better if the "ZIP + Image" is <= 100MB (like the one for the RT-AC87U).

Perhaps that would be a good check to have. If the total RAM is 256MB and the ZIP file size is over 50MB do not allow the F/W Update to run unless a USB-attached drive is available and has been selected to store the ZIP file.

Also, in general, it might be prudent to at least show a WARNING message when the menu is displayed indicating that without a USB drive, the F/W update may not work successfully because the router has only 256MB of RAM.

[ExtremeFiretop]

For routers with 512MB RAM, as long as available RAM is at least "ZIP file size + 50%" with tmpfs dynamically allocated size from RAM in the ~200MB, it works fine. Routers with 1GB RAM should have no problem at all, especially since tmpfs size is usually > 450MB, unless the router happens to be running some kind of service or custom script that eats up quite a lot of RAM after many days/weeks of uptime.

My 2 cents.

As discussed I upped the default overhead percentage to 50% from 20% here: c0d4bc0

Next step might be the WARNING and check for a 256MB model.

[Martinski4GitHub]

Next step might be the WARNING and check for a 256MB model.

I just submitted a PR that includes the function "HasRouterMoreThan256MBtotalRAM()" which can be used for the WARNING msg. I ran out of time this evening to do it, but you can do it if you want.

[ExtremeFiretop]

Next step might be the WARNING and check for a 256MB model.

I just submitted a PR that includes the function "HasRouterMoreThan256MBtotalRAM()" which can be used for the WARNING msg. I ran out of time this evening to do it, but you can do it if you want.

Done! PR created: #34