From: "Michael Brown" <mcb30@ipxe.org>
To: devel@edk2.groups.io, maciej.rabeda@linux.intel.com, lersek@redhat.com
Cc: Jiaxin Wu <jiaxin.wu@intel.com>, Siyuan Fu <siyuan.fu@intel.com>,
Seven.ding@lcfuturecenter.com
Subject: Re: [edk2-devel] [PATCH v1] NetworkPkg/UefiPxeBcDxe: Fix PXE_BOOT_SERVERS usage in boot info parse flow
Date: Thu, 20 Aug 2020 14:41:33 +0100 [thread overview]
Message-ID: <4c5fc5c2-6acb-76d9-e8d7-d2743e547627@ipxe.org> (raw)
In-Reply-To: <cdc80eb4-daf6-4672-4379-90539f068c01@linux.intel.com>
On 20/08/2020 11:44, Maciej Rabeda wrote:
> @Michael
> I am now wondering whether bit 3 is actually relevant to server choice.
>
> Bit 3:
> == 0 -> prompt user to choose a boot file. Which means to me: show
> minimal menu with prompt (tag 10 - PXE_MENU_PROMPT) and options (tag 9 -
> PXE_BOOT_MENU).
> == 1 -> do not prompt user. If boot file name is present (option 67),
> download that boot file.
>
> Bit 3 does not seem to specify/regulate which server to use.
>
> Choice of server IP might look like:
>
> if (option 43 is present, tag 6 is present, tag_6.bit_2 is set and tag 8
> is present and valid)
> take server IP from tag 8 (PXE_BOOT_SERVERS)
>
> else if (option 66 is present)
> take server IP from option 66 (TFTP server name)
>
> else if (option 54 is present)
> take server IP from option 54 (Server Identifier)
>
> else
> failure
RFC 2132 defines option 66 as a hostname (not an IP address): it is the
equivalent of the non-option "sname" field.
RFC 2132 defines option 54 as the DHCP server identifier, which is
unrelated to the TFTP server.
In the simple case (with no PXE menus involved), the TFTP server IP is
provided by the non-option "siaddr" field.
If option 60 is set to "PXEClient" and option 43 tag 9 is present and
option 43 tag 6 bit 3 is clear then this initiates a convoluted process
in which the user is first presented with an interactive menu
(constructed from the contents of option 43 tag 9) in order to select a
"boot server type", after which a second convoluted process is performed
to query the network using a protocol that is almost, but not quite,
entirely unlike DHCP. The TFTP server IP and boot filename are
eventually taken from the selected response packet in this final
almost-DHCP exchange.
Michael
next prev parent reply other threads:[~2020-08-20 13:41 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-19 16:53 [PATCH v1] NetworkPkg/UefiPxeBcDxe: Fix PXE_BOOT_SERVERS usage in boot info parse flow Maciej Rabeda
2020-08-19 18:13 ` [edk2-devel] " Laszlo Ersek
2020-08-19 18:46 ` Michael Brown
2020-08-21 11:19 ` Laszlo Ersek
2020-08-23 16:24 ` Michael Brown
2020-08-19 19:20 ` Laszlo Ersek
2020-08-20 10:44 ` Maciej Rabeda
2020-08-20 13:41 ` Michael Brown [this message]
2020-08-21 9:11 ` Laszlo Ersek
2020-08-21 10:57 ` 回复: " Ding, Seven
2020-08-21 11:15 ` Maciej Rabeda
2020-08-20 3:35 ` Siyuan, Fu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4c5fc5c2-6acb-76d9-e8d7-d2743e547627@ipxe.org \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox