I am running four TP-Link Archer AX23 devices as access points. I reboot the devices every night by cron (that's back from Archer C7 times and having problems from time to time with wifi bandwidth when not rebooting the devices every 1 to 7 days) and noticed that the devices are not coming up again every time like with 23.05.4 and 23.05.3 (I migrated to AX23 with 23.05.3). In fact, one of four devices is failing every night and is offline. Only one LED (power) is on, the rest is off. Unplugging power and booting the device did help every time for the last three days.
Anyway I just downgraded to 23.05.4 and I hope that this really is a problem with the 23.05.5 firmware.
Does anybody else experiencing these problems? Maybe also with other devices?
It might. But is not reachable with its IP over the network. Also no wifi. So I unplugged the device this, another yesterday morning and a third the morning two days ago. The configuration is more or less identical, as the devices are. So it is not a device problem but something which changed from .4 to .5 - hopefully I see all devices up tomorrow morning and the following days.
One in N more or less is ASLR related that kernel leaves initialised memory where bootloader expects zeroes. Should repeat with same intensity at rebooting in a row.
Okay interesting. But I cannot do something about that, correct? It needs to be fixed in a upcoming version? Something changed because with the same devices I did not experience problems for months, rebooting the devices every night.
Without derial rog vhances are close to zero to discover at which point of (re-)boot it stops. Without that option i'd say to try to stabilize it as it is, like leave one AP up forever and check whether it accumulates fatigue of sorts ever?
Yeah not rebooting anymore or not so often would be a workaround. But the problem would still be there.
Did something change from .4 to .5 which would explain the problems I am experiencing here? Also I do not think that I am the only use with this hardware (and I would guess that such a thing is not limited to that specific model, but maybe to ramips-mt7621, but there are more router models with that chip) and also not the only one who reboots the devices.
There are many places pre-initialized devices or memory may fail some code. Unless serial log clearly points to what is wrong it is like hundred-some components to look through.
Looks like I have the same issue. My AX23 may randomly boot/reboot without network, only Power led is on.
AX23 v1.20
Latest OpenWRT from releases
openwrt-23.05.5-ramips-mt7621-tplink_archer-ax23-v1
Linux version 5.15.167 (builder@buildhost) (mipsel-openwrt-linux-musl-gcc (OpenWrt GCC 12.3.0 r24106-10cc5fcd00) 12.3.0, GNU ld (GNU Binutils) 2.40.0) #0 SMP Mon Sep 23 12:34:46 2024
Sometimes it boots and gets IP, and LAN led comes up and it works fine until a reboot, where it seems to boot, but stays offline inaccessible.
The serial console is working, the router is alive. But network is not usable. And what is the most interesting, when try to check the network status using "ip a" or "ifconfig" - the command hangs forever, while the console itself stays alive, and you still get kernel messages. But you cannot kill the command and type anything.
This is the end of boot log:
Sat Oct 12 07:15:13 2024 daemon.notice netifd: Interface 'loopback' is now up
Sat Oct 12 07:15:13 2024 user.notice firewall: Reloading firewall due to ifup of lan (br-lan)
Sat Oct 12 07:15:16 2024 kern.info kernel: [ 26.740048] mt7530-mdio mdio-bus:1f lan1: Link is Up - 1Gbps/Full - flow control off
root@OpenWrt:/# [ 88.074007] mt7530-mdio mdio-bus:1f lan1: Link is Down
root@OpenWrt:/#
root@OpenWrt:/#
root@OpenWrt:/#
root@OpenWrt:/#
root@OpenWrt:/# ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1): 56 data bytes
ping: sendto: Network unreachable
root@OpenWrt:/#
root@OpenWrt:/#
root@OpenWrt:/# ifconfig
^C^C^C^C^C^C
Is this happening only when manually restarting it or only "over the day"? I experienced a new problem for myself: I did not downgrade every device to .4 here and one of the .5 devices was once not reachable anymore yesterday. Same effect. But I did not check the console like you did.
To diagnose this correctly, one really would need a boot log, so a serial connection is required. As brada4 points out, it can just be about anything. The fact multiple people experience this issue does not make it easier to diagnose.
So far, this is the equivalent of 'it does not work'. You cannot expect someone to try and reproduce something as generic as that, since it could basically mean anything.
I had it two times yesterday evening and tonight. Without rebooting, so just on "normal" operation. Se the devices seem to have crashed. In the evening, the device came back up including network, during the night, not.
@ptlink Main branch just saw a fix for MTK Ethernet, might be worth trying a main build once that fix has been incorporated (or you can compile yourself).
If the problem disappears, try an older main image to see if that particular commit fixed it.
Uh oh ouch, the issue has just happened to me again with the latest master. Looks like it is harder to reproduce now, but it still randomly fails to bring up ethernet on boot
23.05.4 - works fine
23.05.5 - fails
The only related to mtk ethernet commit between those releases was:
I've got same result 23.05.4 works fine, 23.05.5 - fails.
I've also tried the 24.10.0 it works a bit better than 23.05.5 - but the Ethernet periodically lost and get connection, so revert back to 23.05.4 which seems stable on AX23
But the problem would still be there.