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.
As far as I know there are no options (in GUI) to configure the speed of a single port. The link speed is set by Autonegotiation.
F. Y. I you can change wan port speed under dual wan tab. :)
 
Yes - if you want to use your 2,5gb LAN Port as WAN Port ... I didn't know that was your goal.
I just looking what it can do, Later i setup AiMesh with 2.5Gbps backhaul.
 
@JWoo - great you have this fixed. Thanks @RMerlin

@JWoo can you check / confirm if runner HW acceleration is present / working on the 58U? I think you will find the command (if it exists) by running the following from cmd/shell... ls /bin

@RMerlin - I have read that the bcm675x chip in the ax-58u does not use runner. If true, does that mean runner HW acceleration should not be included in the tools GUI (see pic from 384.19)

View attachment 28289
From RT-AX58U on latest 386.1 Beta 1.

1607359130451.png


From flow cache control (fc) command:

fc status
Flow Timer Interval = 10000 millisecs
Pkt-HW Activate Deferral rate = 1
Pkt-HW Idle Deactivate = 0
Pkt-SW Activate Deferral count = 0
Flow Low Pkt Rate = 10
Acceleration Mode: <L2 & L3>
MCast Learning <Disabled>
MCast Acceleration IPv4<Enabled> IPv6<Enabled>
IPv6 Learning <Enabled>
GRE Learning <Enabled>
4o6 Fragmentation <Enabled>
TCP Ack Prioritization <Enabled>
HW Acceleration <Enabled>
Notify Processing Mode <Hybrid>
OVS Flow Learning <Disabled>
Flow Learning Enabled : Max<16383>, Active<266>, Cummulative [ 86550 - 86284 ]
 
AX86U or AC86U?
You can use Asus original firmware and Merlin if they are based on the same version. So 386.1 and 384.19 wouldn't work nicely together.
 
You can use Asus original firmware and Merlin if they are based on the same version. So 386.1 and 384.19 wouldn't work nicely together.
It works well this way too. I am using Merlins firmware on my AX88 and AC68U. On my RT-3100 model, I am using the ASUS beta 386. Once Merlin finishes the compile for it, then I will move it over.
 
Just coming in to mention that looks like 386 doesn't fix my AX86U refusing to recognize my as4002t when connected from its 10G port to the 2.5G port on the router. I know that this is Asus at fault and unlikely there will be a fix introduced by merlin, but since I jumped straight to merlin instead of testing the official 386 RC fw, I thought I post it here.
 
Just coming in to mention that looks like 386 doesn't fix my AX86U refusing to recognize my as4002t when connected from its 10G port to the 2.5G port on the router. I know that this is Asus at fault and unlikely there will be a fix introduced by merlin, but since I jumped straight to merlin instead of testing the official 386 RC fw, I thought I post it here.
Have you tested port5?
 
Hi! Have successfully done a clean upgrade from 386.1_alpha3 to 386.1_beta1 on an RT-AX3000. Uploaded/installed the beta firmware, logged in via ssh, performed 'nvram erase ; reboot', and redid most settings through the GUI. However, since I have 'rsync' built and installed, and keep a backup, I did move over the custom_clientlist, dhcp_hostnames and dhcp_staticlist files from that backup. Hopefully, that won't cause any issues, just didn't feel like hand entering or even copy/pasting more than a dozen clients.
 
AC86
A few questions about the new version.

1. Tell me why the log contains a mention of devices that have a DHCP reservation and why does the router want to update them as a device mesh?

