On Fri, May 26, 2017 at 08:29:30PM -0700, Rodney W. Grimes wrote: > > > On 26. mai 2017, at 12:27, Andriy Gapon <a...@freebsd.org> wrote: > > > > > > On 09/03/2017 08:01, Mariusz Zaborski wrote: > > >> Author: oshogbo > > >> Date: Thu Mar 9 06:01:24 2017 > > >> New Revision: 314948 > > >> URL: https://svnweb.freebsd.org/changeset/base/314948 > > >> > > >> Log: > > >> Try to extract the RFC1048 data from PXE. If we get enough info we can > > >> skip > > >> the bootp(). It removes unnecessary DHCP request from pxeloader. > > >> > > >> Submitted by: kczekirda > > >> Sponsored by: Oktawave > > >> Initiated by: Matthew Dillon > > >> Reviewed by: smh, gnn, bapt, oshogbo > > >> MFC after: 3 weeks > > >> Differential Revision: https://reviews.freebsd.org/D9847 > > > > > > Sorry for being late to the party, but this being head hopefully not too > > > late. > > > > > > I am not sure that I agree with the spirit of this change. > > > > > > There are network boot setups that do depend on the "unnecessary" DHCP > > > request > > > from pxeboot. For example, a DHCP server could be configured to return a > > > different set of parameters depending on a particular PXE client. I > > > personally > > > use a configuration where the DCHP server sends a boot menu[*] to a PXE > > > client > > > that's built into network cards. If a FreeBSD boot is selected and > > > pxeboot is > > > started, then the server sends parameters required for the FreeBSD boot > > > (root-path, etc) in response to the request from pxeboot. > > > I don't see how I can keep that working after this change. > > > > > > Additionally, as far as I can tell, we only get cached > > > PXENV_PACKET_TYPE_BINL_REPLY. This might cause a problem in environments > > > where > > > a separate PXE server (Proxy DHCP) is used. In that case the reply might > > > not > > > have the network configuration information which would actually be in > > > PXENV_PACKET_TYPE_DHCP_ACK. > > > An example of such a setup is described here: > > > https://n0dy.com/blog/2014/09/14/network-booting-with-dnsmasq-in-proxy-mode/ > > > Using a separate PXE server is not uncommon in corporate environments too. > > > > > > In general, I think that the change was not thought through to cover > > > scenarios > > > beyond the basic unattended, FreeBSD-only, single DHCP server network > > > boots. > > > That scenario is, of course, very common, but it is not the only one. > > > > > > At minimum, I would like to have a compile time option to control whether > > > pxeboot should send a DHCP request of its own or rely entirely on the > > > cached > > > information. Or maybe pxeboot could be smart enough to do the former if > > > the > > > cached reply is missing some required information like the root-path. > > > Right now, there is no bootp(BOOTP_PXE) under any conditions. > > > > > > And my apologies again for missing the original discussion. > > > My focus was somewhere else at the time. > > > > > > [*] It uses PXE_BOOT_MENU and PXE_MENU_PROMPT vendor options for that. > > > > > > References: > > > http://www.pix.net/software/pxeboot/archive/pxespec.pdf > > > -- > > > Andriy Gapon > > > > > > Yep, there was some discussion added after the commit, and IMO the only > > real conclusion was that this whole topic needs some more thinking. Also I > > do not think the holy grail should be reusing the initial ACK - it may be > > providing enough information for simple setups, but is most certainly not > > enough for more complex ones as you just did describe. Also, it did became > > quite clear that there are some different views on the issue, so IMO we > > need to take some time to collect the ideas and then figure what is the > > best way there. > > > > It is starting to become very clear that we do infact need to > do a full on DHCP request, hopefully with a unique client > string to indicate to the dhcp server that this is the freebsd > loader making the request. This would lead to a great deal > of flexiability for those of use using complicated PXE boot > menus and infustructure supporting much more than just FreeBSD > as a client. > > The fact that FreeBSD does not do this has made it more > difficult to deal with than it should be when adding it > to a network boot infustructure. >
This addresses it: https://reviews.freebsd.org/D10951 defining a FREEBSD user class on dhcp request. I plan to remove the BOOTP_PXE option afterward to always boot with a full dhcp request no need to differentiate BOOTP_PXE and others. Best regards, Bapt
signature.asc
Description: PGP signature
