The ISP modem restart at 08:19 re-delegated the same /64 five seconds
after the PPPoE drop. networkd re-announced it at once, but the fixed
7 s radvd run kept sending preferred-lifetime-0 RAs for it, so clients
sat on a deprecated prefix until networkd's next periodic RA and IPv6
stayed broken for minutes.
Send one RA per radvd start, up to three 3 s apart, and skip each one if
the /64 is already back on the interface. Verified on stellio with the
rendered script: a prefix gone for good -> three RAs; the PD address
removed and re-added 4 s later -> two RAs, then "is back, leaving it
announced", client preferred again and pinging over v6.
After the reboot vlan-lan got its /64 at boot, but IPv6 still failed for
clients: the first PPPoE session lands on another AIS BNG, is torn down
minutes later, and the reconnect brings a different /64 (07:53
2405:9800:b911:91e3 -> 07:57 b910:1f5d). networkd announces the new
prefix at once but never deprecates the old one (systemd#29651), so
clients keep it preferred for up to 30 minutes and source selection
sends every connection from a dead address.
router-radv-deprecate.service watches vlan-* for networkd removing a
dynamic address and sends RAs with that /64 at preferred lifetime 0 via
a short-lived radvd (SIGKILLed: no shutdown RA). Identical script to the
upstream commit; drop once the cnx-network input is bumped past it.
Verified on stellio: the stale prefix flipped to deprecated on the
client at the first RA and pings resumed; a synthetic dynamic address
removed from vlan-lan produced the same RA end to end.
Clients on stellio's lan had no global IPv6. AIS delegates a single /64
over PPPoE; cnx-network's router service carves the VLAN prefixes with
SubnetId=auto, so vlan-mgmt took the whole prefix and vlan-lan logged
"Couldn't find a suitable prefix. Ran out of address space" -- no RA
prefix on lan.
Pin SubnetId: 0x0 on vlan-lan (the whole /64), 0x1 on vlan-mgmt (out of
range on a /64, harmless; works unchanged if AIS ever delegates wider).
Verified live via runtime drop-ins: vlan-lan got 2405:9800:b910:1f5d::/64
and a LAN client pinged 2606:4700:4700::1111 over v6.
Drop once cnx-network carries the per-VLAN `ipv6SubnetId` option
(cnx-network-clan commit 27c697a) and the input is bumped.
The router service only opens SSH to the mgmt VLAN, the staging port
and the ZeroTier mesh. Also admit it on the yggdrasil interface (`ygg`,
as named by clan-core's service) so the box stays reachable when
ZeroTier is down. Interface-scoped, so a spoofed 200::/7 source on the
WAN never matches.
The MT7531 on the Flint 2 is MDIO-attached and shares the SoC MDIO bus
with the 2.5G WAN PHY. On 6.18.49 mt7530_get_stats64 takes the MDIO
mutex under the RCU read lock that /proc/net/dev readers hold; when the
WAN PHY is renegotiating (PPPoE flap) the mutex is contended, the read
sleeps in atomic context and the box oopses:
BUG: scheduling while atomic: zerotier-one/1748/0x00000002
mt7530_get_stats64 -> dsa_user_get_stats64 -> dev_seq_show
Unable to handle kernel paging request at 0000afa547cef5f0
Vendor upstream 07d99587396024932e02474c3a5bede71d108454 (mainline
2026-05-04, absent from linux-6.18.y). Applies to v6.18.49 with one
fuzz-1 hunk (6.18 still exports mt7530_switch_ops).
Storage=volatile left nothing behind for the 2026-09-23/24 reboots: the
last persisted entry is journald stopping during the 2026-09-22 switch,
and /sys/fs/pstore is empty too. Keep the eMMC-wear intent with a 256M
cap and a 1 min sync interval matching the ext4 commit=60.
kurogeek