Beta Asuswrt-Merlin 386.1 Beta is now available

[jorhett]

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

 

[bbunge]

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.

 

[ExtremeFiretop]

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?

Beta - ASUSWRT 386 RC2 public beta with full functions AiMesh 2.0

Pretty cool developments, can't wait to finally try these long awaited 386 versions once they are finalized as a general release in the form of an @RMerlin firmware (once some more time goes by waiting for the GPL of course).:):cool:

www.snbforums.com

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

 

[jorhett]

@RMerlin probably need to rename this thread "386.1 Beta(s)" or make a new thread for beta4 at least. Frankly, this one is quite long...

 

[shabbs]

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.

 

[pltmr]

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.

 

[skeal]

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?

 

[aex.perez]

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:591:B5 not mesh client, can't update it's ip
Dec 31 01:11:40 RT-AX88U kernel: 44:E4:EE:591:B5 not mesh client, can't update it's ip
Dec 31 01:11:40 RT-AX88U kernel: 44:E4:EE:591:B5 not mesh client, can't update it's ip
Dec 31 01:11:40 RT-AX88U kernel: 44:E4:EE:591:B5 not mesh client, can't update it's ip
Dec 31 01:11:40 RT-AX88U kernel: 44:E4:EE:591:B5 not mesh client, can't update it's ip
Dec 31 01:11:40 RT-AX88U kernel: 44:E4:EE:591:B5 not mesh client, can't update it's ip
Dec 31 01:11:40 RT-AX88U kernel: 44:E4:EE:591:B5 not mesh client, can't update it's ip
Dec 31 01:11:40 RT-AX88U kernel: 44:E4:EE:591:B5 not mesh client, can't update it's ip
Dec 31 01:11:40 RT-AX88U kernel: 44:E4:EE:591:B5 not mesh client, can't update it's ip
Dec 31 01:11:40 RT-AX88U kernel: 44:E4:EE:591:B5 not mesh client, can't update it's ip
Dec 31 01:11:40 RT-AX88U kernel: 44:E4:EE:591:B5 not mesh client, can't update it's ip
Dec 31 01:11:41 RT-AX88U kernel: 44:E4:EE:591:B5 not mesh client, can't update it's ip
Dec 31 01:11:41 RT-AX88U kernel: 44:E4:EE:591:B5 not mesh client, can't update it's ip
Dec 31 01:11:41 RT-AX88U kernel: 44:E4:EE:591:B5 not mesh client, can't update it's ip
Dec 31 01:11:41 RT-AX88U kernel: 44:E4:EE:591:B5 not mesh client, can't update it's ip
Dec 31 01:11:41 RT-AX88U kernel: 44:E4:EE:591:B5 not mesh client, can't update it's ip
Dec 31 01:11:41 RT-AX88U kernel: 44:E4:EE:591:B5 not mesh client, can't update it's ip
Dec 31 01:11:41 RT-AX88U kernel: 44:E4:EE:591:B5 not mesh client, can't update it's ip
Dec 31 01:11:41 RT-AX88U kernel: 44:E4:EE:591:B5 not mesh client, can't update it's ip
Dec 31 01:11:41 RT-AX88U kernel: 44:E4:EE:591:B5 not mesh client, can't update it's ip
Dec 31 01:11:41 RT-AX88U kernel: 44:E4:EE:591:B5 not mesh client, can't update it's ip
Dec 31 01:11:41 RT-AX88U kernel: 44:E4:EE:591:B5 not mesh client, can't update it's ip
Dec 31 01:11:41 RT-AX88U kernel: 44:E4:EE:591:B5 not mesh client, can't update it's ip
Dec 31 01:11:41 RT-AX88U kernel: 44:E4:EE:591:B5 not mesh client, can't update it's ip
Dec 31 01:11:41 RT-AX88U kernel: 44:E4:EE:591:B5 not mesh client, can't update it's ip
Dec 31 01:11:41 RT-AX88U kernel: 44:E4:EE:591:B5 not mesh client, can't update it's ip
Dec 31 01:11:41 RT-AX88U kernel: 44:E4:EE:591:B5 not mesh client, can't update it's ip
Dec 31 01:11:41 RT-AX88U kernel: 44:E4:EE:591:B5 not mesh client, can't update it's ip
Dec 31 01:11:41 RT-AX88U kernel: 44:E4:EE:591:B5 not mesh client, can't update it's ip
Dec 31 01:11:41 RT-AX88U kernel: 44:E4:EE:591:B5 not mesh client, can't update it's ip
Dec 31 01:11:41 RT-AX88U kernel: 44:E4:EE:591:B5 not mesh client, can't update it's ip
Dec 31 01:11:41 RT-AX88U kernel: 44:E4:EE:591:B5 not mesh client, can't update it's ip
Dec 31 01:11:41 RT-AX88U kernel: 44:E4:EE:591:B5 not mesh client, can't update it's ip
Dec 31 01:12:12 RT-AX88U kernel: 44:E4:EE:591:B5 not mesh client, can't update it's ip
Dec 31 01:12:13 RT-AX88U kernel: 44:E4:EE:591:B5 not mesh client, can't update it's ip
Dec 31 01:14:14 RT-AX88U kernel: 44:E4:EE:591:B5 not mesh client, can't update it's ip

