Bug 147007

I have now tested this and verified that the behaviour of 
dhclient-3.0.1-10_EL3 is actually IDENTICAL to that of 
dhclient-3.0pl2-6.14 in this regard - both versions
generate identical DHCP packets , as can be seen by doing
a tcpdump:
  # tcpdump -nl -vvv -i eth0 -s 2048 port bootpc or port bootps 2>&1 |
tee /tmp/tcpdump.log

The  "ddns-update-style ad-hoc;" that your DHCP server is using
is broken, deprecated and unlikely to be supported in future 
DHCP releases, as is stated in the dhcpd.conf(5) man page - 
read the sections on DDNS .

The behaviour of the "ad-hoc" update style can be very confusing:
ONLY if the lease has expired, and the client does not send a 
"requested IP address" option in the DHCPREQUEST packet, does 
the server generate a DNS update in ad-hoc mode .

Thus, with both dhclient versions, if the
/var/lib/dhcp/dhclient-eth0.leases file contains an unexpired lease,
and the client renews the lease by sending a requested IP in the
DHCPREQUEST, the server will generate no DNS update. 

If you get the client to release any unexpired leases with the 
command:
   # dhclient -r -pf /var/run/dhclient-eth0.pid -lf \   
        /var/lib/dhcp/dhclient-eth0.leases
and THEN do:
   # ifdown; ifup
OR # dhclient  -pf /var/run/dhclient-eth0.pid -lf \   
        /var/lib/dhcp/dhclient-eth0.leases eth0
then the server will generate the DNS updates with either 
version of dhclient - both 3.0.1-10_EL3 and 3.0pl2-6.14 .

So this seemed like a problem because you must have updated DHCP
before the lease has expired and the server did not generate any
updates.

The best way to remedy this situation is to use the 
  'ddns-update-style interim;'
in the server, and change dhclient.conf to contain:
  'send option fqdn.fqdn "servername.my.domain.com";'
Then the server will update DNS much more intelligently: on every
postive DHCPACK, the server will check if the 'A' and 'PTR' 
records exist and create them if necessary. The 'interim' method
is compliant with all current DDNS RFCs and standards, and will 
be fully supported in future DHCP versions. Also, with this method
you can tell the client to do the forward DNS update. 

If you have further problems with this please run the tcpdump command
above while reproducing the problem and append the /tmp/tcpdump.log
to this bug - please also include information on what version of the
DHCP server and the dhcpd.conf you are using - thank you.

Created attachment 110623 [details]
log with the old version

Created attachment 110624 [details]
new package log

The dhcp server is a windows machine.
I have tried the release and renew as you specified above with no 
luck... but again the older package works immediately.

This is very strange. 

The logs show that both dhclient versions are sending IDENTICAL
packets (except for timestamps / transaction IDs).

The two packet traces differ only in that in the new version trace,
DHCP server .2 makes an OFFER before .3, while in the old version
trace, DHCP server .3 makes an OFFER before .2 - the two dhclient
versions may have slightly different timing characterstics, but 
their behaviour and generated packets are the same.

Verify that the DNS server allows updates from either DHCP server .

What DNS server are you using ? It would be interesting to see the
DNS server event logs during the times these traces were taken .

Can you duplicate the problem when only one DHCP server is responding?

we have 2 identical windows machines for redundancy.. the only thing 
else that i can think of is that we also use cisco ip-helper to 
forward the requests to the dhcp machines.

And DNS runs on both windows machines ? 
Are you using ISC BIND or MS-DNS ?
I know ISC BIND creates log entries for each DNS update request -
I think MS-DNS can be configured to do so as well .
Are both DNS servers configured to accept DNS updates from both
DHCP servers ?

Are there any DNS or DHCP server event log entries for the times 
the packet traces were collected and the problem reproduced ?
They would be most useful to append to this bug.

As I said in the previous comment, the packets generated by the two
versions of dhclient appear to be IDENTICAL , so that would suggest
that a component other than dhclient is the cause of this problem. 

For the old dhclient version trace, the client gets its first OFFER 
from the .2 DHCP server , and in the new dhclient version trace, the
.3 DHCP server responds first . 

Please can you retry the tcpdump with the two versions using this
exact tcpdump command, if you did not use it to generate the 
previous trace:

# tcpdump -nl -vvv -i eth0 -s 2048 port bootpc or port bootps 2>&1 |
tee /tmp/tcpdump.log

If you did use it to produce the previous trace, please check that
you have tcpdump version 3.7.2-7+ installed, and install it if not.

The '-vvv' option makes tcpdump actually print out the option values -
eg. it will show the values of the 'host-name' options sent, assuming
you have tcpdump version 3.7.2-7 . Perhaps when all the DHCP options
are printed out the packets will not be identical - I know both
versions produce identical packets on the RHEL-3 system I've been
testing on, with 'send host-name' in /etc/dhclient.conf, using the
tcpdump command above.