What's new

[384.16_Alpha Builds] Testing all variants

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

I'm not ready to start the beta cycle yet, but if people want to start testing things on the RT-AX56U and RT-AX58U, since they are two new models, then basically everything needs to be tested. Some of those things that I have noted down:

- IPSEC
- AiCloud
- Smart sync
- Repeater/AP mode (particularly the new Internet traffic meter in these modes)
- AiMesh (as either node or router)
- USB sharing disk performance over SMB
- Popular addons, and Entware

I only have an RT-AX58U, so I can't test anything myself on the RT-AX56U.
 
It's a bug in inadyn's freedns plugin, it fails to initialize a buffer before using it, causing the authentication hash to be randomly garbled. I'll send the fix upstream.
It's working now and cache in /tmp is there. :)
Thank you !
 
Maybe you first used a cable and afterwards Wi-Fi to connect to the router from the same device? In such case the MAC addresses of both your ethernet and Wi-Fi are known by your DNS. Solution: sit out the lease time or unplug the power and reboot again.
No since the device cant even use a cable ;-) That was what made it a bit extra surprising. The only thing I could think of was Virtualbox...but since nothing was running or even setup in it..
 
I wanted to share some of my findings recently, which I have been banging my head against the desk for. Not 100% sure when it started, but I noticed that after going back and install diversion that sometimes I would see my internet drop/pause, google homes would say they are disconnected, etc. I would see dnsmasq running taking 100% cpu, and high network processing. This led me to turn off diversion temporarily and I kept seeing other issues.

In the logs I would regularly see:
br0: received packet on eth3 with own address as source address
and in most cases, it was pre-pended with a rate limit of the same message showing thousands of them.

I also noticed that bcmsw_rx would take 1 full core (~25% usage) at certain times, not always correlating with the messages above. The CPU usage could be reproduced by unplugging my laptop which is hard-wired into the router directly. It was uncanny, I would unplug and bcmsw_rx would spin up, I would wait a bit and plug it back in, and it would spin back down.

Both things made me think something was wrong. I had recently done a factory reset and manual reconfigure, and I was ready to do it again, just in case. I turned off AIProtection, I turned off Protected Mgmt Frames and Wifi6 roam. I turned off Spanning Tree (and reboot), and still saw the log messages and errors. Then looking at my bridge information I would see entires like wds0.1.0 or wds1.0.6, which had the same MAC as the ethX or wireless. This got me thinking that it was tied to my AIMesh nodes running.

I turned off one node, and could still reproduce. I disconnected the other and boom the problem went away. I plugged back in and could reproduce the issue. I would notice that at the same time kworker (kernel tasks) would spin up and take ~8-10% CPU on the AiMesh node. Something was generating traffic since bcmsw_rx seems to run with network traffic.

I tried doing:
ifconfig wds1.0.6 down
for all the ones created (it varies on each boot, sometimes 4 sometimes 2 or 3). And guess what, it worked, the CPU spikes are not reproducible, and the log warnings of the same source address have gone away (the odd one here and there, think it is when my device moves from node to node).

I think that when my router comes up, the AiMesh nodes get WDS wireless backhaul channels setup. Sometimes more and sometimes less, I would guess depending on timing if it detects ethernet setup. Not sure of the pattern exactly yet. It seems that if I follow those wds* connections via ifconfig that I see the send traffic go up, to a few megabytes, so something is being sent. They have no IP address and show up in the Wireless Log page as well. They are gone once I disconnect them "down" via ifconfig.

So I have made myself a quick script to run on boot (with some delay) to turn these off manually for now.
Code:
#disconnect wds interfaces                                                                                                                                                 
for item in $(ifconfig | awk 'BEGIN {FS=" "} /wds/ {print $1}')                                                                                                           
do                                                                                                                                                                         
        echo "Disconnecting $item ..."                                                                                                                                     
        ifconfig $item down                                                                                                                                               
done

Will keep watching to see if it comes back or what else happens. Just waned to share my findings. Unsure if this is a bug or expected.

---- edit ----
running Merlin 384.16 alpha 1 - the original one. Have done a couple full resets and reconfigures as I have played around. This also lead me to the understanding that 160Mhz channels stop working once you AiMesh in a 68u and reboot. Seems to stick to just 80Mhz after that, but that makes sense.
 
@MacG32 after flashing to RMerlin firmware from stock, did you do a full reset/initialize and then minimally and manually configure the router to secure it and connect to your ISP?

It was a dirty flash. The graphical errors I pointed out in my first post were left over from Asus. I may be doing a full reset shortly as I'm experiencing minor errors with amtm addons, namely Skynet. When I schedule a reboot, it takes hours before it starts. Very strange behavior, as YazFi starts right away.

