[Dev] Asuswrt-Merlin 388.1 development

[FlourHome]

Thought I might give an update when I tried the latest Alpha for the GT-AX11000 PRO ^^ It seems to have issues when connecting to my two RT-AX92U AiMesh nodes... When it connects to those the entire WebUI freezes and won't load on the GT-AX11000 PRO... Tried both a dirty flash and a clean flash When I disable the AiMesh nodes the WebUI works ^^ I sadly didn't get logs since I had to get the network up again as fast as possible... I can possibly reflash and connect via SSH if needed for logs The two RT-AX92U were running gnuton's version of MerlinWrt, namely "386.08_0-gnuton1"...

 

[Damit1]

I trully hope that one day AX55 will be supported as well.
My device would really use it for the best if it had ASUSWRT Merlin!

 

[Damit1]

Im not sure what causing it, but it is the second time Im having random crashes.
First time I did not put any importance for this.

The log does not mention much.
Is it routers glitch or ISP glitch?

 

[Damit1]

Oct 22 13:01:40 wlceventd: wlceventd_proc_event(534): eth7: Assoc 02:64:70:06:28:B8, status: Successful (0)
Oct 22 13:05:12 wlceventd: wlceventd_proc_event(469): eth7: Deauth_ind 02:64:70:06:28:B8, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Oct 22 13:05:12 wlceventd: wlceventd_proc_event(469): eth7: Deauth_ind 02:64:70:06:28:B8, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Oct 22 13:05:13 wlceventd: wlceventd_proc_event(486): eth7: Disassoc 02:64:70:06:28:B8, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Oct 22 13:07:04 wlceventd: wlceventd_proc_event(486): eth7: Disassoc 4A:12:17:B9:A5:3E, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Oct 22 13:07:04 wlceventd: wlceventd_proc_event(486): eth7: Disassoc 4A:12:17:B9:A5:3E, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Oct 22 13:08:46 wlceventd: wlceventd_proc_event(505): eth7: Auth F2:BB:950:2E:C7, status: Successful (0)
Oct 22 13:08:46 wlceventd: wlceventd_proc_event(534): eth7: Assoc F2:BB:950:2E:C7, status: Successful (0)
Oct 22 13:48:08 wlceventd: wlceventd_proc_event(505): eth7: Auth 92:74:6C:4E:EB:FC, status: Successful (0)
Oct 22 13:48:08 wlceventd: wlceventd_proc_event(534): eth7: Assoc 92:74:6C:4E:EB:FC, status: Successful (0)

(These are prior to the crash)

May 5 08:05:04 kernel: klogd started: BusyBox v1.25.1 (2022-10-16 12:45:22 EDT)
May 5 08:05:04 kernel: Linux version 4.1.51 (merlin@ubuntu-dev) (gcc version 5.5.0 (Buildroot 2017.11.1) ) #2 SMP PREEMPT Sun Oct 16 12:58:26 EDT 2022
May 5 08:05:04 kernel: CPU: AArch64 Processor [420f1000] revision 0

......................

(This is a message after the crash)

May 5 08:05:52 wsdd2[1300]: error: wsdd-mcast-v4: wsd_send_soap_msg: send
Oct 22 13:58:06 wlceventd: wlceventd_proc_event(486): eth6: Disassoc 9C:76:13:43:71:09, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)

 

[ColinTaylor]

@Damit1 Those are all normal messages. Do you see any crashlog: messages in the log?

 

[Damit1]

@Damit1 Those are all normal messages. Do you see any crashlog: messages in the log?

May 5 08:05:04 kernel: proc_dostring_crashlogsave: crash log filename is /jffs/crashlog.log

Have that line in each crash, what should I do with that?

 

[Nagy Imre]

It's included for all models currently based on 21224. I'm still getting new model GPLs on a daily basis, so for now I'm focusing on merging these. Once I get most models, I'll see what I'm going to do with these first two models.


It's the opposite. The first two models received are on 20566, five are on 21224, with two more to be added soon (their GPLs were uploaded by Asus earlier today).

Is RT-AC88U
388 possible for GPL, or is it out of the question?
THX!

 

[ColinTaylor]

May 5 08:05:04 kernel: proc_dostring_crashlogsave: crash log filename is /jffs/crashlog.log

Have that line in each crash, what should I do with that?

Not that message which is normal. I meant lines that start with "crashlog:". For example:

May 5 06:05:08 crashlog: <2>CPU2: stopping
May 5 06:05:08 crashlog: <4>CPU: 2 PID: 0 Comm: swapper/2 Tainted: P O L 4.1.52 #2
May 5 06:05:08 crashlog: <4>Hardware name: Broadcom-v8A (DT)
May 5 06:05:08 crashlog: <0>Call trace:
May 5 06:05:08 crashlog: <4>[<ffffffc000087398>] dump_backtrace+0x0/0x150
May 5 06:05:08 crashlog: <4>[<ffffffc0000874fc>] show_stack+0x14/0x20
May 5 06:05:08 crashlog: <4>[<ffffffc0005589d0>] dump_stack+0x90/0xb0
May 5 06:05:08 crashlog: <4>[<ffffffc00008d710>] handle_IPI+0x190/0x1a0
May 5 06:05:08 crashlog: <4>[<ffffffc000080c68>] gic_handle_irq+0x88/0x90
May 5 06:05:08 crashlog: <4>Exception stack(0xffffffc03e8cfdc0 to 0xffffffc03e8cfef0)

 

