[Beta] Asuswrt-Merlin 384.7 Beta is now available

[JohnSmith]

AC3100 upgrade to beta1 over alpha3, and everything is working as expected.

 

[john9527]

Umm, yes i know that? ..did you understand my question?

c31367024 Merge binary blobs from 384_21140 for RT-AC3100 and RT-AC5300

 

[RMerlin]

GPL source code 384.21152 for ac5300 is not posted by Asus...so which ac5300 GPL is it?

The source code is not model-specific. The 384.7 code is based on 384_21152, and I build all models off the same source code. Only the pre-compiled binary blobs are model-specific.

 

[RMerlin]

It's still update every 30 seconds.

Works for me. Make sure you aren't interfering with the nvram settings through a custom script, and also enable ddns_debug mode.

 

[fearz]

The source code is not model-specific. The 384.7 code is based on 384_21152, and I build all models off the same source code. Only the pre-compiled binary blobs are model-specific.

Thanks, just to be a more bit-specific, i cant find gpl sc 21152 either for ac5300, i can only find 21140, also to add, gpl sc for ac5300 released 32738, why arent you merging that?

Thanks

 

[RMerlin]

Thanks, just to be a more bit-specific, i cant find gpl sc 21152 either for ac5300, i can only find 21140

As I said, GPL source code is not model-specific. I use the same 21152 code from the RT-AC68U GPL to build all models. I don't need a 21152 GPL to compile other models, their older binary blobs are still compatible with it (except for the AC3200 and AC56U, which are too old and not compatible).

lso to add, gpl sc for ac5300 released 32738, why arent you merging that?

Because Asus released it near the end of the 384.7 development cycle. Merging it would mean scrapping 2-3 weeks of work done on the 21xxx source code, adding another 3-4 weeks of development time, and by then Asus would probably have another newer release available, which would mean having to restart all over again... Once I lock a release onto a specific GPL release, I don't merge newer GPLs until the next release cycle, especially not one with such major changes as the 32xxx code vs 21xxx.

Another reason was that the RT-AC87U binary blobs are no longer compatible with the 32xxx code, which would have mean another 3-5 months with no compatible builds for that model.

 

[fearz]

As I said, GPL source code is not model-specific. I use the same 21152 code from the RT-AC68U GPL to build all models. I don't need a 21152 GPL to compile other models, their older binary blobs are still compatible with it (except for the AC3200 and AC56U, which are too old and not compatible).



Because Asus released it near the end of the 384.7 development cycle. Merging it would mean scrapping 2-3 weeks of work done on the 21xxx source code, adding another 3-4 weeks of development time, and by then Asus would probably have another newer release available, which would mean having to restart all over again... Once I lock a release onto a specific GPL release, I don't merge newer GPLs until the next release cycle, especially not one with such major changes as the 32xxx code vs 21xxx.

Another reason was that the RT-AC87U binary blobs are no longer compatible with the 32xxx code, which would have mean another 3-5 months with no compatible builds for that model.

Thank you

 

[octopus]

Works for me. Make sure you aren't interfering with the nvram settings through a custom script, and also enable ddns_debug mode.

I have run it in debug mode and found this message:
Cannot find your DNS name in the list of API keys

After alot of tesing it seems to work if I use password and not ddns-key.
And use username rather then emailadress. (update helptext in gui to reflect this?)

Sep 17 12:27:00 start_ddns: update FREEDNS.AFRAID.ORG default@freedns.afraid.org, wan_unit 0
Sep 17 12:27:00 inadyn[7296]: In-a-dyn version 2.4 -- Dynamic DNS update client.
Sep 17 12:27:00 inadyn[7296]: Resolving hostname octopus.xxxxxx.se => IP# xxx.174.113.xxx
Sep 17 12:27:00 inadyn[7296]: No IP# change detected for default@freedns.afraid.org, still at 158.174.113.100
Sep 17 12:27:00 inadyn[7296]: Update forced for alias octopus.xxxxxxx.se, new IP# xxx.174.113.xxx
Sep 17 12:27:00 inadyn[7296]: Sending IP# update to DDNS server, connecting to freedns.afraid.org([50.23.197.94]:443)
Sep 17 12:27:00 inadyn[7296]: Sending IP# update to DDNS server, initiating HTTPS ...
Sep 17 12:27:02 inadyn[7296]: SSL connection using ECDHE-RSA-AES128-GCM-SHA256
Sep 17 12:27:02 inadyn[7296]: SSL server cert subject: /OU=Domain Control Validated/OU=EssentialSSL/CN=freedns.afraid.org
Sep 17 12:27:02 inadyn[7296]: SSL server cert issuer: /C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
Sep 17 12:27:02 inadyn[7296]: Fetching account API key, connecting to freedns.afraid.org([50.23.197.94]:443)
Sep 17 12:27:02 inadyn[7296]: Fetching account API key, initiating HTTPS ...
Sep 17 12:27:03 inadyn[7296]: SSL connection using ECDHE-RSA-AES128-GCM-SHA256
Sep 17 12:27:03 inadyn[7296]: SSL server cert subject: /OU=Domain Control Validated/OU=EssentialSSL/CN=freedns.afraid.org
Sep 17 12:27:03 inadyn[7296]: SSL server cert issuer: /C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
Sep 17 12:27:03 inadyn[7296]: Successful alias table update for octopus.xxxxxx.se => new IP# xxx.174.113.xxx
Sep 17 12:27:03 inadyn[7296]: Updating cache for octopus.xxxxxx.se

 

[joro_abv]

Literally the post above - it's down to Asus to post the GPLs, Merlin can't possibly comment on Asus' development strategy/release schedule.

