From owner-freebsd-questions@FreeBSD.ORG Sun Jun 1 13:15:57 2014 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CB744905; Sun, 1 Jun 2014 13:15:57 +0000 (UTC) Received: from remote.thehowies.com (50-197-91-217-static.hfc.comcastbusiness.net [50.197.91.217]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "remote.thehowies.com", Issuer "RapidSSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9C1552BED; Sun, 1 Jun 2014 13:15:56 +0000 (UTC) Received: from PRIMARY.thehowies.local ([fe80::967:7eb6:ee49:3820]) by PRIMARY.thehowies.local ([fe80::967:7eb6:ee49:3820%11]) with mapi id 14.01.0438.000; Sun, 1 Jun 2014 06:15:56 -0700 From: John Howie To: Rick Macklem Subject: Re: Patches for BOOTP/DHCP code to support Windows Server DHCP Thread-Topic: Patches for BOOTP/DHCP code to support Windows Server DHCP Thread-Index: AQHPfUBUW2MQdiTIGUuysOzuLv/2xptcnVgA//+fZCc= Date: Sun, 1 Jun 2014 13:15:55 +0000 Message-ID: References: , <1468927196.9638531.1401624102908.JavaMail.root@uoguelph.ca> In-Reply-To: <1468927196.9638531.1401624102908.JavaMail.root@uoguelph.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-net@freebsd.org" , "freebsd-arm@freebsd.org" , "freebsd-questions@freebsd.org" X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 13:15:58 -0000 Hi Rick, That is an excellent point and a good debate to have. I have not looked in detail at how PXEBOOT does it, but I think a clean up = of the code to somehow pass arguments to the kernel is preferable to having= a diskless client send a slew of needless requests to the DHCP server to r= equest information already requested and obtained in previous stages of the= boot process. The number of DHCP requests made by a client when using U-Bo= ot and ubldr is dizzying. The NFS code will look to see if the boot loader = configuration file has specified the root filesystem through use of vfs.roo= t.mountfrom, so something should be possible. Another area for possible attention is handling the scenario when there are= a number of DHCP servers able to reply to requests. This can happen when y= ou have multiple NICs on segments with DHCP Servers or where you have multi= ple servers on the same segment. The current code just grabs the first serv= er to reply at each stage (going through each NIC in turn) and has affinity= to it for the remainder of that stage but not through the entire boot proc= ess. Regards, John Sent from my iPhone > On Jun 1, 2014, at 19:01, "Rick Macklem" wrote: >=20 > John Howie wrote: >> Hi all, >>=20 >> I apologize for the cross posting of this email, but I believe it >> will be >> of interest to people across all three groups. Please feel free to >> forward >> to additional groups if you feel they would benefit. >>=20 >> I have seen a few posts on and off over the years about Windows >> Server >> DHCP not working with FreeBSD. Specifically, the Windows Server DHCP >> would >> not return the boot host name/IP address and the root path. The >> typical >> response to =B3why won=B9t it work" has typically been that there is a >> flaw in >> Windows Server DHCP code. I did a little digging and found that the >> problem actually lies in code in FreeBSD. >>=20 >> Section 3.5 of RFC 2131 (the DHCP RFC) states that =B3...Second, in its >> initial DHCPDISCOVER or DHCPREQUEST message, a client may provide the >> server with a list of specific parameters the client is interested >> in=8A=B2 >> and =B3...The client can inform the server which configuration >> parameters >> the client is interested in by including the 'parameter request list' >> option. The data portion of this option explicitly lists the options >> requested by tag number=8A=B2. A DHCP Server is not required to return >> any >> parameter that a client does not ask for. It appears that the >> ISC-DHCP >> server, which is recommended by most, will return configured options >> regardless of whether or not the client asks for them. >>=20 >> There are two places in the FreeBSD codebase that DHCP is used to >> boot the >> system over a network. The first is in the boot loader, which uses >> code in >> lib/libstand. The second is in the NFS code, in sys/nfs. The code is >> sys/nfs is not always used if the boot loader sets up the environment >> for >> the NFS code, either by passing parameters to the kernel (as PXEBOOT >> appears to do), or information is configured in the boot loader >> configuration files, e.g. /boot/loader.rc. >>=20 >> I have attached two unified diff files which I ask people to test, >> before >> I submit them for inclusion into the codebase as fixes. The first, >> bootp.c.diff fixes the code in lib/libstand/bootp.c to request the >> boot >> host (option 12, aka TAG_HOSTNAME) and the NFS root path (option 17, >> aka >> TAG_ROOTPATH). This fix has been tested with PXEBOOT on an amd64 box >> and >> ubldr on an ARM/RaspberryPI system. The second, bootp_subr.c.diff, >> fixes >> code in sys/nfs/bootp_subr.c to request the same options and also to >> fix >> bugs that erroneously reported the IP address of the BOOTP/DHCP >> server. >> The code assumed that the BOOTP/DHCP server was also the boot host. >> Please >> send me all feedback directly. >>=20 >> The diff files work with 10.0-RELEASE through 10.0-RELEASE-p3, but >> will >> likely work with 9.0 and also CURRENT and STABLE, including 11.0, as >> the >> code is old code that does not appear to have changed in a while. If >> you >> want to try it on those systems please, please make sure you have >> backup >> copies just in case. >>=20 >> If you do not have experience configuring Windows Server DHCP just >> drop me >> an email, and I will send you a cheat sheet to get you up and >> running. >>=20 >> I am going to grab the latest ubldr code to see if I can get it to >> work >> more like PXEBOOT, that appears to pass parameters to the kernel to >> avoid >> the need for the NFS BOOTP/DHCP process. If you test on an ARM system >> with >> ubldr in RELEASE you will see a lot of unnecessary network activity >> going >> on, that we should be able to fix. > Actually, I tend to think that using the code in sys/nfs/bootp_subr.c > is preferable to using the NFS stuff in stand that pxeboot does. >=20 > The only reason I know for pxeboot doing the NFS stuff and filling in > the nfsv3_diskless structure is historical. (Or that's what most people > use for x86, so it would be a POLA violation if it breaks, if you prefer.= ) > (Basically, the code in sys/nfs/bootp_subr.c is easier to maintain than t= he > stand alone NFS client pxeboot uses.) >=20 > As such, I don't think this work is necessary, rick >=20 >> Regards, >>=20 >> John >>=20 >> john@thehowies.com (personal) | jhowie@email.arizona.edu (academic) | >> j.howie@napier.ac.uk (academic) | jhowie@cloudsecurityalliance.org >> (work) >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to >> "freebsd-net-unsubscribe@freebsd.org"