[Damit1]

Not that message which is normal. I meant lines that start with "crashlog:". For example:

May 5 06:05:08 crashlog: <2>CPU2: stopping
May 5 06:05:08 crashlog: <4>CPU: 2 PID: 0 Comm: swapper/2 Tainted: P O L 4.1.52 #2
May 5 06:05:08 crashlog: <4>Hardware name: Broadcom-v8A (DT)
May 5 06:05:08 crashlog: <0>Call trace:
May 5 06:05:08 crashlog: <4>[<ffffffc000087398>] dump_backtrace+0x0/0x150
May 5 06:05:08 crashlog: <4>[<ffffffc0000874fc>] show_stack+0x14/0x20
May 5 06:05:08 crashlog: <4>[<ffffffc0005589d0>] dump_stack+0x90/0xb0
May 5 06:05:08 crashlog: <4>[<ffffffc00008d710>] handle_IPI+0x190/0x1a0
May 5 06:05:08 crashlog: <4>[<ffffffc000080c68>] gic_handle_irq+0x88/0x90
May 5 06:05:08 crashlog: <4>Exception stack(0xffffffc03e8cfdc0 to 0xffffffc03e8cfef0)

Nope. Not having these at all

 

[ColinTaylor]

Nope. Not having these at all

Check that the power cables/plugs are not loose.

 

[egc]

Might be, I don't know for sure. All I know is if it's a kernel module, and not a userland implementation.


The problem is the Wireguard protocol is not compatible with Broadcom Flow Cache (part of their NAT acceleration). That requires you to disable NAT acceleration to be able to use Wireguard, which will cap NAT throughput at around 300-350 Mbps max on an RT-AX88U (and that's without any VPN overhead). Whatever speed gain Wireguard might get, you end up being capped at around 300 Mbps, which isn't much faster than OpenVPN which can reach 220-250 Mbps on the same router. OpenVPN can run with Flow Cache still enabled, so that means anyone with an Internet connection faster than 300 Mbps cannot use Wireguard without seriously capping their whole Internet connection speed.

So in your case, you'd have to chose between 220 Mbps OpenVPN and 1 Gbps non-VPN throughput, or 300 Mbps Wireguard and 350 Mbps non-VPN throughput.

Because I needed the extra speed of Wireguard I had to revert to running DDWRT on my router (Asus AC68 and very happy to hear Wireguard is coming to AsusWRT-Merlin ), maybe DDWRT uses another Hardware NAT acceleration but as far as I know it is the broadcom CTF.ko module and that works together with WireGuard, so I have sligthly over 100 Mb/s using WireGuard and 850 Mb/s using the WAN as tested with iperf3, so it looks like it could work together?

 

[Damit1]

Check that the power cables/plugs are not loose.

Everything is sitting very locked and secured there.
Started ever since the Alpha release.
I guess & hope it will be resolved in Beta phase.

 

[Deleted member 22229]

Just upgraded to 388.1_A1 on AX58U. So far working good.

 

[Damit1]

AX56U upgrade from 386.7_2, to 388.1_alpha1, a rocky start- including not reaching to remote GUI- after about 20m everything worked by its own.
Reboot remotely fixed everything eventually

 

[STRUZZIN]

All my AX58U's on Alpha1 working very well here.

 

[RMerlin]

Because I needed the extra speed of Wireguard I had to revert to running DDWRT on my router (Asus AC68 and very happy to hear Wireguard is coming to AsusWRT-Merlin ), maybe DDWRT uses another Hardware NAT acceleration but as far as I know it is the broadcom CTF.ko module and that works together with WireGuard, so I have sligthly over 100 Mb/s using WireGuard and 850 Mb/s using the WAN as tested with iperf3, so it looks like it could work together?

CTF is the old technology used back in the 2.6.x days. The fact that you are running Wireguard on these older routers would indicate this is probably a userspace implementation of it, which is not as fast as the kernel implementation used by newer kernels.

 

[egc]

CTF is the old technology used back in the 2.6.x days. The fact that you are running Wireguard on these older routers would indicate this is probably a userspace implementation of it, which is not as fast as the kernel implementation used by newer kernels.

No it is a kernel space implementation that is why the speed is triple that of OpenVPN. I know WireGuard does not work on Kernel 2.6 but these routers are using Kernel 4.4 so they are also using an upgraded CTF.ko module for Kernel 4.4. maybe that is compatible with WireGuard?

 

[iceorbital]

can someone check if AirPrint is broken on 388.1?

 

[SomeWhereOverTheRainBow]

CTF is the old technology used back in the 2.6.x days. The fact that you are running Wireguard on these older routers would indicate this is probably a userspace implementation of it, which is not as fast as the kernel implementation used by newer kernels.

All I can tell you is the number one complaint of the users of the kernel models you speak of is that wireguard is not working as fast as it should albeit is operating faster than openvpn which we already knew was going to be the case.

 

[Paul Smedley]

Installed on the following:
2 x AX58U's which are AI Mesh nodes hanging off an AX68U running in AP Mode (which is still on 386.7_2)
1 x AX56U which is an AI Mesh node handing off an AX3000 (aka AX58U) running in AP Mode (which is also updated to 388.1 alpha 1)

All good so far