Beta Asuswrt-Merlin 386.4 beta is now available

[ExtremeFiretop]

Hey @RMerlin

Just reporting an issue with Alpha 3. I noticed a new "Disable 11b" in the WiFi General options as found below.
Once disabled, that's it, it's game over for 802.11b. A hard reset was needed to allow 8011b again, I couldn't re-enable it for the life of me.

1639136123199.png

[ 386.4 alpha Build(s) ] Testing available build(s)

I just tried to do a build for AX88U. It still fails. Need to wait some more. Looks like I spoke too soon...

www.snbforums.com

Just updated to Beta 4, I guess this issue is still ongoing.
Downgrading again

 

[octopus]

Updated to new Beta and working just fine. Problem with Aimesh GUI is gone.

[ 386.4 alpha Build(s) ] Testing available build(s)

...YET. And when they are, I'm sure they'll be current. I'm referring to Asus's client/server support code (both rc and webui), not to the kernel and userspace tools. The webui code for instance is very different in the RC3 code branch than the RC2 code I am currently working with.

www.snbforums.com

Uptime: 0 days 9 hour(s) 1 minute(s) 19 seconds

Thank you for new build!

 

[pirx73]

I must insert grinning Austin Powers "Yeah, baby, yeah!" GIF here

 

[XIII]

Eventually updated my AC86U from latest alpha 3 to beta 1, after several attempts.

The very first attempt claimed succes and then showed a dialog that I should manually reboot. After doing that I was still on alpha 3... The next attempt immediately failed (I had already put the USB drive back in; mislead by the success message). The third attempt (USB removed, rebooted again) really succeeded.

Nothing else to report right now.

 

[spykos]

@RMerlin

Are the below messages because I am running the current beta or they exist in normal builds too ?

Dec 17 11:04:47 hostapd: eth7: STA (MAC address deleted) IEEE 802.11: disassociated
Dec 17 11:04:47 wlceventd: wlceventd_proc_event(469): eth7: Deauth_ind (MAC address deleted), status: 0, reason: Unspecified reason (1)
Dec 17 11:04:47 wlceventd: wlceventd_proc_event(534): eth7: Assoc (MAC address deleted), status: Successful (0)
Dec 17 11:04:47 hostapd: eth7: STA (MAC address deleted) IEEE 802.11: associated
Dec 17 11:04:47 hostapd: eth7: STA (MAC address deleted) RADIUS: starting accounting session E5CD0694AE224076
Dec 17 11:04:47 hostapd: eth7: STA (MAC address deleted) WPA: pairwise key handshake completed (RSN)
Dec 17 11:05:00 rc_service: service 3046:notify_rc restart_letsencrypt

Is there a way to filter the above ?

 

[dmtg]

