If the IP address changes on an interface, other computers on the network won't know the new IP address until their locally cached mDNS record times out. The default timeout is 120 seconds which is long enough to make you think that the device stopped working. It didn't. It's just on a different IP address. Some people reboot their devices and then report that they're working again. The strong suspicion is that their PC's mDNS cache timed out while waiting for the reboot. This can be confirmed using Wireshark to watch outgoing mDNS requests.
This seems to be reproducible using VintageNetWizard and mdns_lite at the same time. You have to go to the device using the device's .local name both when it's in wizard mode and after it connects to the LAN. Note that the directions on the wizard do not use mDNS.
This issue should also happen if DHCP changes its mind when renewing IP addresses and probably in other cases, but I suspect those are rare enough that no one will see them in the wild.
The proper fix to this seems to be for mdns_lite to proactively announce its new .local records so that it an invalidate caches across the network. See https://tools.ietf.org/html/rfc6762#section-10.2.
If the IP address changes on an interface, other computers on the network won't know the new IP address until their locally cached mDNS record times out. The default timeout is 120 seconds which is long enough to make you think that the device stopped working. It didn't. It's just on a different IP address. Some people reboot their devices and then report that they're working again. The strong suspicion is that their PC's mDNS cache timed out while waiting for the reboot. This can be confirmed using Wireshark to watch outgoing mDNS requests.
This seems to be reproducible using VintageNetWizard and
mdns_liteat the same time. You have to go to the device using the device's.localname both when it's in wizard mode and after it connects to the LAN. Note that the directions on the wizard do not use mDNS.This issue should also happen if DHCP changes its mind when renewing IP addresses and probably in other cases, but I suspect those are rare enough that no one will see them in the wild.
The proper fix to this seems to be for
mdns_liteto proactively announce its new.localrecords so that it an invalidate caches across the network. See https://tools.ietf.org/html/rfc6762#section-10.2.