[Beta 382] Asuswrt-Merlin 382.2 Beta is now available

[RMerlin]

Based on your commits to github are you not planning on supporting AiMesh on Merlin Firmware? Or have you just temporarily disabled it whilst getting the new GPL working?

I don't have a final answer yet, but initial tests are hinting that supporting it properly might not be possible. While merging the GPL code I already spotted a couple of problems that might prevent AiMesh from working on Asuswrt-Merlin. Inter node communications is entirely closed source, including the trigger for new firmware checks and uploads. The new firmware check procedure for instance didn't work at all, possibly because the procedure is hardcoded inside the closed source AiMesh service, so it was contacting Asus's servers instead of mine.

For now my focus is just on getting all models to run on 384_10007. After that I will take a closer look at AiMesh, but at a first look, the chances of Asuswrt-Merlin supporting AiMesh are very slim.

 

[RMerlin]

I am now officially cancelling the release of Asuswrt-Merlin 382.2. Too many unresolvable issues surrounding AdaptiveQoS, while fixed code is already available in 384_10007 - no point in wasting any more time on the 382_18991 code base.

I am releasing a final 382.2 Beta 3 version for those still wishing to use it. There is no RT-AC56U GPL for 384_10007, so for the time being, 382.2 Beta 3 will be the only RT-AC56U release available, until Asus releases their next update for that model (no idea when that would happen).

(For the record, my own RT-AC88U is running fine, with an uptime of over 15 days now. I just had to manually restart Adaptive QoS after booting it. So, your mileage may vary.)

The next release will be 384.3, which will provide support for:

RT-AC68U (and all its variants)
RT-AC88U
RT-AC3100
RT-AC86U
RT-AC3200 (will be based on binary blobs from 382_19466 but running 384_10007 GPL code, unless issues appear during development, in which case a separate 382.x release will be made for that model).

 

[charlie2alpha]

I am now officially cancelling the release of Asuswrt-Merlin 382.2. Too many unresolvable issues surrounding AdaptiveQoS, while fixed code is already available in 384_10007 - no point in wasting any more time on the 382_18991 code base.

I am releasing a final 382.2 Beta 3 version for those still wishing to use it. There is no RT-AC56U GPL for 384_10007, so for the time being, 382.2 Beta 3 will be the only RT-AC56U release available, until Asus releases their next update for that model (no idea when that would happen).

The next release will be 384.3, which will provide support for:

RT-AC68U (and all its variants)
RT-AC88U
RT-AC3100
RT-AC86U
RT-AC3200 (will be based on binary blobs from 382_19466 but running 384_10007 GPL code, unless issues appear during development, in which case a separate 382.x release will be made for that model).

Not an ideal situation but it's out of your hands with so many different versions and parts of it becoming increasingly closed source. Seriously, closed source update check? Come on Asus!

As for us owners of the RT-AC56U, seems we have to wait for a new GPL release or go back to 380.69 if we want full functionality at the moment. Binary blob hell...

 

[Grigione]

I hope that a Merlin version AiMesh coming up soon on ac68u,ac86u and others...hope is last our resource ...

 

[RMerlin]

Seriously, closed source update check? Come on Asus!

It's not that they wanted to close that process, it's that it's part of the inter node client/server code. The master node has to tell the childs to check for new firmwares, to download them, and to flash them over the Internet. That part won't work with my own update process.

 

[charlie2alpha]

It's not that they wanted to close that process, it's that it's part of the inter node client/server code. The master node has to tell the childs to check for new firmwares, to download them, and to flash them over the Internet. That part won't work with my own update process.

Ah, I see, a consequence of the mesh architecture itself. Speaking strictly for myself, I do not care if you remove the AiMesh stuff from the firmware. If I was to use such a thing I probably would buy a kit of devices, Google WiFi or Asus Lyra. But that's just me.

 

[XIII]

I am now officially cancelling the release of Asuswrt-Merlin 382.2.

What do you advise people running an 382.2 alpha/beta?

Downgrade to 380 or just keep it until the 384 alpha's arrive?

(In my case for an AC86U)

 

[king006]

What do you advise people running an 382.2 alpha/beta?

Downgrade to 380 or just keep it until the 384 alpha's arrive?

(In my case for an AC86U)

I think you can keep it as long as there are no problems!

 

[charlie2alpha]

What do you advise people running an 382.2 alpha/beta?

Downgrade to 380 or just keep it until the 384 alpha's arrive?

(In my case for an AC86U)

As the above poster said, if it works for you keep it. And anyway most of the newer models will advance to the 384 codebase.

 

[jiancheng]

