[Release] Asuswrt-Merlin 384.13 is now available

[MDM]

I don't know yet if it will be permanent or not. These two models are still on 382 code, and the GPL releases are too different from the 384 code to be compatible any longer, so it means each time I need to have Asus provide me with special binary blobs for these two models. I can no longer use the available GPL drops for these two models. Getting these binary blobs depends on the 384 code being compilable for these two models, as well as to the engineer building these to have the time to actually compile these components for me (which he currently doesn't).

Thanks for the detailed answer!
Then lets hope for Asus, to move them to the 384 code. Fingers crossed...

 

[Zastoff]

384.13_2-g9239ffaa0d on RT-ac87u working well here (over 7 hours now)
Got this in syslog

From Startup after flashing firmware
Dec  6 09:02:58 start_ddns: update WWW.ASUS.COM update@asus.com, wan_unit 0
Dec  6 09:02:58 inadyn[1090]: In-a-dyn version 2.5 -- Dynamic DNS update client.
Dec  6 09:02:58 inadyn[1090]: Update forced for alias xxxxxx.asuscomm.com, new IP# xx.xxx.xx.xx
Dec  6 09:03:01 inadyn[1090]: Certificate verification error:num=10:certificate has expired:depth=0:/CN=ns1.asuscomm.com
Dec  6 09:03:02 inadyn[1090]: Updating cache for xxxxxx.asuscomm.com
Did a service restart_ddns
Dec  6 09:08:38 rc_service: service 6589:notify_rc restart_ddns
Dec  6 09:08:38 custom_script: Running /jffs/scripts/service-event (args: restart ddns)
Dec  6 09:08:38 start_ddns: update WWW.ASUS.COM update@asus.com, wan_unit 0
Dec  6 09:08:39 inadyn[6598]: In-a-dyn version 2.5 -- Dynamic DNS update client.
Dec  6 09:08:39 inadyn[6598]: Update forced for alias xxxxxx.asuscomm.com, new IP# xx.xxx.xx.xx
Dec  6 09:08:41 inadyn[6598]: Certificate verification error:num=10:certificate has expired:depth=0:/CN=ns1.asuscomm.com
Dec  6 09:08:42 inadyn[6598]: Updating cache for xxxxxx.asuscomm.com

Guess thats on Asus end.. But DDNS works.
Thanks RMerlin

Edit:
Did another service restart_ddns and this time, Certificate verification error did not happen.

Dec  6 16:24:31 rc_service: service 18127:notify_rc restart_ddns
Dec  6 16:24:31 custom_script: Running /jffs/scripts/service-event (args: restart ddns)
Dec  6 16:24:31 start_ddns: update WWW.ASUS.COM update@asus.com, wan_unit 0
Dec  6 16:24:31 inadyn[18134]: In-a-dyn version 2.5 -- Dynamic DNS update client.
Dec  6 16:24:31 inadyn[18134]: Update forced for alias xxxxxx.asuscomm.com, new IP# xx.xxx.xx.xx
Dec  6 16:24:33 inadyn[18134]: Updating cache for xxxxxx.asuscomm.com

 

[AndreiV]

AC3200 . 384.13_2-g9239ffaa0d 14 hours use today and having flashed the test file the router interface is now much faster , can't find any issues at all , everything is running perfectly .
My son asked what happened to the internet because all webpages are snapping open much faster, the difference is very noticeable on all our devices.
Merlin viagra for old routers?

 

[RMerlin]

Guess thats on Asus end.. But DDNS works.

Yes, after fixing their certificate a few weeks ago, they somehow reverted back to an expired certificate (at least on some of their servers, assuming they use a cluster). So I gave up on them, and told inadyn to not validate the certificate validity when using Asus DDNS.

My son asked what happened to the internet because all webpages are snapping open much faster, the difference is very noticeable on all our devices.

Just the reboot itself that must have helped, since the list of changes mostly consists of bug fixes.

 

[JIPG]

