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.
Back on 386 beta 3. Did a services-start script file to run "pwr config --wait on" and the CPU temp is holding at 83-84 C. Cooling fan on order...
The big question is why did Asus feel the need to deliberately disable these CPU wait states on this firmware (presumably with full knowledge of the effect on CPU temps). Odd.

Edit: Unless it is related to this (and perhaps why we are seeing higher temps even after re-enabling of the CPU wait states): https://www.snbforums.com/threads/asuswrt-merlin-386-1-beta-is-now-available.68205/post-638759
 
Last edited:
On 386.1 Beta 3 and RT-AC86U for most customers: temperatures haven't changed. 86C 'normal'. No fans needed. With many being in operation for a year or more.
 
On 386.1 Beta 3 and RT-AC86U for most customers: temperatures haven't changed. 86C 'normal'. No fans needed. With many being in operation for a year or more.
Err..well, if you define "normal" as within operating specification, OK, yes that is true. However, these RT-AC86U units are definitely running at least 6-12C (or more) higher than on previous firmware releases.

Edit: For those that are seeing temperatures in excess of 99-100C along with throttling, or intermittent display of only one CPU core reported as operating, I would venture to guess that the heaksink/thermal pad interface is in need or attention and/or renewal. Obviously, the problem here is whether doing so might void any remaining warranty claim possible through Asus or your retailer, so it is a bit of a gamble or tradeoff to evaluate whether it would be worthwhile doing so. If your warranty has definitely expired, the choice is simpler.
 
Last edited:
FWIW, Asus dropped an update to the Official Beta today... 12/31/2020 in the 'Official' forum section.
 
If you can be victim to a MitM attack within your own LAN, then you have a major problem already.

WPA2 is trivially easy to crack. ARP is easy to spoof. Absolutely nothing about this is difficult for someone in any nearby house (and I have lots of bored, house-bound kids within wifi range)

But that's not the real threat. We've seen malware installed from browser extensions play the spoofing game inside networks for years now.

Everyone picks their comfort level. Doing it right with real certs on everything isn't hard, so why wouldn't I?

EtA: I was doing it for years before they added the ability to do it within the admin interface. Sucks to have to work around it, but sucks much worse to do cleanup after an intrusion. I hate taking my day job home :p
 
Last edited:
FWIW, Asus dropped an update to the Official Beta today... 12/31/2020 in the 'Official' forum section.
I tested that beta this morning:

My report to Asus on the temp issue:
Monitor CPU temp with: cat /sys/class/thermal/thermal_zone*/temp

On 386_40451 the CPU temp was 68.5 C after overnight operation.
On the beta 386_41535 the CPU temp was at 88.5 C after 2 hours of operation.
Enabled "pwr config --wait on" and within 10 minutes the CPU temp was at 83.2 C.

Also the QOS Bandwidth monitor does not work on this beta. Did work on 386_40451.
 
beta 4 looks good on my AX88U and AC86U.

Does your Beta 4 include the changelog from the new ASUS 9.0.0.4.386.41535 build?

Change log
- Fixed Let's encrypt register issue.

Really looking forwards to test the Let's encryption register issues being solved..
In the meantime, on the topic of cooling, my beta3 is still holding strong at ~80C at CPU without active cooling for me on my RT-AX88U :)
 
If you can be victim to a MitM attack within your own LAN, then you have a major problem already.
The biggest security threat... is from the INSIDE! Damn kids and their MitM attacks on the home network. ;)
 
I have an Rt-ax58u; when I was used to firmware Version 3.0.0.4.384.10177 and Version 3.0.0.4.384.9918, the 2.4G shows Tx Rate and Rx Rate 6.5Mbps a few min. And then it came back 65 or 74. When it shows 6.5Mbps, I can't open any web pages.

I have tried 386.1 beta 3 and it has same problem.!

P.S. I've tried everything there I can, such as reset the router, different channels etc.
 

Attachments

  • IMG_1301.JPG
    IMG_1301.JPG
    88.8 KB · Views: 176
On my AX88U my device name is this now RT-AX88U-0000 it used to be the same but with numbers and letters instead of trailing 0000. Does anyone know which mac address is used and what portion of it?
 
This happens with Beta2 and 3;

LAN-DHCP
Enabling Manual assignment. Having add 3 wired devices (AndroidTV), 1 Wifi Printer, and 1 802.3ad bonded NAS.

Just some samples, but all throught the log, dozens of messages, mix of wired and wireless coming from Router (AX88) or Mesh nodes (AC5300). Devices not even related to the 5 that were manually assigned. Had unrelated wired devices and wireless, of the wireless some static (Nest Doorbell) and several roaming between nodes (phones). Restarting dnsmasq via scMerlin, rebooting, reflashing, moving from B2 to B3, no difference. Eventually, on wired devices, they lose connectivity and I need to power cycle them to get the IP reassigned. Disabling Manual Assignment makes it go away. Also as part of the this, Network Map, Clients, View List - IP Addresses wire misidentified Static, Manual ,DHCP - haven't gone through the logs yet to correlate the MAC in the messages to the MAC associated with the misidenfied IPADDRs. Had to stop short as the wired AndroidTV boxes (one on each, Router, 2xAIMESH) were being impacted and no TV had family upset with me...

