Could the Wi-Fi Router Instability Be Caused by the RTL8723BS Wireless Chip?
After installing Debian 12 on the palm-sized stick PC “MS-NH1-W10" and starting to operate it as a low-power, always-on server, I encountered a suspicious network issue. Whenever I performed package updates or communication-heavy tasks on the stick PC, its Wi-Fi connection would suddenly drop.
What was puzzling was that, completely synchronized with the stick PC’s disconnection, all other Wi-Fi devices in the home—such as smartphones and laptops—simultaneously lost network connectivity. After waiting a few minutes, all devices would reconnect automatically, but every time the stick PC was put under load, the entire home Wi-Fi would experience brief, repeated outages. Suspecting that it wasn’t just a poor signal on a single client device, but rather that the main router itself was crashing, I began examining the logs to investigate the cause.
Hypothesis Derived from Router Log Timestamp Correlation and RTL8723BS Behavior
I extracted the system logs from the router (ASUS RT-AX86U Pro). As a result, tucked away among the firewall traffic logs, the decisive moment when the Wi-Fi access point process crashed was recorded.
Sep 13 19:17:15 wlceventd: wlceventd_proc_event(662): eth6: Disassoc 80:A5:89:xx:xx:xx, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0 Sep 13 19:17:24 kernel: CSIMON: CSIMON[1.1.0] Initialization Sep 13 19:17:36 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind 84:30:95:xx:xx:xx, status: 0, reason: Disassociated due to inactivity (4), rssi:-54 Sep 13 19:17:36 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind 84:30:95:yy:yy:yy, status: 0, reason: Disassociated due to inactivity (4), rssi:-60 Sep 13 19:17:40 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind 84:30:95:zz:zz:zz, status: 0, reason: Disassociated due to inactivity (4), rssi:-54 Sep 13 19:17:42 wlceventd: wlceventd_proc_event(685): eth6: Auth 84:30:95:xx:xx:xx, status: Successful (0), rssi:0
Tracing the logs chronologically made the following behavior clear:
At 19:17:15, the Realtek RTL8723BS built into the stick PC (OUI: 80:A5:89) disconnected from Wi-Fi (Disassoc).
Just 9 seconds later (19:17:24), the internal traffic monitoring daemon (CSIMON) on the router detected an anomaly and performed re-initialization.
Immediately following, between 19:17:36 and 19:17:40, forced disconnections (Deauth) were fired off in rapid succession toward all devices connected to the same Wi-Fi band (eth6).
At 19:17:42, the router’s Wi-Fi access point function recovered, and all disconnected devices simultaneously initiated re-authentication (Auth).
What should be noted here is “Disassociated due to inactivity (4)" recorded as the reason for disconnection for the other devices. This indicates Reason Code 4 (timeout disconnection due to packets not arriving for a certain period) defined in the IEEE 802.11 international Wi-Fi standard.
Since it is statistically unlikely that multiple independent devices in the home would spontaneously stop communicating at the exact same second, it is expected that the router became unable to respond for some reason, triggering timeouts (Reason Code 4) in a cascading fashion.
So, why did the router freeze right after the stick PC disconnected? When I investigated the overseas community Reddit, I found multiple reports of unstable behavior of the RTL8723BS in Linux environments.
F38 – RTL 8723BS – WiFi Connection Drops ~5 Minutes after Boot
byu/TheSackveganAcadian inFedora
RTL8723BS "coalesce failed with error -22" after upgrade
by inarchlinux
The threads above report issues where the link drops on its own just a few minutes after connection, or driver failures throwing packet transmission errors (coalesce failed). While I cannot assert this definitively without diving into raw radio packet analysis, I surmised that the RTL8723BS became unstable due to load or heat, transmitting abnormal packets or disconnection signals, which in turn caused the wireless router’s processing to break down, triggering a reboot (reset).
Completely Disabling the Built-in Driver and Offloading to USB
For hardware- and driver-level issues that cause the main router to crash, trying to buy time by tweaking power-saving settings on the Linux kernel side is not a wise move. I decided it was safer to completely isolate the suspected built-in Wi-Fi chip from the OS and switch to a USB interface.
Blacklisting the Built-in Driver (r8723bs)
Create a configuration file to prevent the problematic module from loading when the OS boots.
sudo tee /etc/modprobe.d/blacklist-rtl8723bs.conf << 'EOF' blacklist r8723bs EOF
Unload the currently loaded module.
sudo modprobe -r r8723bs
Check the interfaces to confirm that the built-in Wi-Fi has disappeared.
ip link show wlan0
If you get the response “Device “wlan0" does not exist", the disabling of the built-in chip is complete.
Conclusion
An issue occurred where the entire home Wi-Fi disconnected under network load on the stick PC “MS-NH1-W10". Analyzing the router logs revealed that immediately after the built-in chip “RTL8723BS" disconnected, the access point process crashed abnormally, causing all devices to disconnect simultaneously. Communities like Reddit have also pointed out instances where the same chip exhibits unstable behavior. As a countermeasure, I decided to blacklist the built-in driver to silence it completely. As a result, the router crashes stopped entirely, and stability of the home LAN was achieved. When dealing with an unstable built-in chip, the best strategy is not to over-invest in troubleshooting, but to cut your losses and switch to an external one.