I don't know yet if it will be permanent or not. These two models are still on 382 code, and the GPL releases are too different from the 384 code to be compatible any longer, so it means each time I need to have Asus provide me with special binary blobs for these two models. I can no longer use the available GPL drops for these two models. Getting these binary blobs depends on the 384 code being compilable for these two models, as well as to the engineer building these to have the time to actually compile these components for me (which he currently doesn't).

Thank you for your big effort. You are our last hope!

In fact you have moved us (RT-AC87U and RT AC3200 users) to the 384 code (without Aimesh, but we bought the router without it, so no much problem here). I do not understand well why ASUS cannot do it as you have done. In this way, we could be having updates with the binary parts already compiled with the newest code and they should not have to maintain parallel lines ... (ASUS is still updating our routers, e.g. FW 3.0.0.4.382.51939, issued few days ago with some improvements/corrections they have also introduced for the other routers, so maybe for them should be even easier to have AC87U in the last code as the others to avoid duplicating the work ...).

Well, we will wait for ASUS ...

 

[JarleH]

Thank you for your big effort. You are our last hope!

In fact you have moved us (RT-AC87U and RT AC3200 users) to the 384 code (without Aimesh, but we bought the router without it, so no much problem here). I do not understand well why ASUS cannot do it as you have done. In this way, we could be having updates with the binary parts already compiled with the newest code and they should not have to maintain parallel lines ... (ASUS is still updating our routers, e.g. FW 3.0.0.4.382.51939, issued few days ago with some improvements/corrections they have also introduced for the other routers, so maybe for them should be even easier to have AC87U in the last code as the others to avoid duplicating the work ...).

Well, we will wait for ASUS ...

Asus wants you to buy a new router. They have to choose between good support and money, and money wins.

 

[JIPG]

Asus wants you to buy a new router. They have to choose between good support and money, and money wins.

Well, at least they are still providing updates, so the support has not ended:

Versión 3.0.0.4.382.51939
2019/11/20

ASUS RT-AC87U Firmware version 3.0.0.4.382.51939
- Fixed Let's encrypt register issues.
- Fixed Network map client list issues.
- Fixed OpenVPN related bugs.
- Improved system stability.
- Fixed schedule reboot bugs.
- Fixed dual wan failover bugs while the primary wan type is L2TP.

By the way, RMerlin, are the last two items in the "non closed source" part, in such a way they could be "ported" to the RT-AC87U (and in the same way to AC3200) from the 384 branch?.
I would like to have a reliable scheduled reboot, as the memory used increases a lot with the time ...

I do not know if a glitch I have is related with this fact or not: After of some days after the last reboot, a couple of laptops connected by cable to the router (through a power line adapter) loose connection with internet (windows shows no internet), but disconnecting a reconnecting the ethernet plug at laptop side recovers immediately the internet connection.

No other solution is working to recover the connection, although sometimes, waiting some minutes it recovers the connection alone. Maybe a lost lease?. I am getting crazy about it ...

 

[MDM]

through a power line adapter

Probably the culprit (goes in sleep mode or...).

 

[grifo]

Asus wants you to buy a new router. They have to choose between good support and money, and money wins.

Good support equals money and hopefully Asus know that. These routers were sold brand new on Amazon until not long ago and the people who bought them will expect a reasonable support timeframe, Asus are providing updates for them and I'm sure they will also keep up giving RMerlin the binary blobs so he can keep supporting them as they know that RMerlin's firmware is the reason a lot of people are buying Asus routers rather than the best bang for the buck DD-WRT supported routers.

 

[JIPG]

Probably the culprit (goes in sleep mode or...).

Thank you for the suggestion.
In fact, it was the first thing I though, but no, all the adapters were working (I have an application to check them in real time ...).
To be honest, I have to check if I have connection to the router during these events, but it is curious that unplugging and plugging again the the ethernet connector recovers instantaneously the internet connection ...

 

[JIPG]