It's Asus's recent IPv6 implementation in ddns which seems to still be broken. I needed that tested since I had fixed a separate issue, and was wondering if it might also fix this second one (can't test myself, no IPv6 support with my ISP).

I will most likely disable IPv6 support in the next release, and wait for Asus to fix it on their end.

The Asus fix in this firmware 9.0.0.4_386_57877

 

[fegomanet]

No.

I have recently bought an RT-AX58U v2 and have the possibility to exchange it. Do you think that in future versions it will be supported by Merlin? Now I can return it so I am interested in your answer. Thanks a lot!

 

[learning_curve]

I have a problem with DDNS (Asus) status that is inactive for some reason.Dynamic WAN ipv4 won't get updated if it's changed

Related logs:
Dec 17 01:57:57 rc_service: httpd 1404:notify_rc restart_ddns_le
Dec 17 01:57:57 start_ddns: eth0 has not yet obtained an ipv6 address
Dec 17 02:00:00 rc_service: service 4463:notify_rc restart_letsencrypt
Dec 17 02:00:00 Let's_Encrypt: Err, DDNS update failed.

Some parts of this old thread might be of some use @pkoci
DDNS (Asus) has never been 100% reliable to be honest and AFAIK, they (Asus) still only provide DDNS IPv4 only and they don't support IPv6 DDNS - yet. Even though there's now some coding present, to do so.

That was one of the background reasons for that old thread, but the other relevant factor was/is, that No-IP DDNS do support IPv6 DDNS and it works fine on the current stable Merlin release (that I'm using - forum sig).

Have you tried using No-IP DDNS or any another DDNS provider other than Asus? If / when you do, that might possibly add some more info for @RMerlin / you / us on this Beta release, just by excluding Asus DDNS?

 

[GWater]

No extra script needed, working fine here. I can access both the WAN and any of my LAN devices through the OpenVPN connection, on Android or laptops from outside my LAN.
This has been the case for a least the last couple of years that I have been using this function, no helper scripts needed.
Maybe reset your OpenVPN server settings to defaults, and reconfigure from scratch.

Interesting...done multiple resets of openvpn server and disabled Skynet + diversion. Might try a full reset

 

[Imptful]

Hello, i have some weird logs with my AX 88u running latest Merlin 386.4 beta:

Dec 17 11:03:20 kernel: potentially unexpected fatal signal 11.
Dec 17 11:03:20 kernel: CPU: 1 PID: 6437 Comm: dcd Tainted: P O 4.1.51 #2
Dec 17 11:03:20 kernel: Hardware name: Broadcom-v8A (DT)
Dec 17 11:03:20 kernel: task: ffffffc03dc24180 ti: ffffffc02baf4000 task.ti: ffffffc02baf4000
Dec 17 11:03:20 kernel: PC is at 0xf737a39c
Dec 17 11:03:20 kernel: LR is at 0x1dd14
Dec 17 11:03:20 kernel: pc : [<00000000f737a39c>] lr : [<000000000001dd14>] pstate: 600f0010
Dec 17 11:03:20 kernel: sp : 00000000fffc0db8
Dec 17 11:03:20 kernel: x12: 00000000000a2050
Dec 17 11:03:20 kernel: x11: 00000000f66ff024 x10: 00000000000a23c4
Dec 17 11:03:20 kernel: x9 : 00000000f66ff734 x8 : 00000000000a287c
Dec 17 11:03:20 kernel: x7 : 00000000f66ff76c x6 : 00000000000a2876
Dec 17 11:03:20 kernel: x5 : 0000000000000000 x4 : 00000000f66ff718
Dec 17 11:03:20 kernel: x3 : 0000000000000000 x2 : 00000000fffc0d94
Dec 17 11:03:20 kernel: x1 : 000000000007d75a x0 : 0000000000000000
Dec 17 11:04:08 kernel: httpd (1325): drop_caches: 1
Dec 17 11:25:51 hostapd: eth7: STA WPA: group key handshake completed (RSN)
Dec 17 11:25:51 hostapd: eth6: STA WPA: group key handshake completed (RSN)
Dec 17 11:25:51 hostapd: eth7: STA WPA: group key handshake completed (RSN)
Dec 17 11:25:52 hostapd: eth7: STA WPA: group key handshake completed (RSN)
Dec 17 11:28:33 kernel: httpd (1325): drop_caches: 1
Dec 17 11:29:49 wlceventd: wlceventd_proc_event(469): eth7: Deauth_ind, status: 0, reason: Unspecified reason (1)
Dec 17 11:29:49 hostapd: eth7: STA IEEE 802.11: disassociated
Dec 17 11:33:25 kernel: potentially unexpected fatal signal 11.
Dec 17 11:33:25 kernel: CPU: 1 PID: 9615 Comm: dcd Tainted: P O 4.1.51 #2
Dec 17 11:33:25 kernel: Hardware name: Broadcom-v8A (DT)
Dec 17 11:33:25 kernel: task: ffffffc02ba4eb80 ti: ffffffc02b938000 task.ti: ffffffc02b938000
Dec 17 11:33:25 kernel: PC is at 0xf708a39c
Dec 17 11:33:25 kernel: LR is at 0x1dd14
Dec 17 11:33:25 kernel: pc : [<00000000f708a39c>] lr : [<000000000001dd14>] pstate: 600f0010
Dec 17 11:33:25 kernel: sp : 00000000ffe5ebf8
Dec 17 11:33:25 kernel: x12: 00000000000a2050
Dec 17 11:33:25 kernel: x11: 00000000f63ff024 x10: 00000000000a23c4
Dec 17 11:33:25 kernel: x9 : 00000000f63ff734 x8 : 00000000000a287c
Dec 17 11:33:25 kernel: x7 : 00000000f63ff76c x6 : 00000000000a2876
Dec 17 11:33:25 kernel: x5 : 0000000000000000 x4 : 00000000f63ff718
Dec 17 11:33:25 kernel: x3 : 0000000000000000 x2 : 00000000ffe5ebd4
Dec 17 11:33:25 kernel: x1 : 000000000007d75a x0 : 0000000000000000

Not shure what it mens, never had such logs with any Merlin Firmware.

 

[OlaP]

I can't add new AiMesh node after installing 486.4 beta using two RT-AX86U.
No matter I do router don't see any newly setup nodes.

Was running latest ASUS firmware FW_RT_AX86U_300438645934 on boith main router and node without any issues.

Upgraded to 386.4 beta and made reset in GUI. Then set up main router again without any issues.
Put AX86U mesh router 2-3 m from main router this has always worked before.

First tried reset button of and setup as new node (AX86U node still running FW_RT_AX86U_300438645934): not working Main Router could not find any AiMesh nodes.
Also tried on AiMesh node router: hard reset, Merlin 386.3-2, 386.4 beta soft and hard reset: Main Router could not find any AI mesh node.
Tried for hours no luck.

Gave up and put back FW_RT_AX86U_300438645934 on main router and restored saved setting.
Also put back FW_RT_AX86U_300438645934 on node router and made reset and setup as new node. No problem for main router to find the new AiMesh node again!

Something wrong with 386.4 beta?
Or am i missing something?
If I remember correctly I only made "full" GUI reset of main router Not hard reset after installing 386.4 beta..
Will try again making hard reset of main router when final 384.4 released.

 

[skeal]

Hello, i have some weird logs with my AX 88u running latest Merlin 386.4 beta:

Dec 17 11:03:20 kernel: potentially unexpected fatal signal 11.
Dec 17 11:03:20 kernel: CPU: 1 PID: 6437 Comm: dcd Tainted: P O 4.1.51 #2
Dec 17 11:03:20 kernel: Hardware name: Broadcom-v8A (DT)
Dec 17 11:03:20 kernel: task: ffffffc03dc24180 ti: ffffffc02baf4000 task.ti: ffffffc02baf4000
Dec 17 11:03:20 kernel: PC is at 0xf737a39c
Dec 17 11:03:20 kernel: LR is at 0x1dd14
Dec 17 11:03:20 kernel: pc : [<00000000f737a39c>] lr : [<000000000001dd14>] pstate: 600f0010
Dec 17 11:03:20 kernel: sp : 00000000fffc0db8
Dec 17 11:03:20 kernel: x12: 00000000000a2050
Dec 17 11:03:20 kernel: x11: 00000000f66ff024 x10: 00000000000a23c4
Dec 17 11:03:20 kernel: x9 : 00000000f66ff734 x8 : 00000000000a287c
Dec 17 11:03:20 kernel: x7 : 00000000f66ff76c x6 : 00000000000a2876
Dec 17 11:03:20 kernel: x5 : 0000000000000000 x4 : 00000000f66ff718
Dec 17 11:03:20 kernel: x3 : 0000000000000000 x2 : 00000000fffc0d94
Dec 17 11:03:20 kernel: x1 : 000000000007d75a x0 : 0000000000000000
Dec 17 11:04:08 kernel: httpd (1325): drop_caches: 1
Dec 17 11:25:51 hostapd: eth7: STA WPA: group key handshake completed (RSN)
Dec 17 11:25:51 hostapd: eth6: STA WPA: group key handshake completed (RSN)
Dec 17 11:25:51 hostapd: eth7: STA WPA: group key handshake completed (RSN)
Dec 17 11:25:52 hostapd: eth7: STA WPA: group key handshake completed (RSN)
Dec 17 11:28:33 kernel: httpd (1325): drop_caches: 1
Dec 17 11:29:49 wlceventd: wlceventd_proc_event(469): eth7: Deauth_ind, status: 0, reason: Unspecified reason (1)
Dec 17 11:29:49 hostapd: eth7: STA IEEE 802.11: disassociated
Dec 17 11:33:25 kernel: potentially unexpected fatal signal 11.
Dec 17 11:33:25 kernel: CPU: 1 PID: 9615 Comm: dcd Tainted: P O 4.1.51 #2
Dec 17 11:33:25 kernel: Hardware name: Broadcom-v8A (DT)
Dec 17 11:33:25 kernel: task: ffffffc02ba4eb80 ti: ffffffc02b938000 task.ti: ffffffc02b938000
Dec 17 11:33:25 kernel: PC is at 0xf708a39c
Dec 17 11:33:25 kernel: LR is at 0x1dd14
Dec 17 11:33:25 kernel: pc : [<00000000f708a39c>] lr : [<000000000001dd14>] pstate: 600f0010
Dec 17 11:33:25 kernel: sp : 00000000ffe5ebf8
Dec 17 11:33:25 kernel: x12: 00000000000a2050
Dec 17 11:33:25 kernel: x11: 00000000f63ff024 x10: 00000000000a23c4
Dec 17 11:33:25 kernel: x9 : 00000000f63ff734 x8 : 00000000000a287c
Dec 17 11:33:25 kernel: x7 : 00000000f63ff76c x6 : 00000000000a2876
Dec 17 11:33:25 kernel: x5 : 0000000000000000 x4 : 00000000f63ff718
Dec 17 11:33:25 kernel: x3 : 0000000000000000 x2 : 00000000ffe5ebd4
Dec 17 11:33:25 kernel: x1 : 000000000007d75a x0 : 0000000000000000

Not shure what it mens, never had such logs with any Merlin Firmware.

I have the same as you.

 

[pkoci]

Some parts of this old thread might be of some use @pkoci
DDNS (Asus) has never been 100% reliable to be honest and AFAIK, they (Asus) still only provide DDNS IPv4 only and they don't support IPv6 DDNS - yet. Even though there's now some coding present, to do so.

That was one of the background reasons for that old thread, but the other relevant factor was/is, that No-IP DDNS do support IPv6 DDNS and it works fine on the current stable Merlin release (that I'm using - forum sig).

Have you tried using No-IP DDNS or any another DDNS provider other than Asus? If / when you do, that might possibly add some more info for @RMerlin / you / us on this Beta release, just by excluding Asus DDNS?

I tried NO-IP DDNS but it seems not working either. A public ipv4 won't get updated.

logs:
Dec 17 13:25:00 rc_service: service 13794:notify_rc restart_letsencrypt
Dec 17 13:25:00 Let's_Encrypt: Err, DDNS update failed.
Dec 17 13:25:29 watchdog: start ddns.
Dec 17 13:25:29 rc_service: watchdog 1386:notify_rc start_ddns
Dec 17 13:25:29 start_ddns: eth0 has not yet obtained an ipv6 address
Dec 17 13:25:59 watchdog: start ddns.
Dec 17 13:25:59 rc_service: watchdog 1386:notify_rc start_ddns
Dec 17 13:25:59 start_ddns: eth0 has not yet obtained an ipv6 address

 

[frequenzy]

There seems to be a bug on network map. Internet GUI shows disconnected. But internet is up and running for the client devices.

 

[learning_curve]

I tried NO-IP DDNS but it seems not working either. A public ipv4 won't get updated.

logs:
Dec 17 13:25:00 rc_service: service 13794:notify_rc restart_letsencrypt
Dec 17 13:25:00 Let's_Encrypt: Err, DDNS update failed.
Dec 17 13:25:29 watchdog: start ddns.
Dec 17 13:25:29 rc_service: watchdog 1386:notify_rc start_ddns
Dec 17 13:25:29 start_ddns: eth0 has not yet obtained an ipv6 address
Dec 17 13:25:59 watchdog: start ddns.
Dec 17 13:25:59 rc_service: watchdog 1386:notify_rc start_ddns
Dec 17 13:25:59 start_ddns: eth0 has not yet obtained an ipv6 address

So far, FWIW nobody has posted the exact same DDNS issue as yourself nt this thread, but there are others, that are quite similar c/w solutions (which presumably you've already tried?) and it's not impossible... but it seems very, very unlikely that the standard Asus DDNS service does NOT work on a firmware Beta release from @RMerlin so as a 1st pure guess, could it be your own DDNS Configuration?

There's several ways to do this (besides the standard Asus GUI option - links in that same old thread) as you're no doubt already aware. If configured correctly, on the NO-IP site, you can see very clearly, exactly when and what your last DDNS update was, plus a numerical count of all of the most recent updates too.

If there's no entries at all on the NO-IP site, yes there's a fault, but it is almost certainly not a NO-IP fault (unless you have misconfigured that unintentionally) but surely, it's a mis-config somewhere at your end? One which might not be the DDNS config itself, but the DDNS function has become collateral damage of another misconfig?

 

[sentinelvdx]

So far doing good on performance & stability... Only concern is that on this release it's 5ºC above max temps on normal use. Avg is always 70ºC (Min 65/67ºC - Max 70ºC)

 

[FLA_NL]

Dirty upgrade from 386.3_2. All seems to be running fine. Thanks Merlin!

 

[pkoci]

So far, FWIW nobody has posted the exact same DDNS issue as yourself nt this thread, but there are others, that are quite similar c/w solutions (which presumably you've already tried?) and it's not impossible... but it seems very, very unlikely that the standard Asus DDNS service does NOT work on a firmware Beta release from @RMerlin so as a 1st pure guess, could it be your own DDNS Configuration?

There's several ways to do this (besides the standard Asus GUI option - links in that same old thread) as you're no doubt already aware. If configured correctly, on the NO-IP site, you can see very clearly, exactly when and what your last DDNS update was, plus a numerical count of all of the most recent updates too.

If there's no entries at all on the NO-IP site, yes there's a fault, but it is almost certainly not a NO-IP fault (unless you have misconfigured that unintentionally) but surely, it's a mis-config somewhere at your end? One which might not be the DDNS config itself, but the DDNS function has become collateral damage of another misconfig?

I just downgraded back to stable 386.3_2. Both Asus and NO-IP update public ipv4 correctly (my ipv4 changes everytime I reboot router). So there must be something wrong with the latest beta.

 

[Billy Chaney]

Upgraded from Alpha 3 to Beta 1 and am having an issue that's been here for me on all alphas. When ever I reboot my router the time in my log goes to GMT instead of EST. If I click on the apply button it goes back to EST.

 

[Unisoft]

I tried NO-IP DDNS but it seems not working either. A public ipv4 won't get updated.

logs:
Dec 17 13:25:00 rc_service: service 13794:notify_rc restart_letsencrypt
Dec 17 13:25:00 Let's_Encrypt: Err, DDNS update failed.
Dec 17 13:25:29 watchdog: start ddns.
Dec 17 13:25:29 rc_service: watchdog 1386:notify_rc start_ddns
Dec 17 13:25:29 start_ddns: eth0 has not yet obtained an ipv6 address
Dec 17 13:25:59 watchdog: start ddns.
Dec 17 13:25:59 rc_service: watchdog 1386:notify_rc start_ddns
Dec 17 13:25:59 start_ddns: eth0 has not yet obtained an ipv6 address

No_IP works fine on three AX86U routers - two of which on different WAN.
Lets ENcrypt gets the cert too and its all HTTPS. Its IPv4 not IPv6 on these.

I changed from dnsomatic after they had issues past couple of weeks and I got fed up with it, initially thinking it was an alpha build issue but I was clearly wrong.