System hang/hard freeze on COMFAST CF-WR632AX (U-Boot layout) with 25.12.0-rc3 and rc4
Description:
I am experiencing consistent system instability with the COMFAST CF-WR632AX (U-Boot layout) using the latest 25.12.0-rc3 and rc4 builds. After some time, the router suffers a hard freeze:
Wi-Fi networks (SSIDs) disappear completely.
Wired Ethernet connection (LAN) becomes unresponsive.
The device requires a physical power cycle to recover.
Comparison:
Using the exact same package set and configuration, the ImmortalWrt snapshot works perfectly stable on this hardware. The issue seems specific to the current OpenWrt release candidates.
Debug Information:
Unfortunately, since the router freezes completely and is located at a remote site, I cannot provide serial logs or dmesg output at this moment.
I am willing to provide any additional configuration details or perform specific tests within my capabilities to help diagnose and resolve this issue.
Try to run logread -f in a ssh session and wait for the crash. It MAY catch the last lines before device crashes.
Please connect to your OpenWrt device using ssh and copy the output of the following commands and post it here using the "Preformatted text </> " button (red circle; this works best in the 'Markdown' composer view in the blue oval):
Remember to redact passwords, VPN keys, MAC addresses and any public IP addresses you may have:
ubus call system board
cat /etc/config/network # very careful with regard to VPN secrets!!!
cat /etc/config/wireless
cat /etc/config/dhcp
cat /etc/config/firewall
That's how I understand it. The router isn't mine and I don't have access to it, but I'll respond and provide information if I can.
I've disabled WED for now, and it's working. This router has non-standard interfaces. Usually, WAN+WAN6=eth1, but here it's WAN+WAN6=wan. I don't know if this matters, but the same GL.iNet GL-MT3000 router with the same settings works fine on OpenWRT. When I get a chance, I'll do what you asked.
It works without WED. Experimentation is prohibited(((. Since it works, there are no error logs. But other routers work with WED enabled. It's clear that modern routers are quite powerful and can handle dozens of wireless clients without much load, but why this feature causes freezes on this particular router is unclear.
Bug Report: System Lockup and Network Collapse on Comfast CF-WR632AX (MT7981B)
Device Information:
Model: Comfast CF-WR632AX
Architecture: MediaTek Filogic 820 (MT7981B)
OpenWrt Version: 25.12.0-rc5 (Mainline/Master)
Comparison Device: GL.iNet GL-MT3000 (Beryl AX) running the same version.
Description of the Issue: The Comfast CF-WR632AX experiences a total system freeze under network load. Unlike standard interface drops, this issue results in a "hard lockup":
Wired Connectivity: All Ethernet ports (WAN/LAN) stop responding.
Wireless Connectivity: All Wi-Fi SSIDs (2.4GHz and 5GHz) immediately disappear from the air.
System State: The device becomes completely unresponsive (SSH/WebUI inaccessible) and requires a hard power cycle to recover.
Technical Analysis and Comparison:
1. Interface Naming Discrepancy:
GL-MT3000: Maps the 2.5G WAN port to eth0.
+1
CF-WR632AX: Maps the 2.5G WAN port to a dedicated device labeled wan.
+1
In the Comfast DTS, the wan interface is defined as a separate device: network.@device[1].name='wan', whereas the MT3000 uses network.@device[1].name='eth0'.
+1
2. Interrupt (IRQ) Distribution Anomalies: Analysis of /proc/interrupts shows a severe imbalance in how ethernet interrupts are handled on the CF-WR632AX compared to the MT3000:
GL-MT3000: Ethernet interrupts (lines 76 and 77) are effectively distributed between cores (CPU0: ~0.6M, CPU1: ~1.1M ).
CF-WR632AX: Recorded interrupt activity is significantly lower and poorly distributed (~3.3k on CPU0 and ~7.8k on CPU 1).
Enabling packet_steering on the CF-WR632AX appears to trigger the system-wide lockup, likely due to IRQ collisions or improper mapping in the DTS.
3. Hardware Features (ethtool): The ethtool -k wan output for the CF-WR632AX confirms that hardware offloading features are active by default, which may be contributing to the instability if the DTS implementation for the wan device is incompl ete.
Steps to Reproduce:
Flash OpenWrt 25.12.0-rc5 on Comfast CF-WR632AX.
Configure WAN using the default wan device map ping.
Enable packet_steering and initiate high-bandwidth traffic via the 2.5G WAN port.
Result: The system freezes completely; Ethernet link is lost, and Wi-Fi radios stop broadcasting.
Expected Behavior: The system should remain stable under load, with interrupts balanced across cores as seen on the GL-MT3000, without causing a total hardware lockup.
ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: wan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether XX:XX:XX:XX:XX:01 brd ff:ff:ff:ff:ff:ff
3: lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br-lan state UP mode DEFAULT group default qlen 1000
link/ether XX:XX:XX:XX:XX:02 brd ff:ff:ff:ff:ff:ff
4: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
link/ether XX:XX:XX:XX:XX:02 brd ff:ff:ff:ff:ff:ff
10: phy0-ap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP mode DEFAULT group default qlen 1000
link/ether XX:XX:XX:XX:XX:03 brd ff:ff:ff:ff:ff:ff
12: phy1-ap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP mode DEFAULT group default qlen 1000
link/ether XX:XX:XX:XX:XX:04 brd ff:ff:ff:ff:ff:ff
uci show network | grep "@device"
network.@device[0]=device
network.@device[0].name='br-lan'
network.@device[0].type='bridge'
network.@device[0].ports='lan'
network.@device[1]=device
network.@device[1].name='wan'
network.@device[1].macaddr='XX:XX:XX:XX:XX:01'
cat /proc/interrupts | grep -E "eth|wan|mtk"
76: 3301 0 GICv3 229 Level 15100000.ethernet
77: 133 7870 GICv3 230 Level 15100000.ethernet
ethtool -k wan
Features for wan:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
generic-segmentation-offload: on
generic-receive-offload: on
hw-tc-offload: on
ethtool --show-eee wan
EEE status: disabled
ssh MT3000
Summary
ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether YY:YY:YY:YY:YY:01 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br-lan state UP mode DEFAULT group default qlen 1000
link/ether YY:YY:YY:YY:YY:02 brd ff:ff:ff:ff:ff:ff
6: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
link/ether YY:YY:YY:YY:YY:02 brd ff:ff:ff:ff:ff:ff
uci show network | grep "@device"
network.@device[0]=device
network.@device[0].name='br-lan'
network.@device[0].type='bridge'
network.@device[0].ports='eth1'
network.@device[1]=device
network.@device[1].name='eth0'
network.@device[1].macaddr='YY:YY:YY:YY:YY:01'
cat /proc/interrupts | grep -E "eth|wan|mtk"
76: 598793 0 GICv3 229 Level 15100000.ethernet
77: 0 1125058 GICv3 230 Level 15100000.ethernet
ethtool -k eth0
Features for eth0:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
generic-segmentation-offload: on
generic-receive-offload: on
hw-tc-offload: on
ethtool --show-eee eth0
EEE status: disabled
What versions of OpenWrt are you running, mostly ports are renamed to printed labels with upgrades, even they go with default eth0/eth1 names at initial support sometimes.
Please avoid posting unverified AI slop.
If there is a bug please verify slopbot claim about eg hw offloads by selectively disabling them YOURSELF.
We are not 4th line support for your chatbot.
This is better than my attempts to explain everything in English))). The COMFAST CF-WR632AX (OpenWrt U-Boot layout) doesn't have an official stable version. Everything is based on a “scientific experiment” on 25.12.0 rc2, 3, 4, and 5. A possible issue is incorrect processing due to non-standard interface naming. This is my guess, not the AI's. It just formatted it nicely.
These two routers are very similar in hardware, and with the same software and settings, you'd expect them to work the same way. But the Beryl works 24/7, while the Comfast would freeze or lose internet connection. I found this difference. If that's not the cause, then what is? Shouldn't they work the same way, or am I wrong?
Thank you for your feedback but please verify AI slop and post the facts. AI told you to treat ethtool -k/-K settings as suspect. That claim might be correct - disable thse offloads, then enable them one by one and find the culprit?
irqbalance is extra package, nothing to do with hardware support quality for example. By default irq-s shoot on CPU0 and packet steering distributes processing to other cores.
It needs profound human analysis, and you are one, and you have hardware in your hands.
What's clear is that nothing is clear. If all routers are supposed to work differently with the same inputs, then taking the same bus to work can lead to different results. To get to work, you have to try getting off at different stops and even going in the opposite direction. And even that doesn't guarantee results.
I understand.
Thank you!
Is there anyone reasonable who can explain what I'm doing wrong? The router is working as it should, but I'm stuck instead? Or is this all I can get on this forum regarding this issue?
I have 3 of these devices running at my parents’ house as dumb APs - wired to upstream ISP provided router. One of them runs WireGuard server.
They have been exceptionally stable. But I’m running stock uboot.
I don’t know why that would cause issues for a device if it’s already up and running, but since you’re running OpenWRT uboot, maybe you should upgrade that?
I know in snapshot build there have been recent fixes for the OpenWRT mediatek uboot…
I should add that I don’t use WED as you’ve stated you do. So as Brada suggested, turn that off if it solves your problem and move on for now. Unfortunatly nobody here will be able to guess as to why it’s not working for you I’m afraid.
