[Release] Asuswrt-Merlin 384.14 (and 384.13_2) are now available

[MDM]

All the new builds support an identifier so developers can tell if the current firmware version supports the new addon API (along with the other WebUI changes that weren't previously available for these two models).

https://github.com/RMerl/asuswrt-merlin.ng/commits/384.13_x

Was to lazy to search and read trough GitHub...

 

[MDM]

OK, just updated to 384.13_3-g99be446b9e, all seems working fine.

P.S.
This is new (fixed), wasn't there on 13.2

 

[grifo]

OK, just updated to 384.13_3-g99be446b9e, all seems working fine.

Same here. Obviously Skynet web stats aren't working yet as it hasn't been updated to support 348.13_3 yet but that won't take Adam long.

Anyways I guess this is OT here, I should have better posted on the 384.15 alpha thread earlier.

 

[Adamm]

Same here. Obviously Skynet web stats aren't working yet as it hasn't been updated to support 348.13_3 yet but that won't take Adam long.

https://www.snbforums.com/threads/r...urity-enhancements.16798/page-293#post-541509

 

[grifo]

https://www.snbforums.com/threads/r...urity-enhancements.16798/page-293#post-541509

Just updated, it looks great!!

 

[RMerlin]

The Github changelog file is incorrect, this is still 384.13, not 384.14. I just wanted to have feature parity for the new addons implementation, as it's starting to look like I might have to drop support for these two models soon, since binary blobs from 382 are no longer compatible with my 384 code, and I'm unable to obtain updated blobs from Asus.

 

[MDM]

That's a pity, but nothing you can do about it unless Asus goes to 384 with them (probably unlikely so?).
But I do find it bizarre that an RT-AC68U do have 384 and even 385, generation wise...

 

[grifo]

The Github changelog file is incorrect, this is still 384.13, not 384.14. I just wanted to have feature parity for the new addons implementation, as it's starting to look like I might have to drop support for these two models soon, since binary blobs from 382 are no longer compatible with my 384 code, and I'm unable to obtain updated blobs from Asus.

Not so good news then. Have Asus confirmed they won't provide them or is it just a matter of this being low priority for them but they will eventually do it?

From the outside it would look like the latter as they're still providing updates for the stock firmware but they're taking ages even to publish the corresponding GPL on their site, they still haven't done that for the November update. If that's the case there is hope still.

On the other hand if they refuse to do it then who is going to buy their hardware that isn't as plain as vanilla moving forward, anything with multi vendor chipsets or odd architectures so they can support new features, people will be wary to touch them fearing they will have a short support span.

When the AC87U came out a lot of people bought them when they could have gotten a plainer, cheaper AC68U exactly because it was the latest hardware with the best features and presumably longer support being it a newer product.

 

[htismaqe]

Not so good news then. Have Asus confirmed they won't provide them or is it just a matter of this being low priority for them but they will eventually do it?

From the outside it would look like the latter as they're still providing updates for the stock firmware but they're taking ages even to publish the corresponding GPL on their site, they still haven't done that for the November update. If that's the case there is hope still.

On the other hand if they refuse to do it then who is going to buy their hardware that isn't as plain as vanilla moving forward, anything with multi vendor chipsets or odd architectures so they can support new features, people will be wary to touch them fearing they will have a short support span.

When the AC87U came out a lot of people bought them when they could have gotten a plainer, cheaper AC68U exactly because it was the latest hardware with the best features and presumably longer support being it a newer product.

They're basically just behaving like their competition. I've been through Linksys and Netgear in the recent past and their ongoing FW support is just as bad, if not worse. Plan on about 4 updates, once a quarter, and then they're done unless some earth-shattering vulnerability comes out that could lead to them being financially liable for damages.

 

[grifo]

They're basically just behaving like their competition. I've been through Linksys and Netgear in the recent past and their ongoing FW support is just as bad, if not worse. Plan on about 4 updates, once a quarter, and then they're done unless some earth-shattering vulnerability comes out that could lead to them being financially liable for damages.

Asus are still supporting the AC68U which is older than the AC87U so it isn't a case of them only offering a few product updates, in fact they're still supporting the AC87U also, the last stock firmware update came out on 11-20-19 and there likely will be more coming.

The only problem is they aren't giving RMerlin the blobs he needs to keep the support going from his end. Once Asus have made the effort to update the stock FW it shouldn't be too difficult to do that, unless it isn't technically feasible but my feeling is it's more a case of it being a low priority for them so it gets pushed at the bottom of the pile.

Which isn't nice towards RMerlin either (who's helping them selling routers in a pretty substantial way at this point) as he has to keep finding workarounds to continue supporting these routers.

 

