Patches for BOOTP/DHCP code to support Windows Server DHCP

[Rick Macklem]

John Howie wrote:
> 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 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.
> 
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/fstab
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 the
root fs.

It is mainly the difficulties w.r.t. maintaining lib/libstand/nfs.c which makes
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.
> 
> Regards,
> 
> John
> 
> Sent from my iPhone
> 
> > On Jun 1, 2014, at 19:01, "Rick Macklem" <rmacklem at uoguelph.ca>
> > wrote:
> > 
> > John Howie wrote:
> >> Hi all,
> >> 
> >> 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.
> >> 
> >> 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 ³why won¹t 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.
> >> 
> >> Section 3.5 of RFC 2131 (the DHCP RFC) states that ³...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Š²
> >> and ³...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Š². 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.
> >> 
> >> 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.
> >> 
> >> 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.
> >> 
> >> 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.
> >> 
> >> 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.
> >> 
> >> 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.
> > 
> > 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.)
> > 
> > As such, I don't think this work is necessary, rick
> > 
> >> Regards,
> >> 
> >> John
> >> 
> >> john at thehowies.com (personal) | jhowie at email.arizona.edu
> >> (academic) |
> >> j.howie at napier.ac.uk (academic) | jhowie at cloudsecurityalliance.org
> >> (work)
> >> 
> >> 
> >> 
> >> 
> >> _______________________________________________
> >> freebsd-net at freebsd.org mailing list
> >> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> >> To unsubscribe, send any mail to
> >> "freebsd-net-unsubscribe at freebsd.org"
> _______________________________________________
> freebsd-net at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to
> "freebsd-net-unsubscribe at freebsd.org"
>