Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 26 May 2017 20:26:45 +0300
From:      Toomas Soome <tsoome@me.com>
To:        Andriy Gapon <avg@FreeBSD.org>
Cc:        Mariusz Zaborski <oshogbo@FreeBSD.org>, Steven Hartland <smh@FreeBSD.org>,  "George V. Neville-Neil" <gnn@FreeBSD.org>, Baptiste Daroussin <bapt@FreeBSD.org>, Toomas Soome <tsoome@FreeBSD.org>, freebsd-net@FreeBSD.org
Subject:   Re: svn commit: r314948 - in head: lib/libstand sys/boot/i386/libi386
Message-ID:  <9E2DD485-BC28-4DF0-B6EA-22FF63E33D4F@me.com>
In-Reply-To: <c5f695ad-53f8-b5cd-2b20-d3eeefddf7bb@FreeBSD.org>
References:  <201703090601.v2961OJx077853@repo.freebsd.org> <c5f695ad-53f8-b5cd-2b20-d3eeefddf7bb@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help

> 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" 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.
>=20
> 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-mod=
e/
> 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 =
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.
>=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


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.

rgds,
toomas





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9E2DD485-BC28-4DF0-B6EA-22FF63E33D4F>