Re: [Dnsmasq-discuss] dhcp entries not being removed from dnsmasq

2017-05-17 Thread Graeme Peterson
Thanks Simon. Appreciate the heads-up on the off-topic parts of my post. I see from the auth.log entries that dhcp_release is being called as: dhcp_release tapc5399cce-70 132.16.0.13 fa:16:3e:8e:83:97 To me that looks good, and lines up with the man page for dhcp_release. The interface

Re: [Dnsmasq-discuss] dhcp entries not being removed from dnsmasq

2017-05-17 Thread Simon Kelley
Ah, didn't read this before my previous reply. dhcp_release is getting called, but dnsmasq is not getting the packet (dhcp_release works by faking up a DHCP message as if it's coming from the DHCP client, which tells the server to release the lease.) If you can't see the packet in your packet

Re: [Dnsmasq-discuss] dhcp entries not being removed from dnsmasq

2017-05-17 Thread Simon Kelley
dhcp_release is a bit of a hack, and I guess the packet it generates could be blocked by all sorts of iptables rules. It also doesn't seem to support the interface (eg tapc5399cce-70) having more than one IP address on the same subnet, in case that's a problem. My impression is that you're an

Re: [Dnsmasq-discuss] dhcp entries not being removed from dnsmasq

2017-05-17 Thread Simon Kelley
You're assuming a lot of knowledge of OpenStack which is strictly off-topic here. Given that, a couple of observations. 1) If dnsmasq is getting a DHCPELEASE packet, it will log that. Given you're not seeing that in logs, then either dhcp_release is not being invoked, or it's getting the wrong

Re: [Dnsmasq-discuss] dhcp entries not being removed from dnsmasq

2017-05-17 Thread Graeme Peterson
I found the following entry in /var/log/auth.log which shows neutron as root (sudo) calling dhcp_release on IP: 132.16.0.13, MAC: fa:16:3e:8e:83:97 two minutes after the DHCPACK and two minutes before the dnsmasq-dhcp log failure saying: "not using configured address 132.16.0.13 because it is