Patches for BOOTP/DHCP code to support Windows Server DHCP

[Rick Macklem]

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"