Good support equals money and hopefully Asus know that. These routers were sold brand new on Amazon until not long ago and the people who bought them will expect a reasonable support timeframe, Asus are providing updates for them and I'm sure they will also keep up giving RMerlin the binary blobs so he can keep supporting them as they know that RMerlin's firmware is the reason a lot of people are buying Asus routers rather than the best bang for the buck DD-WRT supported routers.

I totally agree. In fact, my last laptop and monitor are from ASUS as I trust in their support.

For example, I had two Tplink routers, and they had only two or three FW, not solving a problem I suffered although it was supposedly solved in the last FW.

 

[RMerlin]

By the way, RMerlin, are the last two items in the "non closed source" part, in such a way they could be "ported" to the RT-AC87U (and in the same way to AC3200) from the 384 branch?.

Routers based on the 382 code are running older code. Any fix you see appear in a 382 release has already been present (sometimes long ago) on the 384 code base.

 

[JIPG]

Routers based on the 382 code are running older code. Any fix you see appear in a 382 release has already been present (sometimes long ago) on the 384 code base.

These two I mentioned are new in many of the models last firmware:

- Fixed schedule reboot bugs.
- Fixed dual wan failover bugs while the primary wan type is L2TP.

Other common improvements in the last 382 FW:

- Fixed Let's encrypt register issues.
- Fixed Network map client list issues.
- Fixed OpenVPN related bugs.
- Improved system stability.

It seems that ASUS has corrected same bugs in many of the firmwares, including AC87U. I know some of them can be corrected in you last FW384.13_2 for testing, but others not.

This is why I think that ASUS should maintain AC87U in the same branch as other routers, been even more easy for then to introduce all these common changes.

 

[MDM]

unplugging and plugging again the the ethernet connector recovers instantaneously the internet connection ...

And that would "wake up" the connection - device...

 

[JIPG]

And that would "wake up" the connection - device...

I checked that it was "awake" before disconnecting the plug ....

 

[JarleH]

I have never tried out Diversion for adblocking. Is it ok to setup, and is it more or less selfupdating?
Can I use a USB stick drive as storage? If so, is this ok:
https://www.komplett.no/product/836...nnepenn-usb/kingston-datatraveler-se9-g2-16gb ?

 

[skeal]

This version 384.13 is awesome. I have it installed on an AC68U as an Access Point. My uptime is 70 days 6 hours 32 minute(s) 45 seconds, wireless log shows clients connected for hundreds of hours. How do you beat that!!! Great work @RMerlin very stable firmware!

 

[dave14305]

This version 384.13 is awesome. I have it installed on an AC68U as an Access Point. My uptime is 70 days 6 hours 32 minute(s) 45 seconds, wireless log shows clients connected for hundreds of hours. How do you beat that!!! Great work @RMerlin very stable firmware!

Hear, hear! I'm not exactly looking forward to the ASUS GPL that comes with 384.14. I've not read any feel-good posts about those stock versions. I'd love a 384.13_2 build like the 87U and 3200 got. I'm thinking there may not be anything stopping us from building our own off the 383.13_x branch for any non-AX88 model.

Either way, 384.13 is safe harbor for anyone having issues in the future. Remember the people worried that 384.13 would be bad luck before it was released? That curse went to iOS 13 instead.

 

[Makaveli]

Hear, hear! I'm not exactly looking forward to the ASUS GPL that comes with 384.14. I've not read any feel-good posts about those stock versions. I'd love a 384.13_2 build like the 87U and 3200 got. I'm thinking there may not be anything stopping us from building our own off the 383.13_x branch for any non-AX88 model.

Either way, 384.13 is safe harbor for anyone having issues in the future. Remember the people worried that 384.13 would be bad luck before it was released? That curse went to iOS 13 instead.

Agreed.

I'm at 87 days uptime on .13 in router mode its been solid.

 

[a5m]

Agreed.

I'm at 87 days uptime on .13 in router mode its been solid.

Nice. I had just hit 70 days and would've kept going but due to a horribly labeled circuit breaker box and having to install a Nest Hello had to power it off and on.