<div dir="ltr"><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jun 2, 2014 at 1:11 PM, Simon Kelley <span dir="ltr"><<a href="mailto:simon@thekelleys.org.uk" target="_blank">simon@thekelleys.org.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 28/05/14 00:24, Aaron Wood wrote:<br>
> This is a _very_ old platform, running 2.47.<br>
><br>
> What happens is that a client requests it's previous address in the DHCP<br>
> DISCOVER packet, and that's ack'd as ok by dnsmasq, even though it differs<br>
> from the address as specified in the dhcp-hosts file that's in use.<br>
><br>
> On a much newer build of dnsmasq, I see the expected (by me) behavior of<br>
> the requested address being denied, and the configured address returned.<br>
><br>
> Further, my lease change notification script is getting an "old"<br>
> notification for the requested address, but never getting a notification<br>
> that a valid lease was handed out.  As such the application listening to<br>
> the lease notification events is losing track of the devices in question.<br>
><br>
> I've gone through the release notes, and I'm not seeing when this would<br>
> have changed.  I can attempt to port a newer version of dnsmasq to the<br>
> system, but it's a very old version of OpenWRT (8.x), on linux 2.4...<br>
><br>
> Is this something that I can configure around?<br>
><br>
><br>
</div></div>I'm not aware that behaviour around that has changed for a very long time.<br>
<br>
Did you try simply stopping dnsmasq, deleting the DHCP leas database,<br>
and then starting dnsmasq?</blockquote><div><br></div><div>Well, I tried a reboot (which effectively does that as the leases file is in /tmp), and it didn't change the behavior.  I think I'm going to try updating it to 2.55 (same as on another platform I have which is acting as-expected), and see if that corrects it.</div>
<div><br></div><div>-Aaron </div></div></div></div>