I have an idea how AQR is connected (Its on a different MDIO bus), but I just lack time to do it and then bother somebody to test it.
So, if I understand correctly, that change to the dts in the above post most probably won't work with B1, right.
I meant that you just had a look at the changes made to the dts with the intention to allow the copper 10G LAN port to work with B1 and confirm if changes looked OK.
Then I can try it on B1.
What speeds are you guys getting over the SFP+ port? I have a fiber ONU SFP 10gb plugged in and out the WAN I'm only getting 1200/800 Mbps. That's on my 5000/5000mbps fiber connection via frontier. I am using the NSS build if that makes a difference.
This thread is not about NSS, but vanilla non-NSS OpenWrt.
1 Like
does the NSS build for the RT-AX89X work for the 10gbps port? what revision is your router?
I ran some iperf3 tests using a fiber optic SFP+ transceiver (not using NSS, just regular upstream OpenWRT build). I think max I got was 2.5 Gbps. That's the limit of the CPU I think, since that Qualcomm routing accelerator chip is unusable with upstream kernel.
To route something closer to 10 Gbps on a CPU without using some special ASIC like that you need a significantly more powerful CPU. There are compact routers like that, check for example DEC750 (comes with Opnsense which is using FreeBSD) which does it using AMD Ryzen embedded.
My conclusion is that if you want 10 Gbps routing with upstream OS, don't use common ARM routers - nothing that I know has upstream support for accelerator chips. That leaves x86_64 options like above for the router. You can then use something else for WiFi as an access point.
I got a little lost on this but now I am in a pickle. I installed the original Google-Drive firmware and all is working well with my device. But I want to go to snapshots (or release if there is one for this device). But I believe there is an issue with the partitioning correct? Is there a way to upgrade to the latest software without having to connect console and delete the partitions?
i have the b2 revision. everything works great and installation was a breeze. any questions or anything i can be of help supporting the RT-AX89X welcome.
by the way i installed 24.10.0 as follows:
- Upload openwrt-qualcommax-ipq807x-asus_rt-ax89x-initramfs-factory.trx
via the stock firmware.
Administration -> Firmware Upgrade -> Manual Firmware update (Upload)
After flashing, the device will reboot with OpenWrt initramfs, and it can
be accessed via any of the LAN ports, using LUCI.
I flashed sysupgrade the usual way...
Anyone here having the B1 revision (currently on rev. B1 the 10G copper port doesn't work) and JTAG connected willing to try this DTS and share if the port will work with it.
I don't have a JTAG connected, otherwise I could try it.
1 Like
Same issue here with a B2, with the stock firmware I was getting around 2Gbps on iperf3 with a DAC between the router and an X520-DA2. Switched to OpenWrt 24.10.0 (r28427-6df0e3d02a) and now the SFP+ is unusable.
When I plug the DAC in the router, nothing happens in NetworkManager. When I unplug it, I will usually get this:
NetworkManager[1268091]: <info> [1744341764.6782] device (enp5s0f1): carrier: link connected
NetworkManager[1268091]: <info> [1744341764.6783] device (enp5s0f1): state change: unavailable -> disconnected (reason 'carrier-changed', managed-type: 'full')
NetworkManager[1268091]: <info> [1744341764.6800] policy: auto-activating connection 'Wired connection 3' (c1a3d95e-c9dd-35b6-bade-d59b83b02a94)
NetworkManager[1268091]: <info> [1744341764.6801] device (enp5s0f1): Activation: starting connection 'Wired connection 3' (c1a3d95e-c9dd-35b6-bade-d59b83b02a94)
NetworkManager[1268091]: <info> [1744341764.6802] device (enp5s0f1): state change: disconnected -> prepare (reason 'none', managed-type: 'full')
NetworkManager[1268091]: <info> [1744341764.6803] device (enp5s0f1): state change: prepare -> config (reason 'none', managed-type: 'full')
NetworkManager[1268091]: <info> [1744341764.6905] device (enp5s0f1): state change: config -> ip-config (reason 'none', managed-type: 'full')
NetworkManager[1268091]: <info> [1744341764.6913] dhcp4 (enp5s0f1): activation: beginning transaction (timeout in 45 seconds)
NetworkManager[1268091]: <info> [1744341770.6817] device (enp5s0f1): state change: ip-config -> unavailable (reason 'carrier-changed', managed-type: 'full')
NetworkManager[1268091]: <info> [1744341770.6937] dhcp4 (enp5s0f1): canceled DHCP transaction
NetworkManager[1268091]: <info> [1744341770.6937] dhcp4 (enp5s0f1): state changed no lease
After many cycles of plugging/unplugging the DAC, only once did I get this same output in the kernel log:
[ 6526.773600] nss-dp 3a003000.dp5-syn 10g-sfp: PHY Link up speed: 10000
[ 6526.773745] br-lan: port 1(10g-sfp) entered blocking state
[ 6526.779037] br-lan: port 1(10g-sfp) entered forwarding state
[ 6527.813621] nss-dp 3a003000.dp5-syn 10g-sfp: PHY Link is down
[ 6527.815642] br-lan: port 1(10g-sfp) entered disabled state
It's all very inconsistent. I can help debug but have no idea where to start.
DAC never worked for me with it, but fiber optic tranceiver did.
More exactly, I used the pair of these:
It's BiDi simplex, so works with a single cable. You need them paired like that to work.
Compatible cable example: https://www.fs.com/products/40435.html
1 Like
Thanks for the details on the transceivers that do work.
Yeah that's what I read from your posts, what's even weirder is that it works for robimarko with the same DAC you have and the same B2 revision, but for retzs64, you and I it doesn't. Could it have to do with the device that's on the other side? It's the only difference I see. Maybe it's power related?
Did a bit more testing today. Plug the DAC in, wait a few seconds for the OpenWrt logs to refresh, unplug it. Refresh the page to make sure. Nothing in the logs. I go do something else, and around 30 minutes later I come back to the same 5 kernel log lines as in my previous post. I have no idea why, as nothing interacted with the router during this time, but this explains why seeing these lines for the first time was a surprise, it's because they don't appear as soon as you plug the DAC in, but at some random point later. So I tried something else. Plug the DAC in, wait an hour. I wanted to see if something was gonna happen while it was plugged in, but nothing, so I unplugged it and waited again. 46 minutes later, they finally showed up (that's from the system log this time so there are two more lines):
Fri Apr 11 23:49:15 2025 kern.info kernel: [10290.489804] nss-dp 3a003000.dp5-syn 10g-sfp: PHY Link up speed: 10000
Fri Apr 11 23:49:15 2025 kern.info kernel: [10290.489957] br-lan: port 1(10g-sfp) entered blocking state
Fri Apr 11 23:49:15 2025 kern.info kernel: [10290.495235] br-lan: port 1(10g-sfp) entered forwarding state
Fri Apr 11 23:49:15 2025 daemon.notice netifd: Network device '10g-sfp' link is up
Fri Apr 11 23:49:16 2025 daemon.notice netifd: Network device '10g-sfp' link is down
Fri Apr 11 23:49:16 2025 kern.info kernel: [10291.529810] nss-dp 3a003000.dp5-syn 10g-sfp: PHY Link is down
Fri Apr 11 23:49:16 2025 kern.info kernel: [10291.530061] br-lan: port 1(10g-sfp) entered disabled state
Next I went back to the stock firmware using your guide (thank you and thanks to remittor for facinstall), and as expected the SFP+ interface does work there, so the DAC is not the issue. Even tried DD-WRT (04-10-2025-r60662) just in case, and it has the same problem as OpenWrt.
1 Like
long shot:
use with some caution
ethtool -s 10g-sfp speed 10000 duplex full autoneg off
(Replace 10g-sfp with the correct kernel interface name found via ip link)
tell us
I have compiled an OpenWrt build with the changed DTS with the hope it will have a working 10G copper LAN port for revision B1. Is there anyone having B1 with UART connected who wants to try it and check if the 10G copper port will work.
Here's the result with ethtool:
root@OpenWrt:~# ethtool -s 10g-sfp speed 10000 duplex full autoneg off
Cannot set new settings: Invalid argument
not setting speed
not setting duplex
not setting autoneg
and with ethtool-full:
root@OpenWrt:~# ethtool -s 10g-sfp speed 10000 duplex full autoneg off
netlink error: link settings update failed
netlink error: Invalid argument
Some more testing, I left the router on for 5 hours with nothing but an ethernet cable plugged in one of the yellow ports (lan7) for LAN access. The 5 lines appeared 26 times. Minimum interval between two instances is 12.48 seconds, max is 47 minutes, average is 11 minutes.
I then plugged the DAC in and no more kernel messages for 2 hours. Unplugged it, and exactly 10 minutes later they were back. Most of the time this is what I get in dmesg on the other side (PC) when the DAC is unplugged:
[37504.430100] ixgbe 0000:05:00.1 enp5s0f1: NIC Link is Up 10 Gbps, Flow Control: RX/TX
[37504.430545] ixgbe 0000:05:00.1 enp5s0f1: NIC Link is Down
After all of this I noticed something that might be interesting:
Maybe the receive errors are part of the problem?
Install the current snapshot build. The drivers will be newer, and this issue might have been fixed (or changed). Be aware snapshots can be unstable.
The evidence strongly points towards a software/driver issue within your OpenWrt build.
Tried snapshot r29220-66b5ed7a4e and it's exactly the same. Only new thing I learned is that the packet activity shown in the screenshot in my previous post happens while nothing is plugged in the SFP+ port, so I don't even know how it's transmitting anything and dropping ghost packets.
@robimarko, with which version(s) of OpenWrt can you confirm that the SFP+ interface works correctly with your FS SFP-10G-PC02 DAC on your B2? Forgot to say mine is a SFP-H10GB-CU3M even though it shouldn't matter what model it is.
Honestly, I have no idea what was the specific version when testing, but it really should not matter as SSDK did not change since then and we are relying on it and not the proper kernel SFP bus driver.
I've taken the risk and flashed the build with the changed DTS and successfully bricked the B1 revision. It won't boot anymore and reboots itself after several seconds.
Now if anyone wants to help, you are welcome.
I'll probably have to open the box first and connect the UART cable.
When I press the reset button and turn it on I have WAN led on in red color and Power LED blinks in white. Does it expect tftp connection?
@Errand9501 I don't know if this is somehow related but have you seen this commit.
1 Like
Make sure the router is powered off.
Press and hold the Reset button.
While holding Reset, plug in the power adapter.
Continue holding Reset until the Power LED starts blinking slowly (white in your case). This indicates it's in rescue mode. Release the Reset button.
Open your TFTP client software.
Set the TFTP server/host address to the router's default recovery IP, which is almost always 192.168.1.1 for ASUS.
Select the stable openwrt factory/recovery firmware file you downloaded. (if it doesn't work revert to the asus orig. firmware)
Set the transfer mode to binary or octet.
Initiate the upload (PUT/Send)..
wait. it should reboot itself
1 Like