Found live again, in a different shape: after a later round of service
restarts (dnsmasq restart while debugging), br-tollgate desynced a
second time — but this time netifd's own status reported the interface
up with 192.168.99.1 assigned, while `ip -4 addr show br-tollgate` was
genuinely empty at the kernel level. dnsmasq logged "DHCP packet
received on br-tollgate which has no address" and silently dropped
every DISCOVER — clients associated to the archipelago SSID fine but
never got an IP.
A single blind ifdown/ifup (the previous fix) isn't trustworthy against
this netifd race — replace it with a loop that checks the actual kernel
address after each cycle and retries up to 5 times, failing loudly
(rather than silently leaving DHCP broken) if it never converges.
ssmithx
6060ad23b2