[Beta 384/NG] Asuswrt-Merlin 384.3 Beta is now available

[RMerlin]

I think I finally tracked down a bug that's been bothering me for weeks now - some router pages would fail to apply/activate settings changes (including the new password change on first run after a factory default reset). Issue was caused by the new config sync service used by AiMesh...

That bug was one of the reasons it took so long to get a first beta release out.

 

[M@rco]

I think I finally tracked down a bug that's been bothering me for weeks now - some router pages would fail to apply/activate settings changes (including the new password change on first run after a factory default reset).

Glad you worked it out. Could this issue affect starting QoS as well?

 

[GoNz0]

So far so good here. AC68u, one as router one as AP.

 

[Blackbat]

I have an issue with my AC68U, which I'm reasonably sure has been a problem for me since the first betas of 382. I run some internal websites on my NAS at home, and I can connect to these via my external static IP address from wired LAN connections (i.e. my desktop PC) but not via WiFi. To connect via WiFi I need to use the LAN address of the NAS. Trying to connect via the WAN address fails. I'm pretty certain this worked fine when I was running 380 (as long as NAT acceleration was disabled).

 

[king006]

I think I finally tracked down a bug that's been bothering me for weeks now - some router pages would fail to apply/activate settings changes (including the new password change on first run after a factory default reset). Issue was caused by the new config sync service used by AiMesh...

That bug was one of the reasons it took so long to get a first beta release out.

Could this be the problem with the guest network and WiFi channel changes? Thanks for the search!

Turn on the browser console and check for any errors when you press Apply.

No error messages are shown But the problem remains.

 

[bladehu2]

hi RMerlin,
I found a bug in 384.3 beta on my ac68u, which wasn't present in pevious 380.xx branches.
If the IGMP snooping is enabled on 5G wifi, the AC client's max connection speed is ~86Mbit (instead of 433) and the real transmission speed also decrease to cca 50Mbit (from normal ~240). 2.4G works fine with enabled igmp. Of course I did nvram clear after upgrade to 384 from 380.69, but the issue is still reproducible. Btw, in 382 was present this bug too.

 

[isr25]

I think I finally tracked down a bug that's been bothering me for weeks now - some router pages would fail to apply/activate settings changes (including the new password change on first run after a factory default reset). Issue was caused by the new config sync service used by AiMesh...

That bug was one of the reasons it took so long to get a first beta release out.

Is this the same issue where sometimes when I attempt to update the firmware, the router restarts, but the firmware is still not updated? AC86U here

 

[DonnyJohnny]

Is this the same issue where sometimes when I attempt to update the firmware, the router restarts, but the firmware is still not updated? AC86U here

Your case is likely due to insufficient memory.
Try do a restart of router before the flashing.
You can even do the following command after the reboot.
sync; echo 3 > /proc/sys/vm/drop_caches

 

[KnightRider]

Asuswrt-Merlin 384.3 Beta is now available for download.

This release merges Asus GPL 384_10007, and also introduces support for the RT-AC3200.

The highlights:

• Merge with GPL 384_10007 (note: AiMesh is NOT supported)
• Added RT-AC3200 support. Note that with both this firmware and Asus's official 382_xxxxx for this model, you will no longer be able to downgrade to a 380.xx release due to the CFE/nvram upgrade done by the 382/384 releases for this model. Also due to the nvram upgrade, the RT-AC3200 once again allows up to 5 OpenVPN clients.
• Stabilized RT-AC56U support (which was added in 382.2 beta).
• Updated Nano to 2.9.3. Also, you can no configure nano by editing /jffs/configs/nanorc .
• PPPoE NAT acceleration should now work for most models (fixes backported from 382_50010)
• Fixed security issue CVE-2018-5721 in httpd
• Various other fixes to networkmap, IPv6 and DHCP (see changelog for details)

Please keep discussions to this specific release.

Downloads are here.
Changelog is here.

With GPL 3.0.0.4.384.20308 out, is this in your roadmap for Beta2?

 

[Wutikorn]

With GPL 3.0.0.4.384.20308 out, is this in your roadmap for Beta2?

https://www.snbforums.com/threads/p...release-test-builds.44060/page-14#post-376318

 

[feranick]

profile.add is already supported.

Thanks. I wasn't aware of it, and I used .profile, rather. Sorry for the confusion, great seeing it included already.

 

[LostFreq]

