[prev in list] [next in list] [prev in thread] [next in thread] 

List:       dhcp-client
Subject:    Re: DHCP client does not null-terminate "X" (parse_X) strings (with fix)
From:       "Mark J. Taylor" <mtaylor () cybernet ! com>
Date:       2000-02-16 17:34:44
[Download RAW message or body]

   *** From dhcp-client -- To unsubscribe, see the end of this message. ***


Thank you for your comments regarding *transmission* of nulls.
I can understand the concerns with sending the nulls for
strings.


Perhaps I was not clear in the previous email: This parse_X()
bug is a local storage and parsing problem regarding the leases
file.  It has nothing to do with packet transmission.


:)



-Mark Taylor
NetMAX Developer
mtaylor@netmax.com
http://www.netmax.com/
http://www.cybernet.com/



"HIBBS, BARR (SBCSI)" wrote:
> 
> > From:         Mark J. Taylor[SMTP:mtaylor@cybernet.com]
> > Sent:         Tuesday, February 15, 2000 5:23 PM
> >
> > I've been doing work with version 2, and noticed today, now that I've
> > started using the "option host-name" in the initial leases file, that
> > the way that clparse.c:parse_option_decl() interacts with parse_X is not
> > quite correct.
> >
> > "parse_X()" will allocate a string and do a memcpy() of the string
> > length+1 (to get the null-terminator), but it returns the length of the
> > non-null terminated string.  The caller, parse_option_decl(), uses the
> > returned length as the number of bytes to allocate for the option's data
> > (the string).  This means that the null terminator will get lost.
> >
> > Version 3-beta has this same behavior.
> >
> > I've seen my "host-name" re-written (when dhclient re-writes the leases
> > file) end up being things like "xxx.netmax.com<FF><FF>^Q",
> > "xxx.netmax.com<FF><FF><FF>", "xxx.netmax.com^Q", etc., because of this
> > bug.
> >
> ...this is one of the many gray areas that arise when implementing dhcp
> clients and servers....
> 
> Everybody knows that "string" data types are null-terminated, right?
> 
> ...unfortunately, that's not quite exactly correct....
> 
> RFC 2132, which governs the dhcp options, does not require (and some say,
> discourages) the use of null terminators for string values.  This is for two
> reasons:  (1) the "null" octet has the meaning of END, that is, it
> terminates the ENTIRE options field in a dhcp message, and (2) ALL dhcp
> options (save for 0 and 255) contain an explicit length octet.
> 
> Okay, enough preaching:  most Microsoft clients send a null terminator for
> any alphanumeric string -- but note that it is included in the length count
> for the string.
> 
> Brian, or someone else who hacks the dhclient daily will have to comment on
> whether your proposed change  has no unpleasant side effects (I concentrate
> exclusively on the server), but thanks for sharing what you've found!
> 
> In general, unless you have a configuration which strains at the maximum
> message size limit for dhcp messages, including a null-terminating octet in
> a string is harmless, with the warning that even null octets are considered
> legal values for identifier strings in DNS, so before you widely deploy your
> change, be sure to test with DNS and your mail, FTP, and Telnet clients at a
> minimum to be certain there is no interference.
> 
> Good luck with your testing!
> 
> --Barr

-----------------------------------------------------------------------
To unsubscribe from this list, visit http://www.isc.org/dhcp-lists.html
or send mail to dhcp-client-request@isc.org with the subject line of
'unsubscribe'.
-----------------------------------------------------------------------

[prev in list] [next in list] [prev in thread] [next in thread]