Simon Kelley wrote: > Tom Metro wrote: >> The router gets rebooted daily, and I'm trying to get the "static" lease >> to persist across reboots. Here's what I'm seeing: >> >> 4. Router is rebooted. >> 5. Initially cctv1 still exists in lease file. >> 6. A ping of cctv1 fails with a bad host name, and has disappeared from >> the lease file. >> >> What caused it to disappear from the lease file? > > The expiration time (first field in the relevant line in the leases > file) is less (earlier) than the current time. > > What value is there.
Here are the lease file entries seen for cctv1 over the course of my testing: 108 00:14:d1:f1:c7:e6 192.168.1.225 cctv1 01:00:14:d1:f1:c7:e6 51 00:14:d1:f1:c7:e6 192.168.1.225 cctv1 01:00:14:d1:f1:c7:e6 4294967295 00:14:d1:f1:c7:e6 192.168.1.225 cctv1 01:00:14:d1:f1:c7:e6 Is that time value suppose to be the usual seconds from epoch? The last one corresponds to Feb 7 02:28:15 2106. Seems pretty "infinite." The first two seem like they would cause the entry to expire as soon as it is created. It may be relevant to point out that the router gets its time initialized to epoch on boot, and set via NTP (what appears to be) fairly late in the boot-up process. Maybe it is possible the first two lines show leases acquired before the time was correctly set? Even still, 108 and 51 seconds are ridiculously short lease periods. Does Dnsmasq examine the lease expiration times when it first reads in the lease file and throw out all entries that are expired? (Does it care if the entry is *way* in the future, as in the case where it thinks the current time is near epoch, but the expiration is correct time + whatever was added for the "infinite" lease?) > You configuration means that dnsmasq will offer an infinite lease to > the cctv, but it may choose to take out a shorter lease. Out of curiosity, why? This seems to break the expectations set by having an "infinite" option. (And the man page doesn't appear to address this quirk. I assume this behavior is part of the DHCP spec.) Generally, that shouldn't be a problem. Presumably the client is aware of the lease expiration and will appropriately request a renewal. But in my observation, it seemed like the client was unaware of the expiration and never requested a lease renewal. > The following hack may solve your problem. > 2) edit the leases file and make the lease expiry time for cctv1 0 > Note that 0 means "infinite - never expires" in this context. Would such a change remain perpetually, or are there circumstances where Dnsmasq would overwrite that entry? Whether manually edited as a one-off or dynamically edited via a script, this is going to effectively mean a 2nd place that needs to have knowledge of which clients have static IPs. It's starting to border on diminishing returns for using DHCP. Static entries in /etc/hosts would also solve these problems, at the expense of having to configure each client with a static IP. > The relevant situation is when a client renews a lease which dnsmasq > doesn't know about. without "dhcp-authoritative" it will reject the > transaction and cause the client to go through a complete DHCP cycle - > that complies with the standard. With "dhcp-authoritative" is will > quietly put the lease into the database and continue as if nothing were > wrong. Ah, got it. That makes sense. So it's not that Dnsmasq will somehow know about the client, it's just that it'll accept a renewal from a client it doesn't know. The stock configuration for Dnsmasq on the router has no persistent lease file and dhcp-authoritative set. I added a persistent lease file (residing on a USB Flash drive) and left dhcp-authoritative set. Sounds like it should have no bearing on the testing I'm doing at the moment. Thanks for the clarification. -Tom -- Tom Metro Venture Logic, Newton, MA, USA "Enterprise solutions through open source." Professional Profile: http://tmetro.venturelogic.com/
