From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from blyat.fensystems.co.uk (blyat.fensystems.co.uk [54.246.183.96]) by mx.groups.io with SMTP id smtpd.web11.110599.1597930902041936369 for ; Thu, 20 Aug 2020 06:41:43 -0700 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: ipxe.org, ip: 54.246.183.96, mailfrom: mcb30@ipxe.org) Received: from pudding.home (unknown [109.144.222.124]) by blyat.fensystems.co.uk (Postfix) with ESMTPSA id 576FC42C4C; Thu, 20 Aug 2020 13:41:33 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH v1] NetworkPkg/UefiPxeBcDxe: Fix PXE_BOOT_SERVERS usage in boot info parse flow To: devel@edk2.groups.io, maciej.rabeda@linux.intel.com, lersek@redhat.com Cc: Jiaxin Wu , Siyuan Fu , Seven.ding@lcfuturecenter.com References: <20200819165338.681-1-maciej.rabeda@linux.intel.com> <2dde2087-e291-0232-62e2-a30cdf4e09b2@redhat.com> <590e1de9-9f8c-72df-205e-c767f788ecf3@redhat.com> From: "Michael Brown" Message-ID: <4c5fc5c2-6acb-76d9-e8d7-d2743e547627@ipxe.org> Date: Thu, 20 Aug 2020 14:41:33 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on blyat.fensystems.co.uk Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 20/08/2020 11:44, Maciej Rabeda wrote: > @Michael > I am now wondering whether bit 3 is actually relevant to server choice. >=20 > Bit 3: > =3D=3D 0 -> prompt user to choose a boot file. Which means to me: show=20 > minimal menu with prompt (tag 10 - PXE_MENU_PROMPT) and options (tag 9 = -=20 > PXE_BOOT_MENU). > =3D=3D 1 -> do not prompt user. If boot file name is present (option 67= ),=20 > download that boot file. >=20 > Bit 3 does not seem to specify/regulate which server to use. >=20 > Choice of server IP might look like: >=20 > if (option 43 is present, tag 6 is present, tag_6.bit_2 is set and tag = 8=20 > is present and valid) > =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 take server IP from tag 8 (PXE_B= OOT_SERVERS) >=20 > else if (option 66 is present) > =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 take server IP from option 66 (T= FTP server name) >=20 > else if (option 54 is present) > =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 take server IP from option 54 (S= erver Identifier) >=20 > else > =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 failure RFC 2132 defines option 66 as a hostname (not an IP address): it is the=20 equivalent of the non-option "sname" field. RFC 2132 defines option 54 as the DHCP server identifier, which is=20 unrelated to the TFTP server. In the simple case (with no PXE menus involved), the TFTP server IP is=20 provided by the non-option "siaddr" field. If option 60 is set to "PXEClient" and option 43 tag 9 is present and=20 option 43 tag 6 bit 3 is clear then this initiates a convoluted process=20 in which the user is first presented with an interactive menu=20 (constructed from the contents of option 43 tag 9) in order to select a=20 "boot server type", after which a second convoluted process is performed=20 to query the network using a protocol that is almost, but not quite,=20 entirely unlike DHCP. The TFTP server IP and boot filename are=20 eventually taken from the selected response packet in this final=20 almost-DHCP exchange. Michael