[Dnsmasq-discuss] local-service feature doesn't detect new/changed interfaces/networks
Timothy White
timwhite88 at gmail.com
Thu Jun 11 10:24:58 BST 2015
Hi Simon
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.
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.
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.
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.
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.
Regards
Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20150611/f750506b/attachment.html>
More information about the Dnsmasq-discuss
mailing list