Edit: Went ahead and did a restore to factory defaults and initialize. Changed reboot time to not interfere with Skynet's checks. Will report back with any inconsistencies. So far, so good.
 
Last edited:
I'm not ready to start the beta cycle yet, but if people want to start testing things on the RT-AX56U and RT-AX58U, since they are two new models, then basically everything needs to be tested. Some of those things that I have noted down:

- IPSEC
- AiCloud
- Smart sync
- Repeater/AP mode (particularly the new Internet traffic meter in these modes)
- AiMesh (as either node or router)
- USB sharing disk performance over SMB
- Popular addons, and Entware

I only have an RT-AX58U, so I can't test anything myself on the RT-AX56U.
I see you have been busy in the supported models department, nice. I will test.
 
I'm not ready to start the beta cycle yet, but if people want to start testing things on the RT-AX56U and RT-AX58U, since they are two new models, then basically everything needs to be tested. Some of those things that I have noted down:
Running Alpha2 on an AX88U (Router) and AX58U (AiMesh Node) connected on Wireless.
Entware installed on both.

I had an issue (AX88U) with WAN uploads on 384.15 and the first Alpha. On the second Alpha1 and this Alpha2, WAN speeds have been rock steady for ~4 days.

AiMesh running well, 1-4 clients connected to the AX58U (seems to change over time).

Did some iperf3 testing between the AX88U and AX58U - WiFi speeds are good (average ~400Mbit/sec).

A large file SMB transfer from an AX200 connected laptop to the AX88U ran an average of 56MB/sec.

On the AX58U I have seen a few things in syslog.log:

FG80211-ERROR) wl_cfg80211_sta_info : GET STA INFO failed, -21
kck:
0000: 3c 77 fd 2c 88 a3 e4 4f 8f cc 4a c5 9d 82 c6 e4
kek:
0000: 69 9f 58 12 f5 b0 f9 0d b9 eb bf 0a ca 59 75 64
replay_ctr:
0000: 00 00 00 00 00 00 00 06

Also saw this shortly afterwards:
Mar 10 10:57:57 wsdd2[21433]: error: wsdd-mcast-v4: wsd_send_soap_msg: send
Mar 10 10:57:57 rc_service: udhcpc_lan 24785:notify_rc stop_ntpd
Mar 10 10:57:57 rc_service: waitting "start_dnsmasq" via udhcpc_lan ...
Mar 10 10:57:58 rc_service: udhcpc_lan 24785:notify_rc start_ntpd
Mar 10 10:57:58 rc_service: waitting "stop_ntpd" via udhcpc_lan ...
Mar 10 10:57:58 ntpd: Stopped ntpd
Mar 10 10:57:59 ntpd: Started ntpd

The node seems to be fine though. In fact, I have been using connmon since late yesterday on the AX88U to monitor the AX58U and ping times and jitter look very good.
 
Did a fresh install of 384.16_alpha2-g08edec78d0 on my AX88U, the page for managing SSL certs seems to be broken;

hJB4JxU.png
 
Upgrade RT-AX88U from V384.15 Final to V384.16_alpha1-gfcd95af015 via dirty firmware upgrade. 30+ devices (includes gaming, streaming, downloads, etc.) and all appears to be working for main AX88U router except the following issues:

- Under General | Network Map | Internet status showed "Disconnected", and the way to get it to reconnect, was to left click the World icon in the GUI, and turn the "Internet Connection" from ON to OFF and then back to ON
- Under Advanced Settings | LAN | LAN IP , my Host Name was defaulted back to the original Host Name, which I then renamed to what I originally had, and applied, which again disconnected by WAN connection, and got it back by the procedure above.


Upgrade RT-AX88U from V384.16_alpha1-gfcd95af015 to V384.16_alpha2-g08edec78d0 via dirty firmware upgrade. 30+ devices (includes gaming, streaming, downloads, etc.) and all appears to be working for main AX88U and all the issues above did NOT reappear upon reboot.
 
Mar 10 12:27:41 hostapd: eth6: STA IEEE 802.11: associated
Mar 10 12:27:41 kernel: CFG80211-ERROR) wl_cfg80211_change_station : WLC_SCB_AUTHORIZE sta_flags_mask not set
Mar 10 12:27:42 hostapd: eth6: STA RADIUS: starting accounting session D2CBA9D5EDE8B1DA
Mar 10 12:27:42 hostapd: eth6: STA WPA: pairwise key handshake completed (RSN)

Any idea what these log entries are there adding up quickly. I removed the mac addresses.
 