[Asad Ali]

in fact they're still supporting the AC87U also, the last stock firmware update came out on 11-20-19 and there likely will be more coming.

The only problem is they aren't giving RMerlin the blobs he needs to keep the support going from his end. Once Asus has made the effort to update the stock FW it shouldn't be too difficult to do that, unless it isn't technically feasible but my feeling is it's more a case of it being a low priority for them so it gets pushed at the bottom of the pile.

The issue is Asus is still pushing updates for 87U on 382 branch which RMerlin stopped development on ages ago, till now Asus specifically compiled Blobs for RMerlin for 384 branch but that's something Asus is not doing now (or getting so lazy to do it because it's extra work for them) so new firmware updates from Asus is not important for RMerlin to work, what's important is if Asus also shifts its codebase to 384/385 like all the other supported models.

 

[RMerlin]

Not so good news then. Have Asus confirmed they won't provide them or is it just a matter of this being low priority for them but they will eventually do it?

The engineer who provided them in the past is simply unavailable these days, too busy with work.

They're basically just behaving like their competition. I've been through Linksys and Netgear in the recent past and their ongoing FW support is just as bad, if not worse. Plan on about 4 updates, once a quarter, and then they're done unless some earth-shattering vulnerability comes out that could lead to them being financially liable for damages.

The RT-AC87U and RT-AC3200 are roughly 5 years old now, and Asus still releases multiple security updates every year, so I'm not sure what you are complaining about there. Both models probably received well over 15-20 updates in total, which is way more than 4. And the RT-AC87U last received an update only two months ago, in November. Netgear's R7500 was their equivalent model (Quantenna-based) released by Netgear a few months after the RT-AC87U. And their last firmware release for that model was from June 2018 - 18 months ago. So once again, I don't see what's the problem here with Asus's support - they still are supporting it.

The fact that these models are based on a separate code base only affects me, not their regular customers. The 382 code base is used for non-AiMesh models, and these two can't support AiMesh due to technical limitations of their design.

 

[htismaqe]

The RT-AC87U and RT-AC3200 are roughly 5 years old now, and Asus still releases multiple security updates every year, so I'm not sure what you are complaining about there. Both models probably received well over 15-20 updates in total, which is way more than 4. And the RT-AC87U last received an update only two months ago, in November. Netgear's R7500 was their equivalent model (Quantenna-based) released by Netgear a few months after the RT-AC87U. And their last firmware release for that model was from June 2018 - 18 months ago. So once again, I don't see what's the problem here with Asus's support - they still are supporting it.

The fact that these models are based on a separate code base only affects me, not their regular customers. The 382 code base is used for non-AiMesh models, and these two can't support AiMesh due to technical limitations of their design.

It was a poor choice of words on my part, not a complaint. I should have said "IF" Asus started trending towards shorter support windows, they'd be more like their counterparts. Sorry for the confusion created. I wasn't complaining about Asus at all, quite the opposite actually.

 

[MDM]

The 382 code base is used for non-AiMesh models.

Ah, I see, low hope then on them getting to 384/385...
Lets pray for the engineer to be less busy

 

[RMerlin]

Ah, I see, low hope then on them getting to 384/385...
Lets pray for the engineer to be less busy

No idea what their plan is once they move things to the 386 code base.

 

[AntonK]

Does anyone know what this dnsmasq nonsense is all about?

