> > 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. -- Rod Grimes rgri...@freebsd.org _______________________________________________ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
