svn commit: r314948 - in head: lib/libstand sys/boot/i386/libi386

[Baptiste Daroussin]

On Fri, May 26, 2017 at 12:27:45PM +0300, 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

I should have been all fixed in head (including some sugar added)

Can you confirm?

Best regards,
Bapt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-net/attachments/20170527/e3ae1ec7/attachment.sig>