Problem with "corrupt" lease file
Niall.oReilly at ucd.ie
Sun Jul 1 15:19:09 UTC 2007
On 30 Jun 2007, at 18:24, Simon Hobson wrote:
> That is ANCIENT, upgrade.
Yes, but that may be beside the point.
OP's situation, IIUC, is that he has:
- equipment which returns string data containing '#' and following
- a version of dhcpd which happily writes this string to the
- the same and later versions of dhcpd which can't read the string
I believe it's a bug in dhcpd that it would write data to the leases
it can't read back correctly. I don't know whether this behaviour
found in the current (3.0.5) release.
If not (i.e. it's been fixed), OP's best route would be to migrate
and (manually) transform the leases file by applying whatever escaping
convention is used by 3.0.5.
Otherwise, 3.0.5 would appear to have an unfortunate data dependency
an appropriate escaping convention to ensure that the sequence of
first writing a lease object from memory to file and subsequently
lease data from file into memory gives a resulting lease object
the original. It seems from the lease-file fragment provided by the
some escaping convention is used (e.g.: uid "\001\000@\312\261n[")
leases, but seems not to be applied uniformly, at least in dhcpd
This might be a case where the oft-quoted remark of Jack T. Hankins
I'm sure David is in a position to say categorically whether this is
issue in 3.0.5.
More information about the dhcp-users