Apparently we should be removing trailing NULs from options whose
data are NVT ASCII strings.
Other than RFC nitpicking, Microsoft DHCP sometimes sticks those
pesky NULs in, and this breaks 'appending' values via dhclient.conf,
as the pretty print routine will stick '\000' into the generated
string.
Anybody out there suffering from Microsoft DHCP servers that can
verify this helps?
Of course, gentle messages pointing out errors or breakage always
welcome.
Note that DHO_PAD == 0, hence simply shortening the length used to
retrieve the data should leave behind '\0' bytes that will be ignored
as DHO_PAD options.
.... Ken
Index: options.c
===================================================================
RCS file: /cvs/src/sbin/dhclient/options.c,v
retrieving revision 1.39
diff -u -p -r1.39 options.c
--- options.c 11 May 2011 14:38:36 -0000 1.39
+++ options.c 24 Jun 2012 21:14:27 -0000
@@ -86,6 +86,19 @@ parse_option_buffer(struct option_data *
warning("rejecting bogus offer.");
return (0);
}
+
+ /*
+ * Strip trailing NULs from ascii ('t') options. They
+ * will be treated as DHO_PAD options. i.e. ignored. RFC 2132
+ * says "Options containing NVT ASCII data SHOULD NOT include
+ * a trailing NULL; however, the receiver of such options
+ * MUST be prepared to delete trailing nulls if they exist."
+ */
+ if (dhcp_options[code].format[0] == 't') {
+ for (len = s[1]; len > 0 && s[len + 1] == '\0'; len--)
+ ;
+ }
+
/*
* If we haven't seen this option before, just make
* space for it and copy it there.
