+++ 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 .
This bug is also upstream in ISC DHCP 3.0.4b2 . Fixed with dhcp-3.0.1-54.EL4 - patch sent upstream .
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2006-0114.html