Bug 177963

+++ This bug was initially created as a clone of Bug #176615 +++

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922
Fedora/1.0.7-1.1.fc4 Firefox/1.0.7

Description of problem:
between dhcp-3.0.2-22 and dhcp-3.0.2-24 some code was moved around and i think
this had an undesired side-effect. i tried to find the exact spot, but couldn't
find it.

The release notes say:
>"append"ing a string onto the end of a "t" type option (such as the
>domain-name field) that had been improperly NULL-terminated by the
>DHCP server will no longer result in a truncated string containing
>only the option from the server, and not the expected appended value.

For me it has the opposite effect.
See the attached logfile.
Notice how 3.0.2-24 says only BOOLE while 3.0.2-22 says BOOLE.creaholic.com.


Version-Release number of selected component (if applicable):
dhcp-3.0.2-24

How reproducible:
Always

Steps to Reproduce:
1. set up a dhcp-server for dynamic dns updates
2. have a nt-client
3. in a dos-shell release ip ("ipconfig /release")
4. in a dos-shell renew ip ("ipconfig /renew")
  

Actual Results:  logfile on dhcp-server shows error:
Unable to add forward map from BOOLE to 192.168.131.226: timed out

zonefiles on dns-server has no records for BOOLE


Expected Results:  logfile should show:
Added new forward map from BOOLE.creaholic.com. to 192.168.131.226
added reverse map from 226.131.168.192.in-addr.arpa. to BOOLE.creaholic.com.

zonefiles on dns-server should have forward and reverse records for BOOLE

Additional info:

notice in attached logfile how it uses the fqdn to remove the dns-records, but
uses the hostname without domainname to add dns-records.

-- Additional comment from dworz on 2005-12-27 12:27 EST --
Created an attachment (id=122601)
logfile showing good and bad behaviour


-- Additional comment from jvdias on 2006-01-09 13:55 EST --
I'm investigating this now. 
Did you try the latest dhcp-3.0.2-28.FC4 release now in updates/testing
(and being moved to updates/final today) ? This release has the complete 
upstream patch for the null termination issue.
It would also be most helpful if you could gather a tcpdump of the server/client
traffic on the server:
  # tcpdump -nl -i any -vvv -s 4096 -X port bootps or port bootpc \
    >/tmp/dhcp.tcpdump.log 2>&1
Then boot the client, duplicating the problem,  'pkill tcpdump', and append
the /tmp/dhcp.tcpdump.log contents to this bug report - thank you.

-- Additional comment from jvdias on 2006-01-09 16:49 EST --
I cannot reproduce this issue with dhcp-3.0.2-28.FC4, or with dhcp-3.0.1-52.EL4
in RHEL-4, both of which have the latest upstream fix for the trailing NUL
removal issue.

I was using a Windows-XP-Professional client, which had the option 
  "Register this connection's addresses in DNS" checked (selected) in the
"DNS" tab of the "Advanced TCP/IP Settings" dialog, reached by clicking on
the "Advanced" button of the "Internet Protocol (TCP/IP) Properties" dialog 
of the "Local Area Connection Properties" dialog. 

NOTE: Windows has several options regarding DDNS updates : 
  o "Append primary and connection specific DNS suffixes" -
    The "connection specific DNS suffix" comes from the DHCP 'domain-name'
    option, and is listed in the 'ipconfig' output.
    The "primary" suffix is the suffix of the primary DNS server (which may
    or may not be in the DHCP 'domain-name-servers' option).
  o "Append these DNS suffixes" -
    A list of domain name suffixes to update can be specified explicitly.
  o "DNS suffix for this connection" - 
    A DNS suffix can be explicitly specified for the connection.

Note also that the dhcp server can request the client to do the DNS updates
by sending the a 'fqdn.server-update' value of 0 (false) ( or by setting the
'allow client-updates' option ) (but I'm not sure how you'd tell windows about
the DNS zone keys).

If you still have problems with dhcp-3.0.2-28.FC4, please gather the tcpdump
output requested above, and send me it along with your dhcpd.conf file - 
thank you.

-- Additional comment from jvdias on 2006-01-13 11:14 EST --
Can you reproduce this problem with dhcp-3.0.2-28.FC4 ? I've not been able to.
If you can, please send me the tcpdump and dhcpd.conf data requested above,
and re-open this bug - thank you.

-- Additional comment from dworz on 2006-01-14 12:46 EST --
Created an attachment (id=123200)
tcpdump of dhcp client/server communication


-- Additional comment from dworz on 2006-01-14 12:47 EST --
Created an attachment (id=123201)
(stripped) dhcpd.conf


-- Additional comment from dworz on 2006-01-14 12:53 EST --
Problem still persists with dhcp-3.0.2-28.FC4.
please note:
-dhcp-client ist windows nt (not xp)
-dhcp-server is set to do the ddns-update.
-the dhcp-client doesn't know anything about ddns.


-- Additional comment from dworz on 2006-01-14 12:58 EST --
Created an attachment (id=123202)
tcpdump of dhcp-server to dns-server traffic

note how dhcpd sends only TAYLOR not taylor.creaholic.com to the dns.

-- Additional comment from jvdias on 2006-01-16 16:32 EST --
Many thanks for appending the client->server dhcp traffic - I've found and 
fixed the problem now.
This bug is fixed with dhcp-3.0.2-30.FC4, to be release to FC-4/Updates/Testing
today, and dhcp-3.0.3-20.FC5 in Rawhide.
Please try out the new version and let me know of any issues - thanks .