From owner-freebsd-net@freebsd.org Fri May 26 09:29:15 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 EAD9AD7B49A for ; Fri, 26 May 2017 09:29:15 +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 1CA02102E; Fri, 26 May 2017 09:29:13 +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 MAA06268; Fri, 26 May 2017 12:29:06 +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 1dEBYQ-000IAN-Fz; Fri, 26 May 2017 12:29:06 +0300 From: Andriy Gapon Subject: Re: svn commit: r314948 - in head: lib/libstand sys/boot/i386/libi386 To: Mariusz Zaborski , Steven Hartland , "George V. Neville-Neil" , Baptiste Daroussin , Toomas Soome References: <201703090601.v2961OJx077853@repo.freebsd.org> Cc: freebsd-net@FreeBSD.org Message-ID: Date: Fri, 26 May 2017 12:27:45 +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: <201703090601.v2961OJx077853@repo.freebsd.org> Content-Type: text/plain; charset=utf-8 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: Fri, 26 May 2017 09:29:16 -0000 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