Jan 14 21:35:18 dnsmasq-dhcp[335]: DHCPREQUEST(br0) 192.168.1.80 d8:9c:67:2e:f0:da
Jan 14 21:35:18 dnsmasq-dhcp[335]: DHCPACK(br0) 192.168.1.80 d8:9c:67:2e:f0:da
Jan 15 01:47:38 dnsmasq-dhcp[335]: DHCPREQUEST(br0) 192.168.1.143 4c:17:44:08:2b:ab
Jan 15 01:47:38 dnsmasq-dhcp[335]: DHCPACK(br0) 192.168.1.143 4c:17:44:08:2b:ab
Jan 15 05:05:37 dnsmasq-dhcp[335]: DHCPREQUEST(br0) 192.168.1.252 24:5b:a7:28:07:da
Jan 15 05:05:37 dnsmasq-dhcp[335]: DHCPACK(br0) 192.168.1.252 24:5b:a7:28:07:da
Jan 15 07:17:44 dnsmasq[335]: Insecure DS reply received for us-east-1.elb.amazonaws.com, could be bad domain configuration or lack of DNSSEC support from upstream DNS servers
Jan 15 07:58:55 syslog: WLCEVENTD wlceventd_proc_event(401): eth2: Disassoc 24:5B:A7:28:07A, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Jan 15 08:49:03 dnsmasq-dhcp[335]: DHCPREQUEST(br0) 192.168.1.80 d8:9c:67:2e:f0:da
Jan 15 08:49:03 dnsmasq-dhcp[335]: DHCPACK(br0) 192.168.1.80 d8:9c:67:2e:f0:da
Jan 15 13:47:38 dnsmasq-dhcp[335]: DHCPREQUEST(br0) 192.168.1.143 4c:17:44:08:2b:ab
Jan 15 13:47:38 dnsmasq-dhcp[335]: DHCPACK(br0) 192.168.1.143 4c:17:44:08:2b:ab amazon-acd112398
Jan 15 17:12:51 syslog: WLCEVENTD wlceventd_proc_event(420): eth2: Auth 24:5B:A7:28:07A, status: 0, reason: d11 RC reserved (0)
Jan 15 17:12:51 syslog: WLCEVENTD wlceventd_proc_event(449): eth2: Assoc 24:5B:A7:28:07A, status: 0, reason: d11 RC reserved (0)
Jan 15 17:12:51 dnsmasq-dhcp[335]: DHCPREQUEST(br0) 192.168.1.252 24:5b:a7:28:07:da
Jan 15 17:12:51 dnsmasq-dhcp[335]: DHCPACK(br0) 192.168.1.252 24:5b:a7:28:07:da
Jan 15 17:15:35 syslog: WLCEVENTD wlceventd_proc_event(401): eth2: Disassoc 24:5B:A7:28:07A, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Jan 15 17:15:38 syslog: WLCEVENTD wlceventd_proc_event(420): eth2: Auth 24:5B:A7:28:07A, status: 0, reason: d11 RC reserved (0)
Jan 15 17:15:38 syslog: WLCEVENTD wlceventd_proc_event(449): eth2: Assoc 24:5B:A7:28:07A, status: 0, reason: d11 RC reserved (0)
Jan 15 17:15:38 dnsmasq-dhcp[335]: DHCPREQUEST(br0) 192.168.1.252 24:5b:a7:28:07:da
Jan 15 17:15:38 dnsmasq-dhcp[335]: DHCPACK(br0) 192.168.1.252 24:5b:a7:28:07:da
Jan 15 17:21:59 dnsmasq-dhcp[335]: DHCPREQUEST(br0) 192.168.1.134 14:b3:1f:07:61:f6
Jan 15 17:21:59 dnsmasq-dhcp[335]: DHCPACK(br0) 192.168.1.134 14:b3:1f:07:61:f6

Thanks,
Anton

 

[Asad Ali]

Does anyone know what this dnsmasq nonsense is all about

It's the DNSMasq's DHCP request and acknowledge entries for your devices. Go to router settings LAN/DHCP Server and set Hide DHCP/RA queries = Yes - if you don't want to see the flooding.

 

[AntonK]

It's the DNSMasq's DHCP request and acknowledge entries for your devices. Go to router settings LAN/DHCP Server and set Hide DHCP/RA queries = Yes - if you don't want to see the flooding.

Thank you! Appreciated...
Anton

 

[Eric Lieb]

Having an issue with DDNS and Let's Encrypt. It seems to be stuck in "status" Authorizing and SAN undefined.

I am using a no-ip.org ddns.

 

[skeal]

Having an issue with DDNS and Let's Encrypt. It seems to be stuck in "status" Authorizing and SAN undefined.

I am using a no-ip.org ddns.

Enable https access to the router use both in the webui. Do not expose webui to WAN by doing so though.