Starter Question: What would cause dnsmasq to start handing out LLAs to wifi clients, and also break DNS at the same time?
My IPv4 network here at home is not fancy but is very reliable and predictable, for both wired and wireless clients.
Recently, our provider (Spectrum) was working on "splices" for an upcoming speed bump. They mentioned that there could be some outages, mainly at late PM/early AM. It turned out that there were 5 recorded outages, and between those periods, my modem (DOCSIS3.1) was showing a frequently-changing Public IPv6 address for much of the time, readable with < icanhazip.com > or others, and -usually- no IPv4 that I could determine. It was chaotic.
What did it look like on the private network side?
1 by 1, wifi clients lost connectivity, and displayed LLA's (169.254.x.x) since dnsmasq was no longer renewing DHCP releases.
IoT clients and HomeAssistant were paperweights
wired clients lasted a bit longer, but still had problems
most of the issues seemed to be DNS related
wired clients would often (not always) stay connected, but usually could not resolve anything (of course) in the internet side.
both Adguardhome and Tailscale were utterly useless [disabling Adguardhome if something acts broken seems like a good simplifying step in this case - fewer variable.]
I tried multiple power cycles of the DOCSIS3.1 modem (like dozens of them over 2 days) and it didn't resolve well. Sometimes a bit of outward connectivity, but eventually that would fail after a few minutes.
Main Question: Why did this External Failure cause such a complete internal failure? What was the cause-effect mechanism for dnsmasq crashing(if that's what happened). Are there some settings I can use in dnsmasq/DHCP-server to mitigate this somewhat?
If/when it happens again, I'd be OK with just NO internet connection, but a working internal/private network. I don't want it to drag everything down like it did.
This does not sound like an IPv6 thing, but rather something else in your config -- maybe an error in the DHCP configuration.
Please connect to your OpenWrt device using ssh and copy the output of the following commands and post it here using the "Preformatted text </> " button (red circle; this works best in the 'Markdown' composer view in the blue oval):
Remember to redact passwords, VPN keys, MAC addresses and any public IP addresses you may have:
Delegate IPv6 prefixes
Enable downstream delegation of IPv6 prefixes available on this interface
...and a small handful of IPv6 options were enabled. I'm sifting through things a 2nd time to be sure that such options are disabled -and- that all my devices still function as expected. Will check this over the next 2 days and make sure that leases are still being assigned.
Also found 2 IPv6 options on in Adguardhome that were activated - I've switched those off as well.
I read your post and thought about my subject/title for this post. Good catch - I don't want to assume IPv6 was the problem. Title has been changed to reflect that. Assuming you understand something is a good way to miss the real problem.
Maybe it was just the frequently changing public IP address (my sampling of it showed usually IPv6, but not always; certainly it was not stable).
I'm not clear on how I can simulate this problem (5 recorded outages over less than two days, clearly with intermittent, like every few minutes public ip address changes that they didn't bother to note in their tech support emails) in order to test whether my measures will be effective.
