Setup: Chateau 5G ax (S53UG+M-5HaxD2HaxD) ether3 ↔ cAP ax ether1, shielded Cat7 run with a PoE injector powering the cAP. Both on RouterOS 7.23.3 (stable). The link had been running clean at 1 Gbps for weeks.
What happened: overnight — no config change, no update, no reboot (10+ days uptime on both ends) — the WLAN behind the cAP died. Findings:
- The link stayed "link-ok" at 1Gbps full-duplex the whole time; not a single link down/up was logged on either side.
- Direction cAP→Chateau still delivered frames, but ~2.5 % arrived corrupt: 99,338 rx-fcs-error + 59,787 rx-fragment on the Chateau port.
- Direction Chateau→cAP was effectively dead: the cAP's rx-fcs-error showed only 61 (!) in total, so frames from the Chateau didn't even arrive as corrupt frames. DHCP offers never reached any WLAN client.
- This asymmetry doesn't fit cable damage as far as I can tell: 1000BASE-T uses all four pairs bidirectionally, so a bad pair should degrade both directions.
Workaround first: limiting the Chateau port to advertise=100M-baseT-full brought the link up instantly clean — 94 Mbps wire speed both ways, zero errors under load.
The interesting part: while running at 100M, the Chateau's monitor showed link-partner-advertising with only the 10/100 modes — the 1G capability bits from the cAP were missing, although the cAP was verifiably configured to advertise the full list. After setting the Chateau back to the full advertise list, autoneg completed with all partner bits present, the link trained at 1 Gbps and has been completely clean since: bandwidth-test 926/940 Mbps per direction plus full-duplex stress 860+770 Mbps simultaneously — zero fcs/align/fragment errors on both sides afterwards.
So the whole outage looks like a wedged PHY/training state that survived for days simply because the link never renegotiated — and it was cured by nothing more than forcing two renegotiations (down to 100M, back to 1G). cable-test only reports "link-ok" on these IPQ-6010 platforms (no per-pair TDR), so I can't fully rule out a marginal contact that happened to re-seat itself, but the evidence points at the PHY.
Questions:
- Is this a known issue on IPQ-6010 based devices (Chateau ax / cAP ax) on 7.2x?
- Is there a way to inspect or reset PHY/autoneg state short of bouncing or renegotiating the link?
- Could downshift or EEE be involved? Any hidden knobs worth checking?
In case it helps others, this watchdog now runs on the Chateau — it samples the rx-fcs-error delta and cAP reachability every 5 minutes and automatically falls back to 100M (with a log warning) if the corruption ever returns:
/system scheduler add name="ether3-gig-guard" interval=5m on-event=":global e3fcs; :global e3pf; :if ([:typeof $e3fcs]!=\"num\") do={:set e3fcs [/interface ethernet get ether3 rx-fcs-error]}; :if ([:typeof $e3pf]!=\"num\") do={:set e3pf 0}; :local now [/interface ethernet get ether3 rx-fcs-error]; :local d ($now-$e3fcs); :set e3fcs $now; :if ([/ping 192.168.100.15 count=5 interval=200ms]<3) do={:set e3pf ($e3pf+1)} else={:set e3pf 0}; :if (($d>50) or ($e3pf>=2)) do={/interface ethernet set ether3 advertise=100M-baseT-full; /log warning (\"ether3-gig-guard: Fallback 100M\"); /system scheduler disable [find name=\"ether3-gig-guard\"]}"