Dec 31 12:51:29 RT-AX88U kernel: 44:E4:EE:595: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:595: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:595: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.

 

[joe scian]

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

WPA2 trivially easy to crack - What a load of crap

 

[John Fitzgerald]

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.

 

[David Williams]

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!!!

 

[elorimer]

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.

 

[aex.perez]

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

 

[RMerlin]

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.

 

[XIII]

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)

 

[alejandrofm1]

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

 

[miroco]

Did this behavior get explained?

I'm on an AX86 and beta 3. My configuration is pretty much vanilla. I made a full reset after the upgrade from Asus official to beta 2. The router was cold booted after the upgrade to beta 3.

As with user @Mortheus2020, none of these mac addresses belong to a device on my network. Furthermore, the addresses appear invalid, since a mac address lookup reveal that: no vendor exist.

Beta - ASUSWRT 386 RC2 public beta with full functions AiMesh 2.0

I own 3 XT8/RT-AX95Q and after very mixed experiences with stock firmware, I decided to give the latest "official" RC8 version a try. Unfortunately, things seem to have gotten from bad to worse for me. One of the major issues I have with those devices is that the third node randomly goes dark...

www.snbforums.com

Dec 31 23:37:16 kernel: CONSOLE: 137239.988 wl1: wlc_recv: dropping a frame with invalid src mac addressdf:be:83:32:dc:c3
Dec 31 23:37:16 kernel: CONSOLE: 137239.988 Unexpected RX reason 22 {if=wl1 fc=0040 seq=f6b0 A1=ff:ff:ff:ff:ff:ff A2=df:be:83:32:dc:c3}
Dec 31 23:43:36 kernel: CONSOLE: 137611.561 wl1: wlc_recv: dropping a frame with invalid src mac addressed:fa:2f:99:0e:65
Dec 31 23:43:36 kernel: CONSOLE: 137611.561 Unexpected RX reason 22 {if=wl1 fc=0040 seq=2330 A1=ff:ff:ff:ff:ff:ff A2=ed:fa:2f:99:0e:65}

Another oddity occurred on Dec the 18th when I was on beta 2 and discovered two additional Apple devices in the clients list, with mac addresses very similar to that of my Mac and valid ip addresses (within the DHCP-scoop). The connections showed up as wired RJ45, but the router only has a wan and a lan connection and it's in my field of view. I took a screenshot of the incident and as I did, they vanished from the clients list. I also saved the system log, but they weren't in it. Is it beta teething, or something else? The SolarWinds attack comes to mind since it's plastered all over the media. With lots of people working remotely, who knows?

 

[Vimes]

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

(snip)

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.

Initially my firmware update from 384.19 to beta 3 of this firmware seemed quite uneventful, in other words fine without issue. But then I noted firstly that the logs of the AX88U had entries like...

miniupnpd[1504]: HTTP peer 169.254.107.63 :61264 is not from a LAN, closing the connection

etc
etc

I then noticed that certain devices, the one above I traced to our HP N54L media server in the loft with a static IP of 192.168.1.147, were not being assigned an IP address correctly and so were not able to connect or they were showing as static when the had always been DHCP.
I had to go into the loft and manually resolve the IP issue with the server by rebooting it. Other devices, like our TV in kitchen showed as static when it was DHCP, needed a full power cycle to resolve it. One of our other TV's wasn't able to be assigned an IP address even tho it was set to use DHCP from the router, it kept being failed to be assigned. That needed a power cycle.
Not knowing at the time that a reboot of each device could have sorted this somewhat I WPA hard reset the router and manually applied each of my settings. But the same issue applied with the 169.254.107.63 type assignments within the client list.
Prior to the update from 384.19 I had none of these issues but was reminded in the update notes that a factory reset could be needed if anything strange is noted.

For me tho it was the full power cycle of certain connected devices until the behaviour above was resolved. I am now getting the impression that beta 3 is working fine since power cycling many connected devices.

 

[Morpheus2020]

Did this behavior get explained?

I'm on an AX86 and beta 3. My configuration is pretty much vanilla. I made a full reset after the upgrade from Asus official to beta 2. The router was cold booted after the upgrade to beta 3.

As with user @Mortheus2020, none of these mac addresses belong to a device on my network. Furthermore, the addresses appear invalid, since a mac address lookup reveal that: no vendor exist.

Beta - ASUSWRT 386 RC2 public beta with full functions AiMesh 2.0

I own 3 XT8/RT-AX95Q and after very mixed experiences with stock firmware, I decided to give the latest "official" RC8 version a try. Unfortunately, things seem to have gotten from bad to worse for me. One of the major issues I have with those devices is that the third node randomly goes dark...

www.snbforums.com

Dec 31 23:37:16 kernel: CONSOLE: 137239.988 wl1: wlc_recv: dropping a frame with invalid src mac addressdf:be:83:32:dc:c3
Dec 31 23:37:16 kernel: CONSOLE: 137239.988 Unexpected RX reason 22 {if=wl1 fc=0040 seq=f6b0 A1=ff:ff:ff:ff:ff:ff A2=df:be:83:32:dc:c3}
Dec 31 23:43:36 kernel: CONSOLE: 137611.561 wl1: wlc_recv: dropping a frame with invalid src mac addressed:fa:2f:99:0e:65
Dec 31 23:43:36 kernel: CONSOLE: 137611.561 Unexpected RX reason 22 {if=wl1 fc=0040 seq=2330 A1=ff:ff:ff:ff:ff:ff A2=ed:fa:2f:99:0e:65}

Another oddity occurred on Dec the 18th when I was on beta 2 and discovered two additional Apple devices in the clients list, with mac addresses very similar to that of my Mac and valid ip addresses (within the DHCP-scoop). The connections showed up as wired RJ45, but the router only has a wan and a lan connection and it's in my field of view. I took a screenshot of the incident and as I did, they vanished from the clients list. I also saved the system log, but they weren't in it. Is it beta teething, or something else? The SolarWinds attack comes to mind since it's plastered all over the media. With lots of people working remotely, who knows?

I am using 3.0.0.4.386.41535 of AX86U now. "wl1: wlc_recv: dropping a frame with invalid src mac address" still exist in syslog.
I think it is the debug information of ASUS firmware.

 

[Kees17760]

Go back to version 384.19 and don't use the firmware version 386.1 because is a piece of garbage.

I'd prefer to call it Work in Progress