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.


Dnsmasq-discuss mailing list

Reply via email to