Dec 7 20:02:26 wlceventd: wlceventd_proc_event(510): wl0.3: Auth B4:E6:2D:40:C1:B8, status: Successful (0)
Dec 7 20:02:26 wlceventd: wlceventd_proc_event(539): wl0.3: Assoc B4:E6:2D:40:C1:B8, status: Successful (0)
Dec 7 20:02:30 kernel: 00:40:8C:B7:7B:40 not mesh client, can't update it's ip
Dec 7 20:02:30 kernel: 00:40:8C:B7:E0:C4 not mesh client, can't update it's ip
Dec 7 20:03:36 wlceventd: wlceventd_proc_event(474): wl0.3: Deauth_ind B4:E6:2D:40:C1:B8, status: 0, reason: Disassociated due to inactivity (4)
Dec 7 20:03:36 wlceventd: wlceventd_proc_event(491): wl0.3: Disassoc B4:E6:2D:40:C1:B8, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Dec 7 20:49:26 wlceventd: wlceventd_proc_event(491): eth6: Disassoc 88:A9:B7:47:62:32, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Dec 7 20:49:26 wlceventd: wlceventd_proc_event(491): eth6: Disassoc 88:A9:B7:47:62:32, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Dec 7 20:55:09 wlceventd: wlceventd_proc_event(510): eth6: Auth 88:A9:B7:47:62:32, status: Successful (0)
Dec 7 20:55:09 wlceventd: wlceventd_proc_event(520): eth6: ReAssoc 88:A9:B7:47:62:32, status: Successful (0)
Dec 7 20:55:09 kernel: br0: received packet on eth6 with own address as source address
Dec 7 20:59:44 wlceventd: wlceventd_proc_event(491): eth6: Disassoc 88:A9:B7:47:62:32, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Dec 7 20:59:44 wlceventd: wlceventd_proc_event(491): eth6: Disassoc 88:A9:B7:47:62:32, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Dec 7 20:59:44 roamast: [EXAP]Deauth old sta in 1 0: 88:A9:B7:47:62:32
Dec 7 20:59:44 roamast: eth6: disconnect weak signal strength station [88:a9:b7:47:62:32]
Dec 7 20:59:44 roamast: eth6: remove client [88:a9:b7:47:62:32] from monitor list
Dec 7 21:00:36 wlceventd: wlceventd_proc_event(510): eth6: Auth 88:A9:B7:47:62:32, status: Successful (0)
Dec 7 21:00:36 wlceventd: wlceventd_proc_event(520): eth6: ReAssoc 88:A9:B7:47:62:32, status: Successful (0)
Dec 7 21:00:36 kernel: br0: received packet on eth6 with own address as source address
Dec 7 21:00:39 kernel: 00:40:8C:B7:7B:40 not mesh client, can't update it's ip
Dec 7 21:00:39 kernel: 00:40:8C:B7:E0:C4 not mesh client, can't update it's ip

Dec 7 21:02:33 rc_service: cfg_server 1472:notify_rc email_info


2. In the Network Map section on the right there is a scrolling bar for information - somehow it looks ugly and crooked. Don’t you?
1607364367448.png

3. If you click on the Aimesh Nodes icon on the Network Map, you will get into the old interface where there is a mesh node icon on the right and you can no longer click on it. Then why is it there if there is a separate branch for the Aimesh configuration?
1607364507684.png

4. The description for the firmware says that aimesh nodes can now broadcast guest networks to their coverage area. How to see or understand this?
My part of devices (smart home) will still connect to Aimesh Router, although they are closer to Aimesh Node.
 
Last edited:
Tell me why the log contains a mention of devices that have a DHCP reservation and why does the router want to update them as a device mesh?
From Post #1:
While testing AiMesh is ok, do note that AiMesh is closed source, and therefore any issue within it are outside of my control. Reproduce the same issue with the stock firmware, and if you do, report it to Asus instead
 
Having a single guest network configured with YaziFi for enhanced configurations (AP isolation config and separate network ranges); is it recommended to remove and leave off or leave as is for the upgrade? I have read through the thread and it seems like one issue that people indicate is related to the guest setup, so wouldn't mind fully removing if that is suspected to help avoid issues.
 
[QUOTE = "heysoundude, post: 639351, lid: 49937"]
dat klinkt meer geschikt voor een script voor mij. [USER = 53009] @Jack Yaz [/ USER] lijkt de systeemmonitoringscriptgoeroe hier in de buurt te zijn ... misschien kan iemand hem vriendelijk vragen daarnaar te kijken, misschien als een verbetering van een van zijn bestaande creaties - scMerlin, misschien ?
[/CITAAT]
:)
 
does this sound familiar to anyone?

I cannot create a new certificate and / or import an old one.
 

Attachments

  • ddns.JPG
    ddns.JPG
    82.3 KB · Views: 165
The biggest problem is related to MTU. If you go to the WAN page and make sure the MTU is set to 1500 after you are on beta 1 then in theory you should be fine, but I can't guarantee it 100% as there might be other nvram settings that are problematic if you ran an alpha build.

Symptoms of an incorrect MTU can be flat out weird at times. For instance, OpenVPN clients will fail to connect over UDP but work fine over TCP if your MTU is misconfigured (i.e. if your WAN has a default MTU of 576, then UDP packet fragmentation will break everything).
my MTU IS SET AT 1492 same as it always has been , i'm on the same DSL line for the past 30 years
i
Dec 7 14:17:13 rc_service: watchdog 557:notify_rc start_cfgsync
Dec 7 14:17:43 rc_service: watchdog 557:notify_rc start_cfgsync



do get this on my sys logs neverending

, Anything I should watch out for ?
Thanks
 
Last edited:
Is it just in my case where last time I've been able to utilize max speed with AX58U last time with 384.16? I've upgraded now to 386.1 to see if anything changed but nope..with the same conditions speedtest comes out about 40-50 Mbps lower with anything above 384.16 :(
 
Status
Not open for further replies.

Sign Up For SNBForums Daily Digest

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