[Dnsmasq-discuss] ip address not released
simon at thekelleys.org.uk
Wed Jun 11 10:03:06 BST 2008
Peter Katzmann wrote:
> we have to repair some embedded systems with mac addresses within a
> specific range.
> These system needs bootp to get flashed some special software.
> So i configured the following entries (Dnsmasq version 2.40):
> Imho the device, who fits to the mac range, will receive the address for
> embed with a lease time of 10 minutes
> Also i have a bootp entry:
> Everything works well with one system but the address won't be released
> after 10 minutes.
> When i replace the system with another one from the mac range i get the
> following error:
> dnsmasq: BOOTP(eth23) 192.168.1.119 00:9a:7e:8f:19:5a address in
> I always have to remove the lease entry manually from
> /var/lib/misc/dnsmasq.leases and restart dnsmasq to get the new system
> running, independently from how long i wait.
This is a limitation of BOOTP: it doesn't support the concept of a
time-limited lease, so once an address is allocated, it's allocated
forever: That has to be the case, since the client cannot renew a lease,
it just assumes that it has use of the address forever.
I'm slightly confused about what is happening here: to get the behaviour
you describe, you must be allocating the address 192.168.1.119 to the
MAC address somewhere - otherwise dnsmasq will complain that there's no
allocated address. Either there's an IP address in you dhcp-host line,
or something in /etc/ethers.
One workaround, which is counter-intuitive, is to stop nailing down an
address for you box, and set --bootp-dynamic. That way each new box will
get a new address. Eventually, you will have a load of addresses with
infinite leases on them, which you will have to clear out, but at least
you won't have to do it as often.
There's actually no reason why the behaviour of dnsmasq couldn't be
changed to honour the lease time in a dhcp-host statement for BOOTP:
it's reasonable to assume that if it's explicitly configured, the user
knows what is wanted. The default lease time associated with the
dhcp-range should still be ignored, of course. I'll make the change in
the next release.
More information about the Dnsmasq-discuss