Date: Sun, 1 Jun 2014 17:18:30 -0400 (EDT) From: Rick Macklem <rmacklem@uoguelph.ca> To: John Howie <john@thehowies.com> Cc: freebsd-net@freebsd.org, freebsd-arm@freebsd.org, freebsd-questions@freebsd.org Subject: Re: Patches for BOOTP/DHCP code to support Windows Server DHCP Message-ID: <867385953.9728745.1401657510047.JavaMail.root@uoguelph.ca> In-Reply-To: <E8EA1B3B-407C-403F-BD83-4A42D2FDCEA6@thehowies.com>
next in thread | previous in thread | raw e-mail | index | archive | help
John Howie wrote: > Hi Rick, >=20 > That is an excellent point and a good debate to have. >=20 > 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 request information already requested > and obtained in previous stages of the boot process. The number of > DHCP requests made by a client when using U-Boot 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.root.mountfrom, so something should be possible. >=20 Well, pxeboot uses a standalone nfs client to do all the things that sys/nfs/bootp_subr.c does. I bothered to add NFSv3 to this stand alone nfs client, but there is no way I will be doing NFSv4 for it. (Although I don't see much use for an NFSv4 root fs, a couple of people have already asked about it. To do it, modifying the NFSv4 kernel client code to use the stuff in bootp_subr.c is definitely the way to go.) I have no intention of removing the pxeboot stuff, but I do suspect many would be surprised to see they are still using NFSv2 (with a performance penalty) for the diskless root fs over pxeboot. (If you have a pxeboot built from sources post-r212125 Sep. 2010, it can use NFSv3, but I think you have to specify the "nfsv3" option in the line for "/" in the /etc/fsta= b in the rootfs being exported to the client.) Btw, if you are running a fairly recent system with a diskless NFS root fs, you might want to type "nfsstat -m" to see what it is actually using for th= e root fs. It is mainly the difficulties w.r.t. maintaining lib/libstand/nfs.c which m= akes sys/nfs/bootp_subr.c preferable from my point of view. Anyhow, have fun with it, rick > 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 you have multiple NICs on segments with DHCP Servers > or where you have multiple servers on the same segment. The current > code just grabs the first server 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 process. >=20 > Regards, >=20 > John >=20 > Sent from my iPhone >=20 > > On Jun 1, 2014, at 19:01, "Rick Macklem" <rmacklem@uoguelph.ca> > > 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 =C2=B3why won=C2=B9t it work" has typically been that ther= e 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 =C2=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=C5=A0=C2=B2 > >> and =C2=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=C5=A0=C2=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 the > > 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" > _______________________________________________ > 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" >=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?867385953.9728745.1401657510047.JavaMail.root>