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.



Dnsmasq-discuss mailing list

Reply via email to