[Beta] Asuswrt-Merlin 384.18 Beta / 384.13_9 is now available

[CaptnDanLKW]

Took the dive, first step was to check amtm.

Problem.

entware package upgrades available but fail...

@RTAC86U:/tmp/home/root# opkg upgrade
Upgrading syslog-ng on root from 3.26.1-1 to 3.27.1-1...
Downloading http://bin.entware.net/aarch64-k3.10/aarch64-k3.10/syslog-ng_3.27.1-1_aarch64-3.10.ipk
Upgrading opkg on root from 2019-06-14-dcbc142e-2 to 2020-05-07-f2166a89-1...
Downloading http://bin.entware.net/aarch64-k3.10/aarch64-k3.10/opkg_2020-05-07-f2166a89-1_aarch64-3.10.ipk
...
Collected errors:
* opkg_download: Failed to download http://bin.entware.net/aarch64-k3.10/aarch64-k3.10/syslog-ng_3.27.1-1_aarch64-3.10.ipk, wget returned 8.
* opkg_install_pkg: Failed to download syslog-ng. Perhaps you need to run 'opkg update'?
* opkg_download: Failed to download http://bin.entware.net/aarch64-k3.10/aarch64-k3.10/opkg_2020-05-07-f2166a89-1_aarch64-3.10.ipk, wget returned 8.
* opkg_install_pkg: Failed to download opkg. Perhaps you need to run 'opkg update'?

I did run opkg update first.

Might be a temporary condition, maybe not...

Stability wise I'm sure its fine.

 

[RAH-66]

@CaptnDanLKW
https://www.snbforums.com/threads/amtm-the-asuswrt-merlin-terminal-menu.42415/page-111#post-595092

 

[QuikSilver]

@QuikSilver, why three tries?

I was too lazy to unmount and remove USB drive before upgrading. I assume thats why it failed but thrird time it finally took.

 

[AurelM]

Updated my local RT-AC68U and a remote RT-AC66U B1 (so both use the same firmware file) from 384.17_0 to 384.18_beta1 without issues. There's a site to site vpn between the two and the remote update was done over the vpn connection from my local pc. After the update, I've given the local router a cold start (shut it down, unplugged it from the outlet, waited for the electrical current to be consumed from the capacitors, about 20-30 seconds, re-plugged it in and then turned it on).

I was too lazy to unmount and remove USB drive before upgrading. I assume thats why it failed but thrird time it finally took.

You just need to unmount it from WebUI so most of the ram gets freed, then update the router, no need to unplug the drive physically.

Thank you @RMerlin !

 

[L&LD]

@QuikSilver, @AurelM is correct. Just 'unmount' all USB drives attached via the GUI. No need to physically remove them (free RAM is what we're seeking).

 

[kernol]

@QuikSilver, @AurelM is correct. Just 'unmount' all USB drives attached via the GUI. No need to physically remove them (free RAM is what we're seeking).

Sadly ... my RT-AC86U is "bad" from time to time - and the webgui Eject process appears to have responded - but the clue to its "errant ways" is in the fact that the spare RAM hardly increases ... so to be sure - I disable jffs custom scripts under Administration Tab and reboot router before applying firmware update.

Has never failed me once - get clean firmware upgrade every time .

 

[CriticJay]

@QuikSilver, @AurelM is correct. Just 'unmount' all USB drives attached via the GUI. No need to physically remove them (free RAM is what we're seeking).

question, should we manually stop scripts such as Skynet and Diversion before the unmounting - or just unmount it?

 

[L&LD]

@kernol, I have seen this too when a router was on for a long time (over 30 days). I did attempt to install the new firmware but the router indicated that the 'image was not correct'. After it rebooted, unmounting the USB drive(s) again worked as expected. With free(r) RAM and a successful flash.

@CriticJay, the act of 'safely removing the USB drive(s)' also properly stops all scripts that rely on it too. One single step and many issues avoided after I adopted this process for updating the RMerlin powered routers I support.

 

[RejZoR]

GPL was also released for 384.9354.

But won't land in this update yet, given Merlin is mentioning GPL of an older version. I'll have to wait some more for it to trickle down into Merlin's builds.

 

[RMerlin]

@RMerlin this code is compatible between AX models?

Not compatible with the current 384_8xxx code used. Also why I didn't merge the RT-AX88U's 384_9107. And I don't know yet if these two are compatible with one another either. That's another headache for later.

 

[CaptainSTX]

Upgraded from 384.17 to 384.18b with no issues and it is running fine. Thank you Merlin.

Did notice that the network map still does not show wireless devices being consistently connected to Guest 3 on either the 2.4 Ghz and the 5 Ghz radio. They disappear from the map after being briefly shown after making a change to WiFi or a router reboot. The devices show as connected in the log and function perfectly.

Moved the eight devices that were connected to Guest 3 on the 5 Ghz to Guest 1 and they consistently show up on the network map. I used the same SSID and password on both Guest 1 and Guest 3.

I did some further testing and moved a device on the 2.4 Ghz radio Guest 3 and it resulted in the device disappearing from the network map. Also tested Guest 2 on both bands and devices are reported correctly.

All devices have a static IPs assigned by the router outside the DHCP pool. Plenty of memory so that shouldn't be the problem.

Not really a major problem but have been using Guest 3 at least back five versions.

 

[nzwayne]

Installed Beta1 ok on my RT-AX88U + 2x RT86U's in AiMesh. I also too lazy and didn't un-mount USB drive. When I don't, the upgrade request on the AX88U sits there for like 60secs, before the progression to convert starts. Next time will use the GUI to un-mount USB drive, as does sound more technically rational. Converted my neighbours RT-AC87U, all went well with that too.
After 10mins or more, I always power off/on the upgraded units. What I've found with my RT-AX88U (with the USB drive installed), the power off has to be like a minimum of 10mins or more, anything shorter the 5GHz functions are down & 5GHz wireless light on the case doesn't turn on. Without the USB drive and a quick off (10secs) then on, no issues.

 

[L&LD]

@nzwayne, I would suggest you 'safely remove' the USB drive(s) from the router before you power them off too (to prevent any drive corruption).

 

[Deleted member 22229]

Just installed 384.18 Beta 1. Working excellent on AX58U.

Thanks @Merlin

 

[matthew_eli]

Dirty upgrade from 384.17 to 384.18beta1 on RT-AC86U and I registered only a small glitch (missing icon) on the homepage of the router webUI (picture enclosed)

Tried also F5, with no luck

Also the green "gear" of the Adaptive QOS icon on the right upper corner seems irregular, like zoomed and truncated

 

[RMerlin]

Tried also F5, with no luck

You need a forced refresh, i.e. press shift while pressing on the reload icon. This will force your browser to bypass its (outdated) cache content.

 

[fields987]

Have been running .18 since early alpha builds. Installed this beta yesterday. No issues to report on my ax88u.

 

[bughit]

The source code is the base, open-sourced portion. The SDK is the platform-specific content, like the kernel and the includes. And the binary blobs is everything that is closed source, like the wireless driver, or the other pre-compiled portions.

Identical code means exactly what it says: the code is the same, only the version number is different.

@RMerlin

By "The source code is the base, open-sourced portion.", it seems you're saying that "code" in the phrase "code is identical to 384_81846" is referring to the GPL (the base open-sourced portion). Is that correct? So AC68U has 384_81918 GPL but then you mention "code is identical to 384_81846". So are are you saying 384_81918 GPL and 384_81846 GPL are identical? What is the relevance of that, because 384_81846 is not otherwise mentioned in the changelog?

There is also still confusion about the GPL version numbers.

384.15 received GPL 385_10002 from AC68U and 384.18 received 384_81918 (does not mention from where). Presumably 384_81918 is from AC86U and is newer than 385_10002, is that correct?

So is it the case that the GPL versions by themselves are meaningless because the can't be compared? They can only be compared for a given model? How is one supposed to understand without diffing code that 384_81918 is newer than 385_10002?

 

[RMerlin]

How is one supposed to understand without diffing code that 384_81918 is newer than 385_10002?

This is the developer's problem (mine), not the end user's.

 

[QuikSilver]

This is the developer's problem (mine), not the end user's.

In @RMerlin we trust.......