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

[Patrick Masotta]

>>>
 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.
<<<

This is somehow surprising but dumping handles at the shell I've verified that 
in my VMware UEFI client the Pxebc protocol and all the Service binding protocols 
(including UDPv4Sb) corresponding to one particular NIC (on a 2 NIC client) share 
"the same" handle #.

I wonder if we can really rely on this. I'm trying to find in the UEFI 2_5.pdf and 
UEFI_Driver_Writer_Guide_V1.0.1_120308.pdf something supporting this fact
but so far I cannot find anything...


 >>>
 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.
 <<<

i.e. a PC with two NICs connected to 2 Networks with PXE servers on it.
Probably we should think about this later. I'm more concern about the validity 
of the previous handle assumption.


>>>
 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.
 <<<

Yes I know what you mean;
"I think" the handle of the running image (our code) has a "path" telling us where
was laded from. That would solve this thing.

Best,
Patrick