From owner-freebsd-net@freebsd.org Fri May 26 18:26:59 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 405C1D83246 for ; Fri, 26 May 2017 18:26:59 +0000 (UTC) (envelope-from tsoome@me.com) Received: from st13p35im-asmtp002.me.com (st13p35im-asmtp002.me.com [17.164.199.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 168A31D20; Fri, 26 May 2017 18:26:59 +0000 (UTC) (envelope-from tsoome@me.com) Received: from process-dkim-sign-daemon.st13p35im-asmtp002.me.com by st13p35im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0OQK00300LLJI700@st13p35im-asmtp002.me.com>; Fri, 26 May 2017 17:26:49 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=4d515a; t=1495819609; bh=Uo8VYNpPnGzO7Lu2HttvBGMkOQSUaXrhMYXFTYZO0Vc=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=bYUs4LgOXARHRBN8vkhJmZsiOd4vcC2mpyWIWgM9QnbDdOIgLQjw8D2CwPL7EvD5p XJ6Kap+u7fyl/mwJQQYNmaGPb2b50rpxZ6QlVDhf9Hun6qLgc8c6MfV35L34L07cEw oVVfyCLqz4/ZhdQHv0SaLeIRupDYyhKyT/4ESf9h/UKKgWPUg5idn47LFBYRU4BzSy /hoiyn+lsL3TXQ6FzV4XJVNZawf6XimGLN9GabFIWn9nWu/XWH0nE8E2UP8M35Ziu7 5p+O+b5/4giSQO6Dsw7iQxgh6bfFv9GL7T+Q25sUY1KK5v7cHvn/8uxEdTeZl+7weO NoH1zYFj4GS+Q== Received: from icloud.com ([127.0.0.1]) by st13p35im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0OQK00C6LLSLP610@st13p35im-asmtp002.me.com>; Fri, 26 May 2017 17:26:49 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-05-26_12:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=2 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1701120000 definitions=main-1705260310 Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: svn commit: r314948 - in head: lib/libstand sys/boot/i386/libi386 From: Toomas Soome In-reply-to: Date: Fri, 26 May 2017 20:26:45 +0300 Cc: Mariusz Zaborski , Steven Hartland , "George V. Neville-Neil" , Baptiste Daroussin , Toomas Soome , freebsd-net@FreeBSD.org Content-transfer-encoding: quoted-printable Message-id: <9E2DD485-BC28-4DF0-B6EA-22FF63E33D4F@me.com> References: <201703090601.v2961OJx077853@repo.freebsd.org> To: Andriy Gapon X-Mailer: Apple Mail (2.3273) 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 18:26:59 -0000 > On 26. mai 2017, at 12:27, Andriy Gapon 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