Patches for BOOTP/DHCP code to support Windows Server DHCP

[John Howie]

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.

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"