On 27/09/18 14:42, Kristian Evensen wrote: > Hi Simon, > > On Wed, Sep 26, 2018 at 7:30 PM Simon Kelley <si...@thekelleys.org.uk> wrote: >> Simplest test is to make whichdevice always return NULL, and see if that >> helps. > > Making whichdevice() always return NULL makes the issue go away. > Without the change, DHCP after a network restart (which triggers > recreating devices) only works after I manually restart dnsmasq. With > the change, DHCP works fine. Chainging dnsmasq to use two interfaces > also makes the issue disappear. I unfortunately do not know what has > suddenly triggered this error. I see that the code in whichdevice() is > from 2012/2013, so it must be something in a different component.
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. > > Carrying a local patch is no problem for me, but I guess a generic > solution is desirable. Would a patch adding a configuration option be > acceptable? > 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. Cheers, Simon. _______________________________________________ Dnsmasq-discuss mailing list Dnsmasqemail@example.com http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss