From owner-freebsd-net@freebsd.org Sat May 27 07:54:02 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 9A9ABD84810 for ; Sat, 27 May 2017 07:54:02 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 783121CAE; Sat, 27 May 2017 07:54:02 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1235) id A27BCCE3; Sat, 27 May 2017 07:54:01 +0000 (UTC) Date: Sat, 27 May 2017 09:54:01 +0200 From: Baptiste Daroussin To: "Rodney W. Grimes" Cc: Toomas Soome , Andriy Gapon , Mariusz Zaborski , freebsd-net@freebsd.org, "George V. Neville-Neil" , Toomas Soome , Steven Hartland Subject: Re: svn commit: r314948 - in head: lib/libstand sys/boot/i386/libi386 Message-ID: <20170527075401.xlpzc5odaxpupnsh@ivaldir.net> References: <9E2DD485-BC28-4DF0-B6EA-22FF63E33D4F@me.com> <201705270329.v4R3TUP1011340@pdx.rh.CN85.dnsmgr.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="sspro6sax76c56wp" Content-Disposition: inline In-Reply-To: <201705270329.v4R3TUP1011340@pdx.rh.CN85.dnsmgr.net> User-Agent: NeoMutt/20170428 (1.8.2) 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 07:54:02 -0000 --sspro6sax76c56wp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 26, 2017 at 08:29:30PM -0700, Rodney W. Grimes wrote: > > > On 26. mai 2017, at 12:27, Andriy Gapon wrote: > > >=20 > > > 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 > > >>=20 > > >> 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. > > >>=20 > > >> 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 > > >=20 > > > Sorry for being late to the party, but this being head hopefully not = too late. > > >=20 > > > I am not sure that I agree with the spirit of this change. > > >=20 > > > There are network boot setups that do depend on the "unnecessary" DHC= P request > > > from pxeboot. For example, a DHCP server could be configured to retu= rn 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 P= XE client > > > that's built into network cards. If a FreeBSD boot is selected and p= xeboot is > > > started, then the server sends parameters required for the FreeBSD bo= ot > > > (root-path, etc) in response to the request from pxeboot. > > > I don't see how I can keep that working after this change. > > >=20 > > > Additionally, as far as I can tell, we only get cached > > > PXENV_PACKET_TYPE_BINL_REPLY. This might cause a problem in environm= ents where > > > a separate PXE server (Proxy DHCP) is used. In that case the reply m= ight 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-prox= y-mode/ > > > Using a separate PXE server is not uncommon in corporate environments= too. > > >=20 > > > 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. > > >=20 > > > At minimum, I would like to have a compile time option to control whe= ther > > > 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. > > >=20 > > > And my apologies again for missing the original discussion. > > > My focus was somewhere else at the time. > > >=20 > > > [*] It uses PXE_BOOT_MENU and PXE_MENU_PROMPT vendor options for that. > > >=20 > > > References: > > > http://www.pix.net/software/pxeboot/archive/pxespec.pdf > > > --=20 > > > Andriy Gapon > >=20 > >=20 > > 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 e= nough for more complex ones as you just did describe. Also, it did became q= uite 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 wa= y there. > >=20 >=20 > 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. >=20 > 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. >=20 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 --sspro6sax76c56wp Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEgOTj3suS2urGXVU3Y4mL3PG3PloFAlkpMJUACgkQY4mL3PG3 PloAChAAlitSCfghc2Z/3DUFotuFKWVYSAA47l+78swhI0ZBwPrxn+yos75xXL22 PrjTdAbTkSYM6TwqIS+YBb5p5ZElBPMkU+WqPyE3kZtqnZYnMkWgO4Beov0FMCt3 7wnVB+MKyw+MTkhwpqoMSAfxx4aKKk81AZLiOCJnZwmRuGzkZwsQK+z6wnduwbiF kC9HN5sb+S6pWTsGRTLIeplmIT2SUuAe594fAN95uvG4zEMa2us/x5XHZPuSqquR PizkJa507BDVRTusSsFxApagNzIxE9yBweqoxAWKxCYDBNWWYHTrdZl+IKOw7lKy SBtGijU1CWE7Gla3ulDiS5zcodlO61C7v6RTQDkUBPUMagIwApbtVuTzTljvYjtX 7lwrIDTgLogvrjW2LjDQXAh4i35Fsnm0E8QD48HY697OGQaZ6Sx+2mi71Qeu/jvc h7YayvXIeKg1xQ9GbG+9m/EHwbEmS1fm2Ihj6KjxaPlEVL0VLB1opRlPLcCJd2zS 63EdsJzc/xx2dBMA+HEdqBQA6kb2NijOhYJ96DQMjT6FKGz4Z84BmxpQ9i44GxmP jWChsdeetZMe48WO7iG366sqNVoR/1nZriJ1pfl3gmfLtlcuvPBhB4l2ezWG4qXi 2YT8H+sTzEX/GmwLupsbVCDmw9D5UDqJ4S9NJD6P1JTb7BSj/sg= =dXwx -----END PGP SIGNATURE----- --sspro6sax76c56wp--