<div dir="ltr">Hi Simon<div><br></div><div>I'm not sure if this will be related to the issue Tong had earlier this year. I have a piece of software (the Grase Hotspot project) the relies on dnsmasq to serve the local clients. In theory, the local-service feature shouldn't hurt this. However, dnsmasq is starting before the Coova Chilli software has finished bring up it's tun interface, which is where the client network IP is. Because the interface comes up after dnsmasq, it doesn't do anything to bind to it, (if bind-interfaces is on), and also doesn't add the network on the interface to the local networks list.</div><div>Ideally, dnsmasq would detect a new interface, or a network change, and rebuild it's local networks list, for clients it'll answer queries for.</div><div>Alternatively, being able to specify a list of local networks in the config file (forgive me if this exists, I couldn't find it in the man page), that it'll always answer queries on, regardless of the local-service argument, would also solve this. We know at the time that dnsmasq is started what the network IP will be, as we already drop a config file in /etc/dnsmasq.d/ that contains settings from the Hotspot. If I could force a network range to be considered local in the config files, I can easily have it in that file.</div><div><br></div><div>So, after a reboot, dnsmasq starts before tun0 has it's ip. DNS requests from clients on the tun0 network result in no reply, and "Ignoring query from non-local network" being logged in syslog. A restart of dnsmasq after tun0 has it's ip results in clients successfully being able to use dnsmasq.</div><div><br></div><div>I'm hoping to be able to avoid the need to manually send a signal to dnsmasq, and that it can detect the network changes itself. Otherwise, I'll have to work out some hack to either delay dnsmasq long enough for tun0 to come up, or hope I can hook into another part of the code that should be run after tun0 is up.</div><div><br></div><div>Regards</div><div><br></div><div>Tim</div></div>