Not really - my question was are there any signs that Asus would stop posting further versions for AC56. Of course, Merlin can not know what are the exact Asus plans, yet - he has much more information than me (and probably you), so I'd gladly take some speculation from his side on the matter.

 

[RAH-66]

Not really - my question was are there any signs that Asus would stop posting further versions for AC56.

AC56U present in EOL https://www.asus.com/event/network/EOL-product/

 

[joro_abv]

AC56U present in EOL https://www.asus.com/event/network/EOL-product/

Thanks.

 

[Bobbulf]

Having problem accessing mail on iPhone with iPhone´s mail app. ios11.4.1. Never had any problem with that before. Upgraded to 384,7 from 384.5, erased all with initialize command in router-meny, and configured settings manually (only had settings for wifi password, so nothing else changed from default).
When opening mail-app, it tells looking for mail for a long time, then gives error for connection to mail. Tried gmails own app, and it connects at once.
When disabling wifi on iPhone, apples mail app connects at once using 4G, and also Gmails own app. So something is wrong with connection/authentication or perhaps a security setting? Hopefully it would be fixed with ios 12 coming later today if its related to an error in Aplles way of handling the connection, but thought I would report the issue here if it is something that could influence other apps also perhaps.
Edit: I now see there i same problem accessing mail through Thunderbird on my windows PC. It never gets in contact with the mailserver when I open Thunderbird, no errors, just stops to look for mailafter a while. Still get my mails via 4G on iPhone.
Must be something related to the router upgrade then. Is there any new settings that have to be changed to make it work as before?

Edit 2: I restarted router and everything is normal now Sorry for the disturbance

 

[TheOldMan]

I've upgraded my rt-ac86u since 384.6 and the dirty upgrades worked flawlessly. Impressive without resetting? .7 a1,2,3 and now b1. Also no resets since 384.5 as well. Nice router, I must say.

 

[M@rco]

Nice router, I must say.

Nice firmware, I must say as well

 

[telUK]

I've upgraded my rt-ac86u since 384.6 and the dirty upgrades worked flawlessly. Impressive without resetting? .7 a1,2,3 and now b1. Also no resets since 384.5 as well. Nice router, I must say.

I like to reset every couple of updates.

I may have asked this before but is there any need to use the manual method of holding wps button down/ power on button vs the initialisation tab in the GUI to reset the router fully?

 

[M@rco]

I may have asked this before but is there any need to use the manual method of holding wps button down/ power on button vs the initialisation tab in the GUI to reset the router fully?

All you ever wanted to know about factory reset: https://www.snbforums.com/threads/faq-nvram-and-factory-default-reset.22822/

and the more recently introduced option to Initialize: https://www.snbforums.com/threads/rt-ac86u-administration-restore-vs-initialize.41944/

Edit: Maybe @RMerlin can edit the FAQ in the first link with some info regarding the Initialize procedure?

 

[JIPG]

As I said, GPL source code is not model-specific. I use the same 21152 code from the RT-AC68U GPL to build all models. I don't need a 21152 GPL to compile other models, their older binary blobs are still compatible with it (except for the AC3200 and AC56U, which are too old and not compatible).



Because Asus released it near the end of the 384.7 development cycle. Merging it would mean scrapping 2-3 weeks of work done on the 21xxx source code, adding another 3-4 weeks of development time, and by then Asus would probably have another newer release available, which would mean having to restart all over again... Once I lock a release onto a specific GPL release, I don't merge newer GPLs until the next release cycle, especially not one with such major changes as the 32xxx code vs 21xxx.

Another reason was that the RT-AC87U binary blobs are no longer compatible with the 32xxx code, which would have mean another 3-5 months with no compatible builds for that model.

Out of curiosity, do you know how dangerous are the vulnerabilities solved in the last fw 384.32738?:

Security fixes.
- Fixed Reflected XSS vulnerability.
- Fixed CSRF vulnerability.
- Fixed command injection vulnerability.
- Fixed stack buffer overflow vulnerability.
Thanks for Rick Ramgattie contribution.

I am getting a little bit paranoic with the Ai Protection log, stating these last days that I am having more than 40 attacks a day... (the ones solved by Ai protection, the others, who knows ...)

 

[RMerlin]

AC56U present in EOL https://www.asus.com/event/network/EOL-product/

In that case unless Asus decides to keep issuing firmware updates (unlikely based on what's written at the top of that page) then it also means 384.6 will probably be the end of the road for my firmware on that model as well. Too much closed source components, they break backward compatibility every few firmware releases.

I've upgraded my rt-ac86u since 384.6 and the dirty upgrades worked flawlessly. Impressive without resetting? .7 a1,2,3 and now b1. Also no resets since 384.5 as well. Nice router, I must say.

I can't remember when was the last time I resetted my primary router (an RT-AC88U).

Out of curiosity, do you know how dangerous are the vulnerabilities solved in the last fw 384.32738?:

I don't have any additional information to share about any of these, sorry. Based on their vague descriptions, I'd suspect they're all only exploitable LAN-side, or if you still persist in opening your router's webui to the WAN despite numerous warnings not to, so personally, I'm not losing any sleep over any of these issues.

 

[RAH-66]

I suspect they're all only exploitable LAN-side, or if you still persist in opening your router's webui to the WAN despite numerous warnings not to, so personally, I'm not losing any sleep over any of these issues.

Is it safe to use AiCloud on RT-AC87U?

 

[RMerlin]

Is it safe to use AiCloud on RT-AC87U?

No idea. To be honest, I haven't trusted AiCloud in quite a long time. Too much is closed source, and I don't trust such a cloud-centric product unless developed by a company that focuses on that type of products. In Asus's case, AiCloud seem to be an on-the-side, developed by a separate team than their core firmware devs.

I use a VPN to remotely access my content.