Problem with "corrupt" lease file

[Niall O'Reilly]

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  
characters,
	  - a version of dhcpd which happily writes this string to the  
leases file,
	  - the same and later versions of dhcpd which can't read the string  
correctly.

	I believe it's a bug in dhcpd that it would write data to the leases  
file which
	it can't read back correctly.  I don't know whether this behaviour  
is still
	found in the current (3.0.5) release.

	If not (i.e. it's been fixed), OP's best route would be to migrate  
to 3.0.5
	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  
and needs
	an appropriate escaping convention to ensure that the sequence of  
operations of
	first writing a lease object from memory to file and subsequently  
reading that
	lease data from file into memory gives a resulting lease object  
identical to
	the original.  It seems from the lease-file fragment provided by the  
OP that
	some escaping convention is used (e.g.: uid "\001\000@\312\261n[")  
in writing
	leases, but seems not to be applied uniformly, at least in dhcpd  
3.0pl1.

	This might be a case where the oft-quoted remark of Jack T. Hankins  
applies.
	I'm sure David is in a position to say categorically whether this is  
still an
	issue in 3.0.5.

	/Niall