Dec 31 01:11:40 RT-AX88U kernel: 44:E4:EE:59:D1:B5 not mesh client, can't update it's ip
Dec 31 01:11:40 RT-AX88U kernel: 44:E4:EE:59:D1:B5 not mesh client, can't update it's ip
Dec 31 01:11:40 RT-AX88U kernel: 44:E4:EE:59:D1:B5 not mesh client, can't update it's ip
Dec 31 01:11:40 RT-AX88U kernel: 44:E4:EE:59:D1:B5 not mesh client, can't update it's ip
Dec 31 01:11:40 RT-AX88U kernel: 44:E4:EE:59:D1:B5 not mesh client, can't update it's ip
Dec 31 01:11:40 RT-AX88U kernel: 44:E4:EE:59:D1:B5 not mesh client, can't update it's ip
Dec 31 01:11:40 RT-AX88U kernel: 44:E4:EE:59:D1:B5 not mesh client, can't update it's ip
Dec 31 01:11:40 RT-AX88U kernel: 44:E4:EE:59:D1:B5 not mesh client, can't update it's ip
Dec 31 01:11:40 RT-AX88U kernel: 44:E4:EE:59:D1:B5 not mesh client, can't update it's ip
Dec 31 01:11:40 RT-AX88U kernel: 44:E4:EE:59:D1:B5 not mesh client, can't update it's ip
Dec 31 01:11:40 RT-AX88U kernel: 44:E4:EE:59:D1:B5 not mesh client, can't update it's ip
Dec 31 01:11:41 RT-AX88U kernel: 44:E4:EE:59:D1:B5 not mesh client, can't update it's ip
Dec 31 01:11:41 RT-AX88U kernel: 44:E4:EE:59:D1:B5 not mesh client, can't update it's ip
Dec 31 01:11:41 RT-AX88U kernel: 44:E4:EE:59:D1:B5 not mesh client, can't update it's ip
Dec 31 01:11:41 RT-AX88U kernel: 44:E4:EE:59:D1:B5 not mesh client, can't update it's ip
Dec 31 01:11:41 RT-AX88U kernel: 44:E4:EE:59:D1:B5 not mesh client, can't update it's ip
Dec 31 01:11:41 RT-AX88U kernel: 44:E4:EE:59:D1:B5 not mesh client, can't update it's ip
Dec 31 01:11:41 RT-AX88U kernel: 44:E4:EE:59:D1:B5 not mesh client, can't update it's ip
Dec 31 01:11:41 RT-AX88U kernel: 44:E4:EE:59:D1:B5 not mesh client, can't update it's ip
Dec 31 01:11:41 RT-AX88U kernel: 44:E4:EE:59:D1:B5 not mesh client, can't update it's ip
Dec 31 01:11:41 RT-AX88U kernel: 44:E4:EE:59:D1:B5 not mesh client, can't update it's ip
Dec 31 01:11:41 RT-AX88U kernel: 44:E4:EE:59:D1:B5 not mesh client, can't update it's ip
Dec 31 01:11:41 RT-AX88U kernel: 44:E4:EE:59:D1:B5 not mesh client, can't update it's ip
Dec 31 01:11:41 RT-AX88U kernel: 44:E4:EE:59:D1:B5 not mesh client, can't update it's ip
Dec 31 01:11:41 RT-AX88U kernel: 44:E4:EE:59:D1:B5 not mesh client, can't update it's ip
Dec 31 01:11:41 RT-AX88U kernel: 44:E4:EE:59:D1:B5 not mesh client, can't update it's ip
Dec 31 01:11:41 RT-AX88U kernel: 44:E4:EE:59:D1:B5 not mesh client, can't update it's ip
Dec 31 01:11:41 RT-AX88U kernel: 44:E4:EE:59:D1:B5 not mesh client, can't update it's ip
Dec 31 01:11:41 RT-AX88U kernel: 44:E4:EE:59:D1:B5 not mesh client, can't update it's ip
Dec 31 01:11:41 RT-AX88U kernel: 44:E4:EE:59:D1:B5 not mesh client, can't update it's ip
Dec 31 01:11:41 RT-AX88U kernel: 44:E4:EE:59:D1:B5 not mesh client, can't update it's ip
Dec 31 01:11:41 RT-AX88U kernel: 44:E4:EE:59:D1:B5 not mesh client, can't update it's ip
Dec 31 01:11:41 RT-AX88U kernel: 44:E4:EE:59:D1:B5 not mesh client, can't update it's ip
Dec 31 01:12:12 RT-AX88U kernel: 44:E4:EE:59:D1:B5 not mesh client, can't update it's ip
Dec 31 01:12:13 RT-AX88U kernel: 44:E4:EE:59:D1:B5 not mesh client, can't update it's ip
Dec 31 01:14:14 RT-AX88U kernel: 44:E4:EE:59:D1:B5 not mesh client, can't update it's ip

Dec 31 12:51:29 RT-AX88U kernel: 44:E4:EE:59:D5:42 not mesh client, can't update it's ip
Dec 31 12:51:29 RT-AX88U kernel: B0:65:BD:1B:F7:EF not mesh client, can't update it's ip
Dec 31 12:54:43 RT-AX88U kernel: 44:E4:EE:59:D5:42 not mesh client, can't update it's ip
Dec 31 12:54:43 RT-AX88U kernel: B0:65:BD:1B:F7:EF not mesh client, can't update it's ip
Dec 31 12:56:03 RT-AX88U kernel: B0:65:BD:1B:F7:EF not mesh client, can't update it's ip
Dec 31 12:59:45 RT-AX88U kernel: B0:65:BD:1B:F7:EF not mesh client, can't update it's ip
Dec 31 13:00:19 RT-AX88U kernel: 44:E4:EE:59:D5:42 not mesh client, can't update it's ip
Dec 31 13:00:19 RT-AX88U kernel: B0:65:BD:1B:F7:EF not mesh client, can't update it's ip

Didn't try this in 384.19 and didn't use 386.b1 so can't say whether or no it was happening there too.
Since turning off manual assignment, messages, issues have subsided. Will seen when the IP's renew if they get labled correctly in the client list.
 
WPA2 is trivially easy to crack. ARP is easy to spoof. Absolutely nothing about this is difficult for someone in any nearby house (and I have lots of bored, house-bound kids within wifi range)

But that's not the real threat. We've seen malware installed from browser extensions play the spoofing game inside networks for years now.

Everyone picks their comfort level. Doing it right with real certs on everything isn't hard, so why wouldn't I?

EtA: I was doing it for years before they added the ability to do it within the admin interface. Sucks to have to work around it, but sucks much worse to do cleanup after an intrusion. I hate taking my day job home :p

WPA2 trivially easy to crack - What a load of crap
 
On my AX88U my device name is this now RT-AX88U-0000 it used to be the same but with numbers and letters instead of trailing 0000. Does anyone know which mac address is used and what portion of it?

Last 4 (mac, ie ab:cd) on the sticker under the unit.
 
Have updated my new AX86U to Beta 3 and AC3100U to Beta 3 as a node and all is working well. Been running for about 36 hours and no issues with 26 clients connected to the two devices. All temperatures seem to be with in normal ranges and speeds are great now that I have upgraded the main router to new AX86U. Thanks to Merlin and Happy New Year to all!!!
 
WPA2 is trivially easy to crack.
So true. I find it marginally more difficult if you change the default password. :) Sorry, after this year, I needed that.
 
Go back to version 384.19 and don't use the firmware version 386.1 because is a piece of garbage.

Something similar happens to me, but using repeater and it doesn't happen in the version 384.19.

Once I disabled Manual Assignment, problem vanished. Everything is working 100%, and temps 80c~85c at 23.3c ambient. Was running warmer, gave a little tilt to the router by putting a thin box in one front corner. Will see overnight as ambient raises to 25.5 what it looks like in the AM. Have scribe/uiscribe, Skynet, conmon ,ntpMerlin, scMerlin running...
 
The big question is why did Asus feel the need to deliberately disable these CPU wait states on this firmware (presumably with full knowledge of the effect on CPU temps). Odd.

It was to address a technical issue. After consulting with them, that issue isn't critical enough to not revert this change, so I went ahead and reverted it on my end.

why we are seeing higher temps even after re-enabling of the CPU wait states):

Heat soak. The router has no active cooling, so even if the CPU reduces its heat generation, all the heat spreaders on top of it have been heated up and are only passively cooled, so for these to cool down might take hours.
 
After consulting with them, that issue isn't critical enough to not revert this change, so I went ahead and reverted it on my end.
Will you release a new AC86u (only) build with this change, for those that are worried about high CPU temperatures?

Or should they wait for Beta 4?

(Reason for asking: I did not have time to install Beta 3 yet, but was planning to install it this weekend)
 
It would be nice to have the GUI option to enable or disable.

I follow this thread to install it on my ax88u when I see it stable enough (family and telecommuting does not give option to error) My ax88u is a first version where cpuwait is off by default. in my case. I have been 9 days with cpuwait on and cpuspeed on without any problem in 384.19 and waiting to make the jump

1609496019311.png
 
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