dynamic update not working consistently

[Jiann-Ming Su]

 I'm running 3.0.5 in interim mode and am having a strange dynamic dns
problem where the hostname is not updating reliably.

Here's the logs from a XP client that can't get the name to register at all:

Jan  5 14:54:07 dhcp2 dhcpd: DHCPDISCOVER from 00:13:d3:15:d2:4d via 10.10.96.1
Jan  5 14:54:08 dhcp2 dhcpd: DHCPOFFER on 10.10.99.135 to
00:13:d3:15:d2:4d (notworking) via 10.10.96.1
Jan  5 14:54:08 dhcp2 dhcpd: DHCPREQUEST for 10.10.99.135 (172.30.8.4)
from 00:13:d3:15:d2:4d (notworking) via 10.10.96.3
Jan  5 14:54:08 dhcp2 dhcpd: DHCPACK on 10.10.99.135 to
00:13:d3:15:d2:4d (notworking) via 10.10.96.3
Jan  5 14:54:08 dhcp2 dhcpd: DHCPREQUEST for 10.10.99.135 (172.30.8.4)
from 00:13:d3:15:d2:4d (notworking) via 10.10.96.1
Jan  5 14:54:08 dhcp2 dhcpd: DHCPACK on 10.10.99.135 to
00:13:d3:15:d2:4d (notworking) via 10.10.96.1


Here's an XP station that works:

Jan  6 13:48:03 dhcp2 dhcpd: DHCPDISCOVER from 00:15:c5:08:7c:6b via 10.10.8.3
Jan  6 13:48:04 dhcp2 dhcpd: DHCPOFFER on 10.10.15.235 to
00:15:c5:08:7c:6b (working) via 10.10.8.3
Jan  6 13:48:04 dhcp2 dhcpd: Added new forward map from
working.test.bogus to 10.10.15.235
Jan  6 13:48:04 dhcp2 dhcpd: added reverse map from
235.15.10.10.ddns.in-addr.arpa to working.test.bogus
Jan  6 13:48:04 dhcp2 dhcpd: DHCPREQUEST for 10.10.15.235 (172.30.8.4)
from 00:15:c5:08:7c:6b (working) via 10.10.8.3
Jan  6 13:48:04 dhcp2 dhcpd: DHCPACK on 10.10.15.235 to
00:15:c5:08:7c:6b (working) via 10.10.8.3
Jan  6 13:48:04 dhcp2 dhcpd: DHCPREQUEST for 10.10.15.235 (172.30.8.4)
from 00:15:c5:08:7c:6b (working) via 10.10.8.1
Jan  6 13:48:04 dhcp2 dhcpd: DHCPACK on 10.10.15.235 to
00:15:c5:08:7c:6b (working) via 10.10.8.1

In the dhcpd.conf man page, it mentions in "interim" mode, the dhcp
server tracks whether or not it has updated the record and doesn't try
to update records it thinks it has already updated.  For the "working"
station, we observe that behavior.  Subsequent dhcp transactions from
the working station does not have the corresponding dns update.
However, for the "notworking" station, it never tries to update at
all.

We sniffed the dhcp traffic for both stations, and the only obvious
difference is the working station is sending option 43, while the
notworking station does not.  However, for a Linux station that's
updating properly, it sends even less options. So, we're not sure how
much effect the options have.

How can we debug this further?  Thanks for any insights.
-- 
Jiann-Ming Su
"I have to decide between two equally frightening options.
 If I wanted to do that, I'd vote." --Duckman
"The system's broke, Hank.  The election baby has peed in
the bath water.  You got to throw 'em both out."  --Dale Gribble
"Those who vote decide nothing.
Those who count the votes decide everything.”  --Joseph Stalin