From owner-freebsd-net@freebsd.org Sat May 27 03:29:37 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 797CCD8417D for ; Sat, 27 May 2017 03:29:37 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5CDAE1E7C; Sat, 27 May 2017 03:29:36 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id v4R3TWYj011341; Fri, 26 May 2017 20:29:32 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id v4R3TUP1011340; Fri, 26 May 2017 20:29:30 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201705270329.v4R3TUP1011340@pdx.rh.CN85.dnsmgr.net> Subject: Re: svn commit: r314948 - in head: lib/libstand sys/boot/i386/libi386 In-Reply-To: <9E2DD485-BC28-4DF0-B6EA-22FF63E33D4F@me.com> To: Toomas Soome Date: Fri, 26 May 2017 20:29:30 -0700 (PDT) CC: Andriy Gapon , Baptiste Daroussin , Mariusz Zaborski , freebsd-net@freebsd.org, "George V. Neville-Neil" , Toomas Soome , Steven Hartland X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 May 2017 03:29:37 -0000 > > On 26. mai 2017, at 12:27, Andriy Gapon 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. -- Rod Grimes rgrimes@freebsd.org