From owner-freebsd-net@freebsd.org Sat May 27 22:09:41 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 A4325D85F18 for ; Sat, 27 May 2017 22:09:41 +0000 (UTC) (envelope-from kczekirda@gmail.com) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 518FA1959; Sat, 27 May 2017 22:09:41 +0000 (UTC) (envelope-from kczekirda@gmail.com) Received: by mail-qk0-x229.google.com with SMTP id u75so28128506qka.3; Sat, 27 May 2017 15:09:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=YVG2/YcJwUJF2u6E+r4Mq5VOw9XiIn53uibfCj7u/rY=; b=SFXoyDauYusoT/eJ0FL9KhYD8F/tCJ5X7iaSHZTYurfPTo8pJwDdQrrEIYwLIx/f3L RzFIhx9c4NNWIbKvJJoGBMu6Q112oAOaU6BI59Jb7qlhm8SEXDPsaCOtYcBjsS8iuFvp j0890FkxxtOc7EP0+x6DJsLMh7zove+sf9jFUP8LubMFB2dmOx9ljCVJLdoll8w1Az+S 8DKXK7cAiFI0pXiuSWePLHvsgs0CyLZ88C57ZiOlz0Ijym1cgo16NBm8og964/rF00ib 8wrUymHDaDyfhQPeWOyGN9HjB6wkpnM51xI2OnzjJYfyv808Ccqq0k1Z1bWWURdpvtBB Q0Qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=YVG2/YcJwUJF2u6E+r4Mq5VOw9XiIn53uibfCj7u/rY=; b=NW2zJoWPv3mP2R5Z4wSOEgLGbG+H1LWiA9cHi/FAqysSc2esIMj8Rz1iyDtoLxargx gGsZoGIjCiQ6UHs4nFjSzeqF/ACp1ppWet4Lkii9Y6MbD6a3QBzOEMehNGqxtxdSZFHE vNM9PjU7ixXs0Y0+tXzmpEQwLeod7WNuimpDY+j204OI3PXqZ49k/dwxAbG2MCuEYYF/ uS4YldxNPMdcN2MmQ5qKcJwwt7/VChHBEnGJsftxUwACSXqN/Rf1Xbwi8KNMWHnh7nU8 unVNCgmTNc0TH1sPyeHa0JzHsnfpM5oLu2lwPKwFSXSxJDx0D4qU8cyHpMeilRpMGcSI WRbg== X-Gm-Message-State: AODbwcBae4fOh+pUf6d8DxYkbiClT6jiWLOw4IzB9fKb1HG7JMkS/PVm ySo8JKD/NLkcMeBcTzroF6w665QBty7aIaA= X-Received: by 10.233.239.65 with SMTP id d62mr8952232qkg.119.1495922980237; Sat, 27 May 2017 15:09:40 -0700 (PDT) MIME-Version: 1.0 Sender: kczekirda@gmail.com Received: by 10.200.44.139 with HTTP; Sat, 27 May 2017 15:09:09 -0700 (PDT) In-Reply-To: <20170526210908.ykqalqbetxp4f27p@ivaldir.net> References: <201703090601.v2961OJx077853@repo.freebsd.org> <20170526210908.ykqalqbetxp4f27p@ivaldir.net> From: Kamil Czekirda Date: Sun, 28 May 2017 00:09:09 +0200 X-Google-Sender-Auth: --X8tVQ0iJdDeTESL8iNo6s5DYE Message-ID: Subject: Re: svn commit: r314948 - in head: lib/libstand sys/boot/i386/libi386 To: Baptiste Daroussin Cc: Andriy Gapon , Mariusz Zaborski , Steven Hartland , "George V. Neville-Neil" , Toomas Soome , freebsd-net@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 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: Sat, 27 May 2017 22:09:41 -0000 2017-05-26 23:09 GMT+02:00 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. > > I just figured out it also breaks chainloading with ipxe (like qemu does) > and it > does not request the rootpath if not passed to the ipxe first. > > I'm now really thinking the our loader deserves its own DHCP value. > > We should also give it some tags so people can provide it the information > they > want depending on the tags (like hey this is the fbsd loader give it that > rootpath). > > > > > 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. > > > In initial revision I noticed, that I'm not sure it should be default behavior. In a lot of installations pxeloader can base on the cache and doesn't require second, full request with the same answer. In that situation we can switch off bootp() and I think it would be nice to have this switch and give them to users. Flag during compilation is sensible. In very simple and popular case we have chain with four requests for the same information (!): PXE (NIC) -> iPXE -> pxeloader -> dhclient and it's possible to switch off request from iPXE and pxeloader without breaking boot process. Kamil > > 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. > > >