Running Alpha2 on an AX88U (Router) and AX58U (AiMesh Node) connected on Wireless.
Entware installed on both.

I had an issue (AX88U) with WAN uploads on 384.15 and the first Alpha. On the second Alpha1 and this Alpha2, WAN speeds have been rock steady for ~4 days.

AiMesh running well, 1-4 clients connected to the AX58U (seems to change over time).

Did some iperf3 testing between the AX88U and AX58U - WiFi speeds are good (average ~400Mbit/sec).

A large file SMB transfer from an AX200 connected laptop to the AX88U ran an average of 56MB/sec.

On the AX58U I have seen a few things in syslog.log:

FG80211-ERROR) wl_cfg80211_sta_info : GET STA INFO failed, -21
kck:
0000: 3c 77 fd 2c 88 a3 e4 4f 8f cc 4a c5 9d 82 c6 e4
kek:
0000: 69 9f 58 12 f5 b0 f9 0d b9 eb bf 0a ca 59 75 64
replay_ctr:
0000: 00 00 00 00 00 00 00 06

Also saw this shortly afterwards:
Mar 10 10:57:57 wsdd2[21433]: error: wsdd-mcast-v4: wsd_send_soap_msg: send
Mar 10 10:57:57 rc_service: udhcpc_lan 24785:notify_rc stop_ntpd
Mar 10 10:57:57 rc_service: waitting "start_dnsmasq" via udhcpc_lan ...
Mar 10 10:57:58 rc_service: udhcpc_lan 24785:notify_rc start_ntpd
Mar 10 10:57:58 rc_service: waitting "stop_ntpd" via udhcpc_lan ...
Mar 10 10:57:58 ntpd: Stopped ntpd
Mar 10 10:57:59 ntpd: Started ntpd

The node seems to be fine though. In fact, I have been using connmon since late yesterday on the AX88U to monitor the AX58U and ping times and jitter look very good.
I also get "kernel: CFG80211-ERROR) wl_cfg80211_sta_info : GET STA INFO failed, -21" and "kernel: CFG80211-ERROR) wl_cfg80211_change_station : WLC_SCB_AUTHORIZE sta_flags_mask not set".
AX88U by it self.
I have to select channel manually to get my configuration up to maximum speed to clients. Phone falls down to 192 in auto mode and 866 in manual channel (using Smart Connect).

RT-AX88U - just one of the latest Merlin firmwares and nothing else -
 
I have come to an odd observation: Every 4-5 hours my L2TP client gives the following error message:
/usr/sbin/l2tpd[603]: Too many retransmissions on tunnel (63126/41495); closing down
pppd[9205]: Terminating on signal 15

As a result of which it terminates the client and restarts the L2TP client and continuous as normal. There is no trigger for this. I checked if it is caused by the VPN provider but the other router I have keeps running (same config but with second Alpha1) and does not have this odd behavior.
To cut a long story short: periodically the L2TP client loses connection and restarts but has no clear trigger why it loses connection.
There is no correlation between the load on the router and the occurence of this event.
Any thoughts anyone?
 
RT-AX56U
Traffic Analyzer text looks to be not placed correctly. See attached image
 

Attachments

  • traffic analyzer.PNG
    traffic analyzer.PNG
    173.8 KB · Views: 252
RT-AX56U
Traffic Analyzer text looks to be not placed correctly. See attached image
Hover your cursor over it.......you will be surprised. :)
 
  • Like
Reactions: a5m
So far Alpha 2 is running fine for me. Main features used include - routing, Secure DNS (Cloudflare), Guest and private WiFi, Port forwarding. No add on apps.

*** Edit *** I still occasionally see the router shut down when performing a "Reboot" from the GUI. All LEDs on front panel "off". I then have to use the hard power off/on switch to boot up.
 
Last edited:
Did a fresh install of 384.16_alpha2-g08edec78d0 on my AX88U, the page for managing SSL certs seems to be broken;

hJB4JxU.png
I don't have the problem with mine. I use ddns.
 
I don't think the Internet Traffic overview is very accurate. I ran Speedtest which shows 230 MB download but the Internet Traffic overview only shows 44 MB. Not sure where it is pulling data from. The Traffic Analyzer seems more accurate. What are your thoughts on the accuracy?
Speedtest.net shows the speed in Mbps, while Internet Traffic displays it as MB/s.
So, if you are getting 230 Mbps on speedtest, then Internet Traffic should show ~28 MB/s.
Works fine for me, I get 496 Mbps on speedtest and 62 MB/s on Internet Traffic.
 

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

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

Staff online

Top