[syslinux] EFI: PXE: "My IP is 0.0.0.0"

[Gene Cumm]

On Thu, Jun 25, 2015 at 4:55 AM, Patrick Masotta <masottaus at yahoo.com> wrote:
>>>>
>  Looks like the patch mostly addresses the
>  initial search to find the right handle for
>  PXE.  I think I found the remaining source of the
>  issue (the part that's generating the
>  handle->Configure() messages).
>  I'm trying to read through pieces of the EFI spec, gnu-efi API,
>  and a few other sources.  I'm pretty
>  certain you'll see that the previous
>  patch/binaries are sending packets that
>  _should_ be sent on NIC1 out
>  NIC0.--
>  -Gene
> <<<
>
> Hi Gene
> have you seen this thread?
> http://www.syslinux.org/archives/2015-April/023436.html
> continued here
> http://www.syslinux.org/archives/2015-May/023443.html

Apparently I tagged it in my email but never got around to reading it yet.

> Cao's patch try to solve the same multi-NIC issue you are dealing with;
>
> Your approach detect's the right NIC at
> pxe.c\net_parse_dhcp(void)
> but it is also necessary to detect the right NIC again at
> main.c\efi_create_binding()
> as explained here.
> http://www.syslinux.org/archives/2015-May/023453.html
> Cao's patch fails doing this because it relies on certain assumptions on
> handle "order" that are not correct.

The key is that the handle _itself_ is the proper link between the
EFI_PXE_BASE_CODE_PROTOCOL and EFI_UDP4_SERVICE_BINDING_PROTOCOL.
_IT_ is the piece that must be stored and reused.

I found this thanks to a Google search "EFI_PXE_BASE_CODE_PROTOCOL
EFI_MANAGED_NETWORK_PROTOCOL" and
http://sourceforge.net/p/edk2/mailman/message/31604654/ where Laszlo
Ersek showed the output of a command that made things "click" in my
mind to understand the relationship.

> I'm also trying to fix this bug but unfortunately I'm not having much time.

I just need to publish mine.

> This is the approach I'm going to try:
> 1) detecting the right NIC at pxe.c\net_parse_dhcp(void) (as you do)
> 2) saving its associated MAC address.
> 3) at main.c\efi_create_binding()    (let's consider the UDP case)
> LibLocateHandle() returns the handles of the devices that publish a EFI
> UDPv4 Service Binding Protocol GUID. Each device with a published EFI UDPv4
> Service Binding Protocol GUID supports the EFI UDPv4 Protocol and may be available for use.
> Considering a "Device Path Protocol" is attached to device handles then
> I think parsing the Path Protocol of each returned handle we can detect the
> "MAC Address Device Path" structure and get the associated MAC address.
> The returned handle that has a MAC address matching the one previously saved at
> pxe.c\net_parse_dhcp(void) should be the one that has to be used creating a child of
> EFI UDPv4 Protocol.
>
> I'm looking for a simpler way to do this but so far I haven't found it.

Done.  See above.

Now, as for the case of multiple potentially valid handles with
EFI_PXE_BASE_CODE_PROTOCOL, this would completely invalidate the idea
of a search.  If there are multiple handles with
EFI_PXE_BASE_CODE_PROTOCOL data that could be usable, it's impossible
to perform a valid search.  If an implementation does in fact do this,
we must find a completely different way to query the EFI firmware for
the proper handle.

Consider the case of PXE booting NIC-1 then the NBP decides to abort
and return control to the EFI firmware (presuming this is possible; I
haven't tested LOCALBOOT yet) then boot NIC-2 and load Syslinux.  How
do we know which is valid?  Presume NIC-1 had a filename
"syslinux.efi" while NIC-2 "bootx64.efi".  Now consider if NIC-3 came
first in the boot order.

-- 
-Gene