Hi, On Thu, Sep 27, 2018 at 9:53 PM Simon Kelley <si...@thekelleys.org.uk> wrote: > Progress. AFAIK, the dnsmasq behaviour around this has not changed at al > in that time period. I think it's likely that the change is in the > OpenWRT network infrastructure, maybe hotplug/coldplug stuff that now > destroys and re-creates the kernel-level network device, rather than > just reloading its configuration. > > I run the bleeding edge dnsmasq code (we suffer so you don't have too!) > on an old, stable Chaos-calmer OpenWRT install, and I'm not seeing this > effect, which adds weight to the theory that the change is elsewhere.
Yes, I agree. I also haven't seen this error up until recently, so there is something else that has broken. I will try to dig a bit when or if I have time, and see if I can discover something. > Dnsmasq is quite clever at handling changes in kernel network level > devices under its feet, maybe there's a way to re-bind when that > happens? I'll have a look. A configuration option would be the last > resort here: adding "pull this lever to make it work" options is > something I try and avoid. I agree here as well. I checked if there was a socket event we were missing, but at least no event was received on my boxes. I guess the most elegant approach would be to monitor RTNLGRP_LINK for DELLINK, and close the socket when DELLINK arrives. The socket could then be recreated on NEWLINK, or, proably even better, NEWADDR. BR, Kristian _______________________________________________ Dnsmasq-discuss mailing list Dnsmasqemail@example.com http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss