As servicing DHCP on Windows NT, dhclient received the domain name and setting weirdly to /etc/resolv.conf For example: search mzaki.nom\000 nameserver 192.168.177.2 Fix: RFC2132 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. (RFC2132 2. BOOTP Extension/DHCP Option Field Format) isc-dhcp 2.0pl5 client seems to violate this. If server send domain name with a trailing NULL as follows, 0f 0a 6d 7a 61 6b 69 2e 6e 6f 6d 00 | | | | | value: mzaki.nom\0 ( this '\0' stands for NUL character ) | length: 10 tag: Domain Name pretty_print_option() in common/options.c translates this into mzaki.nom\000 and turns over to client script. ad hoc patch is: How-To-Repeat: setup Windows NT as DHCP server, run dhclient on FreeBSD, see /etc/resolv.conf
State Changed From-To: open->feedback Bugs in 'isc-dhcp' should be reported to their developers. See section 6 in the README file in src/contrib/isc-dhcp for details.
Responsible Changed From-To: freebsd-bugs->obrien Over to dhcp maintainer.
At Sat, 30 Sep 2000 12:42:16 PDT, johan@FreeBSD.org wrote: > Synopsis: The combination of dhclient & WinNT server makes resolv.conf useless > > State-Changed-From-To: open->feedback > State-Changed-By: johan > State-Changed-When: Sat Sep 30 12:39:05 PDT 2000 > State-Changed-Why: > Bugs in 'isc-dhcp' should be reported to their developers. > See section 6 in the README file in src/contrib/isc-dhcp > for details. > Hi I forgot to ask you to report back to 'freebsd-gnats-submit@FreeBSD.org' with the subject of this mail when is has been fixed in the isc-dhcp src.
> > State-Changed-Why: > > Bugs in 'isc-dhcp' should be reported to their developers. > > See section 6 in the README file in src/contrib/isc-dhcp > > for details. > > I forgot to ask you to report back to > 'freebsd-gnats-submit@FreeBSD.org' with the subject of this mail > when is has been fixed in the isc-dhcp src. > I'd already reported to ISC a week ago, but no response. -- Motomichi Matsuzaki <mzaki@e-mail.ne.jp> Dept. of Biological Sciences, Grad. School of Science, Univ. of Tokyo, Japan
State Changed From-To: feedback->analyzed I just fetched the latest and greatest src from ISC. And it seems they have already fixed this. cvs log common/options.c ==== revision 1.65 date: 2000/09/29 19:58:24; author: mellon; state: Exp; lines: +8 -4 Don't print trailing NUL when printing a text string. ==== I guess this will be fixed when David do the next import of ISC-DHCP. Thanks for your report and thanks for reporting it to ISC. I leave this open as a import reminder to David.
I had received the response from ISC at 01 Oct. # Sorry for delaying Ted Lemon <Ted.Lemon@nominum.com> says: >The interoperability problem is Microsoft's fault, not ISC's fault. >The section of RFC2132 to which you refer is a mistake, and shouldn't >be there. If there is a future revision of RFC2132, I am expecting >that this error will be fixed. > >There is a workaround in 3.0b2pl6. This will not be fixed in any 2.0 >release - 2.0 is no longer being maintained. Please apply my ad hoc patch (in PR) to FreeBSD tree. -- Motomichi Matsuzaki <mzaki@e-mail.ne.jp> Dept. of Biological Sciences, Grad. School of Science, Univ. of Tokyo, Japan
State Changed From-To: analyzed->closed I'm getting rather annoyed at you over continuing to push this. Ted Lemon/ISC has told you this is the WRONG fix. See http://www.isc.org/ml-archives/dhcp-client/2000/09/msg00045.html http://www.isc.org/ml-archives/dhcp-client/2000/10/msg00001.html http://www.isc.org/ml-archives/dhcp-client/2000/10/msg00004.html I will not commit this patch. As you state, the 3.0 beta client has delt with this issue in rev 1.65 of common/options.c. Your patch is nothing like the offical work around. I would however accept a patch based on the rev 1.64->1.65 diff that applied cleanly to the version 2 client.
At Fri, 3 Nov 2000 04:05:56 -0800 (PST), obrien@FreeBSD.org wrote: > I'm getting rather annoyed at you over continuing to push this. > Ted Lemon/ISC has told you this is the WRONG fix. > See http://www.isc.org/ml-archives/dhcp-client/2000/09/msg00045.html > http://www.isc.org/ml-archives/dhcp-client/2000/10/msg00001.html > http://www.isc.org/ml-archives/dhcp-client/2000/10/msg00004.html No. He has told me in that thread the description in the RFC was mistake to which I had referred, and the "bug" I had pointed out was not a bug. He didn't say my patch is wrong. Indeed, his work-around to this problem is different from mine, but it is a refinement and based on mine. Yes, pushing *worse-old* mine is my big mistake. I beg your pardon for this. > I would however accept a patch based on the rev 1.64->1.65 diff > that applied cleanly to the version 2 client. --- options.c.orig Mon Jun 26 17:06:20 2000 +++ options.c Sat Nov 4 04:03:54 2000 @@ -553,9 +553,13 @@ for (; dp < data + len; dp++) { if (!isascii (*dp) || !isprint (*dp)) { - sprintf (op, "\\%03o", - *dp); - op += 4; + /* Skip trailing NUL. */ + if (dp + 1 != data + len || + *dp != 0) { + sprintf (op, "\\%03o", + *dp); + op += 4; + } } else if (*dp == '"' || *dp == '\'' || *dp == '$' || -- Motomichi Matsuzaki <mzaki@e-mail.ne.jp> Dept. of Biological Sciences, Grad. School of Science, Univ. of Tokyo, Japan