From owner-freebsd-net@freebsd.org Thu Jun 1 14:17:19 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 65C0FAFDECB for ; Thu, 1 Jun 2017 14:17:19 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 5E33C7B7B6; Thu, 1 Jun 2017 14:17:17 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA24947; Thu, 01 Jun 2017 17:17:15 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1dGQuZ-000Po0-Lw; Thu, 01 Jun 2017 17:17:15 +0300 Subject: Re: svn commit: r314948 - in head: lib/libstand sys/boot/i386/libi386 To: Baptiste Daroussin Cc: Mariusz Zaborski , Steven Hartland , "George V. Neville-Neil" , Toomas Soome , freebsd-net@FreeBSD.org References: <201703090601.v2961OJx077853@repo.freebsd.org> <20170527125616.3c5h4iag3egvq32s@ivaldir.net> From: Andriy Gapon Message-ID: <385ad469-8c20-ada7-21b5-c8fedd6e201d@FreeBSD.org> Date: Thu, 1 Jun 2017 17:16:19 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <20170527125616.3c5h4iag3egvq32s@ivaldir.net> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit 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: Thu, 01 Jun 2017 14:17:19 -0000 On 27/05/2017 15:56, Baptiste Daroussin wrote: > 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? Yes, I can. Thank you! My setup works again. I have some further local changes for which I will open a differential review (or a few of them) soon. -- Andriy Gapon