@RMerlin
Some 25 pages in the webui contain a link to an FAQ-page at the Asus website. For example Advanced_DHCP_Content.asp. Or Advanced_VPN_OpenVPN.asp, which contains four such links. These links are constructed by calling the function httpApi.faqURL(). The idea is that it checks if a version of the FAQ page is available in the preferred language.

Unfortunately, that function (defined in js/httpApi.js) is implemented by making ajax-calls to the Asus website. The webui pages are at 192.168.1.1 and the Access-Control-Allow-Origin header from the Asus webserver does not allow such access, which results in errors in the browser console like these:

Firefox ESR 52 security warning:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://www.asus.com/support/FAQ/1000906.
(Reason: CORS header ‘Access-Control-Allow-Origin’ missing).

Internet Explorer 11 errors:
SEC7120: Origin http://192.168.1.1 not found in Access-Control-Allow-Origin header.
SCRIPT7002: XMLHttpRequest: Network Error 0x80070005, Access is denied.

So the current code makes a request to the Asus server, causes an error (because response.search("QAPage") is not allowed) and as a result the link always falls back to the English version.

In my opinion, it is undesirable that these requests to the Asus server are made, when accessing the router at a LAN address. I propose the following change, which removes the external request and makes the link default to the language preference:

In release/src/router/www/js/httpApi.js
remove lines 423 up to and including 438, except for line 434:

document.getElementById(_Objid).href = temp_URL_lang;

The only drawback is, that the link may be to an FAQ page that hasn't been translated to the local language yet. I've checked and found that the majority have been translated. But if you would rather always link to the English version, you could simply remove lines 423 up to and including 438, except for line 436 instead.

 

[RMerlin]

Glad you worked it out. Could this issue affect starting QoS as well?

Doubt it, since that issue only causes issues on webui changes, not on the boot process.

 

[RMerlin]

Could this be the problem with the guest network and WiFi channel changes? Thanks for the search!

It's tied to the Guest network failing to restart the wireless stack. No idea about Wifi channel changes, didn't investigate.

With GPL 3.0.0.4.384.20308 out, is this in your roadmap for Beta2?

No.

 

[routers]

I just got the RT-AC86U, HW Ver 1.5, FW Ver 382_15098.

I think I wanna run 384_20308 until 384.3 is released, but would it be wiser to run 384_10007 because 384.3 is based on that, or doesn't it matter?

I will Factory Reset before and after installing 384.3 Final.

 

[RMerlin]

In my opinion, it is undesirable that these requests to the Asus server are made, when accessing the router at a LAN address. I propose the following change, which removes the external request and makes the link default to the language preference:

Stock firmware doesn't suffer from this because they force you to be redirected to router.asus.com (something I disable by default, because I hate forced redirections.)

Disabling that new behaviour would be the easy way out. However I'd be tempted to see if it couldn't be modified to check if the current URL is an IP or a FQDN, and act accordingly.

 

[RMerlin]

I just got the RT-AC86U, HW Ver 1.5, FW Ver 382_15098.

I think I wanna run 384_20308 until 384.3 is released, but would it be wiser to run 384_10007 because 384.3 is based on that, or doesn't it matter?

I will Factory Reset before and after installing 384.3 Final.

Shouldn't matter, you can downgrade firmware versions if needed.

 

[Grigione]

Merlin,in next 384.3 beta release will be solved problem about guest networks?

 

[RMerlin]

Merlin,in next 384.3 beta release will be solved problem about guest networks?

Yes, that's what the second post in the thread says.

 

[LostFreq]

Stock firmware doesn't suffer from this because they force you to be redirected to router.asus.com (something I disable by default, because I hate forced redirections.) Disabling that new behaviour would be the easy way out.

Please keep it at the local IP address, I hate that router.asus.com thing too!

However I'd be tempted to see if it couldn't be modified to check if the current URL is an IP or a FQDN, and act accordingly.

Sure, in release/src/router/www/js/httpApi.js you could replace line 392:

-    var pLang = httpApi.nvramGet(["preferred_lang"]).preferred_lang;

+    var faqInfo = httpApi.nvramGet(["preferred_lang", "http_dut_redir"]);
+    var pLang = faqInfo.preferred_lang;

and then wrap the $.ajax-request like this:

if (faqInfo.http_dut_redir == "1") {
    // existing lines 423-438 here $.ajax({ ... });
} else {
    document.getElementById(_Objid).href = temp_URL_lang;
}

Untested, but that should do it I think.