Date: Sat, 27 May 2017 09:54:01 +0200 From: Baptiste Daroussin <bapt@freebsd.org> To: "Rodney W. Grimes" <freebsd-rwg@pdx.rh.CN85.dnsmgr.net> Cc: Toomas Soome <tsoome@me.com>, Andriy Gapon <avg@freebsd.org>, Mariusz Zaborski <oshogbo@freebsd.org>, freebsd-net@freebsd.org, "George V. Neville-Neil" <gnn@freebsd.org>, Toomas Soome <tsoome@freebsd.org>, Steven Hartland <smh@freebsd.org> Subject: Re: svn commit: r314948 - in head: lib/libstand sys/boot/i386/libi386 Message-ID: <20170527075401.xlpzc5odaxpupnsh@ivaldir.net> In-Reply-To: <201705270329.v4R3TUP1011340@pdx.rh.CN85.dnsmgr.net> References: <9E2DD485-BC28-4DF0-B6EA-22FF63E33D4F@me.com> <201705270329.v4R3TUP1011340@pdx.rh.CN85.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <avg@FreeBSD.org> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170527075401.xlpzc5odaxpupnsh>