Bug: DHCPv6 Server not able to read its own lease file (4.1.1)

[Maurice Massar]

hi,

when a lease is abandoned, dhcpd generates such an entry in the leases
file:

==========
ia-na "xxxxxxxxxxxxxxxxxx" {
  cltt 5 2010/01/29 13:26:40;
  iaaddr 2001:db8::10be {
    binding state abandoned;
    preferred-life 4500
    max-life 7200
    ends never;
  }
}
==========

but: the parser does not like that:

==========
$ ./server/dhcpd -6 -d -cf /dev/null -lf /tmp/v6/never-never.leases -T
Internet Systems Consortium DHCP Server 4.1.1
Copyright 2004-2010 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
/tmp/v6/never-never.leases line 8: semicolon expected.
  }
   ^
/tmp/v6/never-never.leases line 9: corrupt lease file; expecting ia_na contents, got '
'

^
/tmp/v6/never-never.leases line 9: corrupt lease file; expecting ia_na contents, got '
'

^
[...]
==========

looking at the sources, I would say the problem is in common/parse.c
parse_date_core() which reads all tokens up to but excluding a final
semicolon in the common case, but if the input is "never" the following
semicolon is read to. In this context (ia-na contents, end statement),
parse_date_core() is called via parse_date() which wants to read a
semicolon itself. So, as a workaround
  sed -i 's/ends never;$/ends never;;/' .../dhcpd6.leases
fixes that.

I don't feel confident to come up with a patch, because
parse_date_core() swallows the final semicolon, not only in the "never"
case, but in all error cases too.

And there is one more problem: after the parser got off track, it will
be stuck in an endless loop, while logging:
[...] corrupt lease file; expecting ia_na contents, got '#012#012'
(#012 is probably escaped by rsyslog) ... and this can fill up /var/log
pretty quickly if left unattended...


btw.. shouldn't there be a ";" at the end of the "preferred-life" and
"max-life" line?


I got to this problem because our "dhcpd -6" process dies silently,
sometimes serveral times a day .. sometimes running for a few days..
-tf does write a tracefile, but -play seems unable to read it:
subnet_number():inet.c:52: Addr/mask length mismatch: 4 (000000000b000000402d000000c61608) != 16 (ffffffffffffffff0000000000000000)
(I added a dump of addr and mask struct in the log_fatal() call)
I'll keep poking on this one.... (I did not enable coredumps yet, and
will run tcpdump -w in parallel .. other ideas?)

cu
Maurice Massar