On 8/22/19 6:50 PM, Simon Kelley wrote:
On 26/04/2019 21:03, Brian Haley wrote:
Currently, dhcp_release will only send a 'fake' release
when the address given is in the same subnet as an IP
on the interface that was given.
This doesn't work in an environment where dnsmasq is
managing leases for remote subnets via a DHCP relay, as
running dhcp_release locally will just cause it to
silently exit without doing anything, leaving the lease
n the database.
Change it to save the first IP it finds on the interface,
and if no matching subnet IP is found, use it as a fall-back.
This fixes an issue we are seeing in certain Openstack
deployments where we are using dnsmasq to provision baremetal
systems in a datacenter.
While using Dbus might have seemed like an obvious solution,
because of our extensive use of network namespaces (which
Dbus doesn't support), this seemed like a better solution
than creating system.d policy files for each dnsmasq we
might spawn and using --enable-dbus=$id in order to isolate
messages to specific dnsmasq instances.
The address we're determining here is the address used for the "server
identifier" for the DHCP lease. In the case of a client on the other
side from a DHCP relay, dnsmasq uses one of the addresses of the
interface through which the packet arrived. This patch also uses one of
the addresses, but it doesn't choose it in the same way, so for an
interface with multiple addresses, dhcp_release may pick a different
address than the one dnsmasq did, the server_id in the release message
will not match, and the operation will silently fail again.
If the interface has only one address, a common case, then that has to
be chosen, and all works. For more robustness, it makes sense for this
patch to pick one of the addresses in the same way that the dnsmasq code
does, namely, by doing
ioctl(..., SIOCGIFADDR, ...)
in the case that none of the addresses match the address of the lease.
A patch to do that instead of using the first one returned by netlink
would be great.
Thanks Simon, I'll update it and send a v2.
-Brian
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
