Wily raconteur

A firmware update broke my fiber WAN. The device that broke it reported itself perfectly healthy on every check I could think of. Here is how I found the fault, the seven wrong turns I took first, and how far the evidence actually goes. The setup The uplink is an HSGQ/ODI M110 GPON SFP stick , a Realtek RTL9602C SoC inside a transceiver. Firmware V1.0-220923 works. Firmware V1.1.8-240408 reproducibly kills WAN. Same fiber, same OLT, same hardware. Only the firmware string differs. The HSGQ/ODI M110 GPON SFP stick. The cruel part is that the broken firmware looks fine. The ONU reaches O5, the GPON operational state (G.984.3): registered with the OLT, ranged, all alarm flags clear, GEM port mappings present. Every surface check is green. No service traffic reaches the host. One symptom sent me the wrong way early. Link-local control frames, LLDP (multicast) and MNDP (broadcast), still showed up in the router's traffic sniffer while service unicast did not. I read that as a host-...

TL;DR: I wanted IPv6 failover between two ISPs on a MikroTik RB5009. Announcing two prefixes via SLAAC technically works, but failover is slow because Router Advertisement lifetimes don't expire on demand, and LAN clients can't see upstream routing decisions anyway. As an interim workaround, a PPPoE down script that bounces the DHCPv6-PD client forces RouterOS to deprecate the dead prefix immediately, which gets failover down to about a second. The cleaner approaches are conditional Router Advertisements (RFC 8475) or Source Address Dependent Routing with RFC 8028–aware hosts (RFC 8678). Neither is a native turnkey feature on consumer/SMB gear, but both are reachable on RouterOS through scripting and policy routing, with caveats. The setup I recently bought a MikroTik RB5009UPr to replace my primary FTTH ISP's router and optics. It also replaced a PoE switch, letting me reclaim some desk space. It really is a sweet bit of kit. I then had a second fiber line from an...