hello! i’d like to preface this by saying i’m a software engineer, not a network engineer. i just want a homelab as the end result and don’t really want to learn about networking, so i’ve been relying heavily on ai to guide me to that end.
i bought a smart plug and connected it to my desktop computer. i tested switching it off using home assistant and my entire server went down. i switched the plug back on manually and everything reconnected way quicker than expected. after lots of debugging, i suspect a firmware bug.
i’m leaving this here in hopes for a firmware bug fix or to help someone else in the future. i placed my nas in the first lan port and that fixes everything for me, so i’ve set up this rando account just to post this.
i had the ai write a bug report since this is all beyond my capabilities. the title of this post and the below output are directly from the ai’s output:
Summary
On the GL-BE9300 running firmware 4.9.0, br-lan has a single wired member (eth1.1), and that interface's carrier state appears to be tied to the link state of one specific physical LAN port rather than to its parent device eth1.
When that port loses link — cable unplugged, or the attached client powered off at the mains — the kernel marks eth1.1 as NO-CARRIER / LOWERLAYERDOWN and the bridge disables the port. Every wired LAN client is cut off simultaneously, even though each one's own PHY link is still up. Wi-Fi clients are unaffected. The outage persists indefinitely until link returns on that one port.
The parent device eth1 remains UP throughout, which is why I believe this is a bug: a VLAN interface's carrier should track its parent, not an individual switch member port.
Device / firmware
- Model: GL-BE9300 (Flint 3)
- Firmware: 4.9.0
- Switch driver: `rtl8372-mdio 90000.mdio:1d`
- Config note: a custom VLAN (ID 2) exists for a separate IoT segment (
eth1.2, CPU tagged, one LAN port untagged). Default LAN iseth1.1.
Expected behaviour
Unplugging a client from one LAN port affects only that client.
Actual behaviour
Unplugging the client on the affected port disables the bridge's only wired port, disconnecting all wired clients on all LAN ports.
Steps to reproduce
- Connect client A to the affected LAN port and client B to any other LAN port.
- Confirm the router can reach both (
ping). - Unplug client A's ethernet cable.
- Client B is now unreachable from the router and from every other client. Wi-Fi clients are unaffected.
- Reconnect client A. All wired clients recover immediately.
Reproduced identically by cutting mains power to client A while it was running, and by unplugging its cable alone with the machine still powered. It does not occur when client A is shut down gracefully with its PSU still connected, because the NIC stays energised on +5V standby and the link never drops.
Also reproduced with Network Acceleration set to software-only and fully disabled — the behaviour is independent of that setting.
Evidence
Router log at the moment the cable is pulled:
kern.info kernel: rtl8372-mdio 90000.mdio:1d: lan1 link down
kern.info kernel: br-lan: port 1(eth1.1) entered disabled state
daemon.notice netifd: VLAN 'eth1.1' link is down
ip -br link while the port is down — note eth1 is UP but eth1.1 is not:
eth1 UP <BROADCAST,MULTICAST,UP,LOWER_UP>
eth1.1@eth1 LOWERLAYERDOWN <NO-CARRIER,BROADCAST,MULTICAST,UP>
br-lan UP <BROADCAST,MULTICAST,UP,LOWER_UP>
The bridge flushes every dynamic eth1.1 entry. Before (wired clients present):
xx:xx:xx:xx:xx:01 dev eth1.1 master br-lan
xx:xx:xx:xx:xx:02 dev eth1.1 master br-lan
... (7 more wired clients)
xx:xx:xx:xx:xx:99 dev eth1.1 master br-lan permanent
After:
xx:xx:xx:xx:xx:99 dev eth1.1 master br-lan permanent
Only the router's own permanent entry remains. ip neigh splits cleanly along the wired/wireless boundary — every wired host goes INCOMPLETE/FAILED while Wi-Fi hosts stay REACHABLE.
Link-down on other LAN ports does not produce a VLAN 'eth1.1' link is down event; only the one port does. In my case the driver reports it as lan1 (physical port labels may differ from the case markings on this model).
Impact
Any client on that port becoming unreachable takes down the entire wired network. In my setup a smart plug switching off a desktop PC took my NAS offline for 30+ minutes, while Wi-Fi stayed up.
Workaround
Keep a permanently-powered device on the affected port. Note that leaving it empty is not viable — an unpopulated port means the wired LAN never comes up at all.
Request
Make eth1.1's carrier follow its parent eth1 (the CPU port), so that an individual switch member port losing link does not disable the bridge's wired port.