I am now officially cancelling the release of Asuswrt-Merlin 382.2. Too many unresolvable issues surrounding AdaptiveQoS, while fixed code is already available in 384_10007 - no point in wasting any more time on the 382_18991 code base.

I am releasing a final 382.2 Beta 3 version for those still wishing to use it. There is no RT-AC56U GPL for 384_10007, so for the time being, 382.2 Beta 3 will be the only RT-AC56U release available, until Asus releases their next update for that model (no idea when that would happen).

(For the record, my own RT-AC88U is running fine, with an uptime of over 15 days now. I just had to manually restart Adaptive QoS after booting it. So, your mileage may vary.)

The next release will be 384.3, which will provide support for:

RT-AC68U (and all its variants)
RT-AC88U
RT-AC3100
RT-AC86U
RT-AC3200 (will be based on binary blobs from 382_19466 but running 384_10007 GPL code, unless issues appear during development, in which case a separate 382.x release will be made for that model).

First and foremost, thank you RMerlin to bring us wonderful updates for Asus routers.

I just noticed that 382.2-Beta3 updated on RT-AC68U seems to remove USB Application-Downloader, but the release note/changelog doesn't mention that, if it is intentional behaviour.

 

[Odkrys]

I installed 384.3 alpha1 on my RT-AC86U.
To enable telnet, I need to press the apply button twice on the web ui. lol
SSH is working properly.

 

[RMerlin]

I installed 384.3 alpha1 on my RT-AC86U.
To enable telnet, I need to press the apply button twice on the web ui. lol
SSH is working properly.

Maybe Asus added that - they used to have something similar back in the day when someone wanted to increase the wireless output power, requiring multiple clicks to "unlock" it. Especially since nobody should be using telnet anymore, for obvious security reasons - SSH is just as easy to use. Microsoft even added an OpenSSH client in the latest Windows 10 release.

Anyway, I haven't analyzed the details of what was changed on that page.

 

[RMerlin]

Started a new preview thread for 384.3 discussions:

https://www.snbforums.com/threads/preview-asuswrt-merlin-384-3-pre-release-test-builds.44060/

 

[RussellInCincinnati]

Ah, I see, a consequence of the mesh architecture itself. Speaking strictly for myself, I do not care if you remove the AiMesh stuff from the firmware. If I was to use such a thing I probably would buy a kit of devices, Google WiFi or Asus Lyra. But that's just me.

Without ignoring the interesting mesh possibilities, am also not wanting Merlin to spend time on trying to make AiMerlsh. Unless Merlin tells us of some compelling fascinating reason to want to work on it, in the future.

 

[JJQuin]

Installed the official 382.2_beta3 on my RT-AC86U, works great! I've got QoS working and AB-Solution/Skynet both installed with no issues. I had a minor upload speed problem with PIA VPN on wireless, but PIA tech support gave me a new custom config that fixed the issue.

https://www.snbforums.com/threads/a...eds-but-only-over-wireless.42062/#post-373853

I still have the minor issue where client devices won't remember their name or icon. I change it, click apply and it goes back to what it was set with before. Only happens with a few clients, but it's random after each reset I've done different clients did this. Again it's a really minor issue. After all the testing and reconfiguring I've done, I've practically got my client devices memorized!

Looking forward to 384.3. Thanks for all the hardwork RMerlin, you're awesome!

 

[PDinDetroit]

RT-AC3200 running 382.3_alpha2-g92b6c01

With DNS Filtering ON and configured for Comodo, Android Phones and Tablets running 7.x could not update apps already downloaded from the Play Store. Turned DNS Filtering OFF and updates downloaded and installed. Put DNS Filtering ON and configured for OpenDNS Home, updates downloaded and installed.

 

[Eric Lieb]

Only thing I can say about the 384 from Asus is there seems to be an instability issue with AC68... My ping times sometimes go from 4 ms to 100+ ms on my fiber connection and sometimes i lost internet on connected devices.

 

[bluepoint]

Only thing I can say about the 384 from Asus is there seems to be an instability issue with AC68... My ping times sometimes go from 4 ms to 100+ ms on my fiber connection and sometimes i lost internet on connected devices.

Not my experience. Ping is consistent 4-6ms and the 5GHz band has stronger signal to the farthest corner of the house.

 

[HeadBanger]

RT-AC68U 382.3A. I’m still getting traffic slowdown when dealing with a modest load or more. Only a reboot temporarily cures it.

Is this a known issue with 382? Is it fixed in 384?

HB

 

[Gregory Phillips]

I briefly tried 382.2_beta3 but it caused an issue with IPv6 so I rolled back to beta_2 which works fine.