Re: [edk2-devel] [PATCH v1] NetworkPkg/UefiPxeBcDxe: Fix PXE_BOOT_SERVERS usage in boot info parse flow

["Michael Brown" <mcb30@ipxe.org>]

On 21/08/2020 12:19, Laszlo Ersek wrote:
> On 08/19/20 20:46, Michael Brown wrote:
>> FWIW, iPXE's equivalent logic (based on a combination of what the PXE
>> spec says and what the Intel reference PXE implementation actually does,
>> which is not necessarily the same thing) is to *ignore* PXE_BOOT_SERVERS
>> if a DHCP filename is available and option 43 tag 6 bit 3 is *set*.
> 
> Sorry, I expressed my concern incorrectly (I think I was tripped up by
> the typo in Maciej's commit message).

My fault; I should have read more closely.

> It's about bit#2 in PXE_DISCOVERY_CONTROL.
> 
> The question is whether bit#2 is *equivalent* to adhering to
> PXE_BOOT_SERVERS ("if, and only if").
> 
> When bit#2 is set, the spec says we must. OK.
> 
> When bit#2 is clear, the spec doesn't say anything. So two
> interpretations are possible, "we still may consider PXE_BOOT_SERVERS",
> and "we must not consider PXE_BOOT_SERVERS".

iPXE's interpretation is:

- if bit 2 is set then the subsequent boot server discovery will ignore 
replies from any servers not mentioned (for the selected boot server 
type) in PXE_BOOT_SERVERS

- if bit 2 is clear then the subsequent boot server discovery will 
accept replies from any server

This seems consistent with the spec paragraph stating:

   "If PXE_DISCOVERY_CONTROL bit 2 is set, the client may still use
    multicast and broadcast discovery (if it is permitted by bits 0
    and 1); but the client may only accept replies from servers that
    are identified in the PXE_BOOT_SERVERS option."

> Anyway -- I'm sending this just to explain my earlier email. My main
> point remains:
> 
> http://mid.mail-archive.com/11640b08-6f42-e4d8-356d-91d4bdf86c2c@redhat.com
> 
> (alt link: https://edk2.groups.io/g/devel/message/64530)

Resolving as INVALID seems appropriate to me.

Thanks,

Michael