From owner-freebsd-stable@FreeBSD.ORG Tue Nov 22 08:45:59 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DAFDC16A426 for ; Tue, 22 Nov 2005 08:45:59 +0000 (GMT) (envelope-from lists@servingpeace.com) Received: from smtp.servingpeace.com (servingpeace.com [69.55.225.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 879DF43D76 for ; Tue, 22 Nov 2005 08:45:50 +0000 (GMT) (envelope-from lists@servingpeace.com) Received: from [10.0.0.30] (adsl-69-105-73-175.dsl.pltn13.pacbell.net [69.105.73.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.servingpeace.com (Postfix) with ESMTP id B7EECBA224; Tue, 22 Nov 2005 00:45:49 -0800 (PST) Message-ID: <4382DAB9.30908@servingpeace.com> Date: Tue, 22 Nov 2005 00:45:45 -0800 From: Sam Nilsson User-Agent: Thunderbird 1.5 (Macintosh/20051025) MIME-Version: 1.0 To: Mark Andrews References: <200511142205.jAEM5lkA016867@drugs.dv.isc.org> In-Reply-To: <200511142205.jAEM5lkA016867@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: DHCP client error: domain_not_set.invalid X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2005 08:46:00 -0000 Mark Andrews wrote: >> --61jdw2sOBCFtR2d/ >> Content-Type: text/plain; charset=us-ascii >> Content-Disposition: inline >> Content-Transfer-Encoding: quoted-printable >> >> On Sun, Nov 13, 2005 at 07:14:00PM -0800, Mark Space wrote: >>> Hi all, >>> =20 >>> I just set up the latest 6.0 release, and I'm getting errors with the=20 >>> DHCP client. Trying to pull a network address during start up, I get: >>> =20 >>> Bogus domain search list 15: domain_not_set.invalid >>> =20 >>> This repeats several times before giving up. Google tells me that this= >> =20 >>> problem was report by two users on the bsd-current list. No one ever=20 >>> replied to their inquiries (at least on the list), so I thought to try=20 >>> once more to see if there's any interest in addressing this issue.=20 >>> =20 >>> More info was in the original post: >>> http://lists.freebsd.org/pipermail/freebsd-current/2005-October/057034.ht= >> ml >> >> We should really bitch and then ignore this value when it's bogus rather >> than rejecting the lease. We should also probably allow underscores >> since they are popular among clueless Microsoft admins. Please try the >> follow patch. > > Yes. They are clueless. However giving into their cluelessness > just perpetuates the cluelessness. > > Underscores have never been legal in hostnames. Underscores > are deliberately used to provide namespaces which do not collide > with the hostname namespace. Accepting underscores just allows > the namespaces to collide. > > Mark Sorry for the late reply. I just read this thread and this issue affects me as well. Hopefully I'm not commenting on something that has been fixed but I can't test STABLE at the moment to verify that... I understand the idea that bad values should be rejected, but in reality, I have the same DSL modem that these others have and there is no way to change the domain search list that it sends. No way that I could find at least. This is SBC-Yahoo in California, so there are a lot of people out there with this modem. I had to modify the source code to accept the lease anyway. Now my network stops working every time I rebuild and forget to re-patch the source. I shouldn't have to patch the source code to be able to accept a lease. A single bad lease option shouldn't prevent a lease from being accepted without choice. dhcpd should either 1. accept bogus names (warnings are fine) 2. offer a configuration option or command line switch to allow the bogus domain if we wish 3. offer a configuration option like isc-dhcpd does so that we can ignore or override the setting Number 3 is the best IMHO, number 2 is easier but similar, and number one has already been done in less than a line of code and could be deployed "right now". - Sam Nilsson