What's new

Beta Asuswrt-Merlin 386.1 Beta is now available

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Status
Not open for further replies.
A more important question would be: why would it matter? The CPU can run up to 100C before it starts throttling. That is well within safety margins.

Asus has occasionally done changes to power management to handle low-level issues over the years. They might have made such a change in recent GPLs perhaps.

Hi Merlin,
it could matter if we think about the CPU health, a stable higher temperature could shorten the lifetime of the CPU.

However I understand that it could be a choice of Asus to handle issues as you told me. Later I'll surely try again the 386.1 beta 3, deleting the /jffs/.sys/TrafficAnalyzer/TrafficAnalyzer.db to see if that solves the problem of the statistics.

Thank you very much.

Bye.
 
OK, just checked. WAN DNS is set to 8.8.8.8 with fallback of 8.8.4.4. I definitely did a full reset recently, and set it up from scratch before moving back you the beta 3 version. In terms of MTU value, I'm set up for IP, and the value is not shown in the WAN menu with that option. When I switch to PPOE, it shows correctly as 1492. I have no VPN set up. Is there another place I should be looking for MTU when I'm set to IP?

The repeated symptoms (I've now done this three times) is that when I move to beta 3, wifi and LAN are fine, but internet connectivity stops operating, even though the router says it is connected to the Internet.

OK. Found the issue.

In the stock firmware from assus, there is not MTU setting in IP mode for WAN. Nonetheless, everything worked fine.

When I changed to beta 3, there is an MTU field in IP mode toward the bottom of the WAN tab. That was indeed blank. I changed it to 1500 and everything works again.

Any ideas why what was likely an implicit default in the stock was not showing up in the explicit MTU field in the beta?
 
Did you check the MTU on the WAN page after the upgrade? Set it for 1500, mine was blank after the upgrade. I also always restart the cable modem after a firmware upgrade.

Yup. That was the problem. My MTU value (which did not show up in stock when set in IP mode) was indeed blank in the beta version. So odd, but thanks for the hint.
 
Flashed beta 3 on my main ax88u and all 7 ac68u aimesh nodes, everything working perfekt. Thanks
 
Any ideas why what was likely an implicit default in the stock was not showing up in the explicit MTU field in the beta?

Asus started work on adding that MTU setting on their firmware, but it seems they haven't finished it yet. When moving to my firmware (which already had support for it), the router incorrectly ends up with no MTU value at all, which doesn't get properly handled. I changed the default value to 1500 in beta 1 (which is why alpha users must either fix it or do a factory default reset), however it's possible that the MTU configuration code I merged from Asus doesn't properly deal with blank values that get inherited when moving from one of their beta firmware (or my alpha firmware) with the issue.

So, looks like the issue can also be introduced by running their beta firmware, and then switching to my firmware without doing a factory default reset.

I'll see if I can make the router use a more sensible value of 1500 if that value is completely blank.
 
Been using this for years.....Merlin gave the hint :)
Thanks @john9527 and @RMerlin , great thread. Since we are sticky averse, the above thread is in my browsers Bookmarks.
 
Asus started work on adding that MTU setting on their firmware, but it seems they haven't finished it yet. When moving to my firmware (which already had support for it), the router incorrectly ends up with no MTU value at all, which doesn't get properly handled. I changed the default value to 1500 in beta 1 (which is why alpha users must either fix it or do a factory default reset), however it's possible that the MTU configuration code I merged from Asus doesn't properly deal with blank values that get inherited when moving from one of their beta firmware (or my alpha firmware) with the issue.

So, looks like the issue can also be introduced by running their beta firmware, and then switching to my firmware without doing a factory default reset.

I'll see if I can make the router use a more sensible value of 1500 if that value is completely blank.

Thanks. Just to be clear, when I moved to their non-beta 386 version of the firmware for the AX88u, I did do a factory reset. Then when I moved back to the beta 3, I encountered the issue, which went away again when I went back to the stock firmware. I repeated the cycle 3-4 times.

I did not, however, move from the ASUS stock firmware to the beta and then do a new factory reset.
 
Dirty flashed from beta 2 to beta 3. At first, I didn't notice any difference at all, but then I saw that TENX had a great day on the NASDAQ, the fire in the fireplace was extra warm, and my glass of silver had turned to reposado, so yeah, this is a solid upgrade.

Thank you, RMerlin!
 
Dirty upgrade from Beta2 to 3. All working ok for everyone. Thanks @RMerlin for all your time & energy on this project!!
View attachment 28910


The marketing aim of AIMesh for ASUS was very obviously to sell more routers. And now some people have 6 routers in AiMesh config for a single house. Amazing - ASUS bean counters must be very happy
 
Last edited:
Updated to Beta 3, AX58U working fine no issues so far. As stated there is no speed test visible. CPU temp 49c. Same as always.
 
Last edited by a moderator:
Love the metaphor.
 
Is it only the RT-AC86U's that have seen a temp bump?
 
18 hours with Beta 3 on AX86U. Temps are 2.4 GHz: 50°C - 5 GHz: 53°C - CPU: 78°C with ambient temps of 27-32C now. Still having rolling kernal alarms when scribe installed (disappears when uninstalled):
kernel: _blog_emit, blogp = 0x6
kernel: _blog_emit, blogp = 0x4
kernel: _blog_emit, blogp = 0x2240
kernel: _blog_emit, blogp = 0x1a68
kernel: _blog_emit, blogp = 0x2

Will ignore the LE stuck at Authorizing as suggested by Merlin.
 
Is it only the RT-AC86U's that have seen a temp bump?

FWIW my AC86U has not experienced a significant bump in temp.

I have an audiable notification set up in HA when the temp hits 77C, and it has - but it doesn't seem to be a long term thing that the fan cannot easily mitigate.

Dunno if this helps, but I am happy to provide any relevant historical data.
 
Beta 3 Issue - Guest WiFi not connecting to Internet when VPN client is running.

Steps:
1. Connect client to Guest WiFi. VPN client running.
2. Guest WiFi not connecting to Internet. Regular WiFi connecting.
3. Set VPN client Service State to "off". Guest WiFi and regular WiFi connecting to Internet.
4. Set VPN client Service State to "on". Guest WiFi not connecting to Internet. Regular WiFi connecting.
5. Set VPN client Service State to "off". Guest WiFi and regular WiFi connecting to Internet.

Router is RT-AC86U.
Hard factory reset done and settings entered from scratch.
Connection to Internet tested by streaming using ABC iView app and YouTube app.
Devices tested were Apple iPhone and Android mobile.
Devices connected to Guest WiFi never disconnected during testing.
No errors or unexpected messages seen in system log.
VPN client public Internet address checked as a VPN Server address.
Issue observed on 386.1 Beta 1, 3 & 3. Not seen on 384.19
 
Updated from Beta2 to Beta3...…..running for few hours and so far so good on both units. Thanks @RMerlin
 
Status
Not open for further replies.

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top