Syslinux - Jun 2015 - EFI: PXE: "My IP is 0.0.0.0"

On Fri, Jun 26, 2015 at 10:49 AM, Patrick Masotta <masottaus at yahoo.com>
wrote:
>>>>
>  Commit 23b2707 should resolve this.  Please
>  let me know if you need
>  test binaries
>
>  --
>  -Gene
>  <<<
>
>
> 1)  About the Service Binding protocols, PXE protocol, etc having the same
handle# is clear if we
> see that the number is in fact the "Device Handle" supporting all
those protocols.
> (clearly said at UEFI_Driver_Writer_Guide_V1.0.1_120308.pdf)
It's a handle to the device that loaded Syslinux, in this case a NIC
plus IP-stack (IPv4 or IPv6).
> 2) about your last commit
> 2.1) I think I found a couple of issues check them corrected at
> https://github.com/ppatpat/syslinux/
>
>   a) a missing return; on an error condition at efi/pxe.c\net_parse_dhcp()
>   b) you close a protocol before creating its child at
efi/main.c\efi_create_binding()
Rewrote the commit messages and it's in at commit ID 5186539
> 2.2) I think "image_DeviceHandle" instead of
"pxe_DeviceHandle" produces a code easier to follow;
> specially when we end up using that handle to create a TCP4 or UDP4
child...
Not all handles are devices but all usable devices have handles.  The
image_handle is a type EFI_LOADED_IMAGE_PROTOCOL, not a device.
pxe_handle could perhaps be renamed as nic_handle or device_handle.

-- 
-Gene

>>>
 It's a handle to the device that loaded Syslinux, in this case a NIC
 plus IP-stack (IPv4 or IPv6).
 <<<

Yes it is the handle of the device (NIC) that loaded syslinux
plus IP stack (as you said) but also all the attached Service Binding Protocols,
PXE Protocol, and some more. All of them sharing the same device handle.

 
>>>
> 2.2)
> I think "image_DeviceHandle" instead of
> "pxe_DeviceHandle" produces a code easier to follow;
> specially when we end up using
> that handle to create a TCP4 or UDP4 child...
 
 Not all handles are devices but all usable devices have handles.? The
 image_handle is a type EFI_LOADED_IMAGE_PROTOCOL, not a device.
 pxe_handle could perhaps be renamed as nic_handle or device_handle.
 
 -- 
 -Gene
 <<<

We already have "image_handle" that (as you say) corresponds to the
EFI_LOADED_IMAGE_PROTOCOL
I think that "image_DeviceHandle" would clearly represent the
DeviceHandle associated to the loaded image.
I use "image_DeviceHandle" in my codebase; if you call it nic_handle
or device_handle you miss the
association with the current loaded image. Just my 2 cents; not big deal on
this.

Best,
Patrick

OK there are problems.

From
https://sourceforge.net/p/edk2/mailman/message/31604654/
""In current EDKII implementation, all the network servicebinding
protocols for a
NIC device are installed together on the NIC's device handle, so you can get
all
of them when you have chosen a special NIC handle.""

Unfortunately there are PCs with UEFI implementations not following the former
rule.

i.e. HP Elitebook 2570p (single NIC)

shell> dh
...
172: DevPath (..9,0x0)/MAC(FC15B4E81CAC,0x0))Net MNPSb ARPSb DHCPv4Sb TCPv4Sb
IPv4Sb IPv4Config UDPv4Sb MTFTPv4Sb
...
184: DevPath (..00:0000:0000:0000:0000:0000))Load Net Pxebc 
...
19D: DevPath (..v4(0.0.0.0,UDP,DHCP,0.0.0.0))Load Net Pxebc
...

shell> dh 172
Handle 172 (730D8A98)
   Dpath (730D8E98) 
      ACPI Device Path for Acpi
       HID PNP0A03, UID 0
      Hardware Device Path for PCI
       Function (0) Device (19)
      Messaging Device Path for MAC
       MAC (FC15B4E81CAC)
      AsStr: 'PciRoot(0x0)/Pci(0x19,0x0)/MAC(FC15B4E81CAC,0x0)'
   Net (730C5020) 
   MNPSb (722D0F40) 
   ARPSb (722C13A0) 
   DHCPv4Sb (722C4220) 
   TCPv4Sb (722A7330) 
   IPv4Sb (72DF2A20) 
   IPv4Config (722AF638) 
   UDPv4Sb (722A3EA0) 
   MTFTPv4Sb (7229B4A0) 
   D79DF6B0-EF44-43BD-9797-43E93BCF5FA8 (722A6318)
...

shell> dh 184
Handle 184 (722AE898)
   Dpath (722ADA18) 
      ACPI Device Path for Acpi
       HID PNP0A03, UID 0
      Hardware Device Path for PCI
       Function (0) Device (19)
      Messaging Device Path for MAC
       MAC (FC15B4E81CAC)
      Messaging Device Path for IPv6
       IPv6 (Not Available)
      AsStr:
'PciRoot(0x0)/Pci(0x19,0x0)/MAC(FC15B4E81CAC,0x0)/IPv6(0000:0000:0000:0000:0000:0000:0000:0000,UDP,DHCP,0000:0000:0000:0000:0000:0000:0000:0000)'
   Load (722BB7A8) 
   Net (730C5020) 
   Pxebc (722B0110) 

shell> dh 19D
Handle 19D (72284598)
   Dpath (72284618) 
      ACPI Device Path for Acpi
       HID PNP0A03, UID 0
      Hardware Device Path for PCI
       Function (0) Device (19)
      Messaging Device Path for MAC
       MAC (FC15B4E81CAC)
      Messaging Device Path for IPv4
       IPv4 (Local IP: 0.0.0.0:0)
            (Remote IP: 0.0.0.0:0)
            (Protocol: 0)
            (Source IP: DHCP)
      AsStr:
'PciRoot(0x0)/Pci(0x19,0x0)/MAC(FC15B4E81CAC,0x0)/IPv4(0.0.0.0,UDP,DHCP,0.0.0.0)'
   Load (72284728) 
   Net (730C5020) 
   Pxebc (722B0110) 

The booting syslinux.efi receives DeviceHandle = 19D (IPv4); this handle has
also attached to it the Pxebc Protocol
but it does not have attached the Service Binding Protocol UDPv4Sb (in this case
under the handle 172 instead).

The HP 2570p is not really an old PC (~2013) then I can think if we continue
using the "same handle" method we will have
problems PXE booting lot of UEFI PCs.
I think when we receive the image_DeviceHandle we must save it but also parse
the associated DevicePath saving the MAC address too.
When looking for Pxebc Protocol we can use the image_DeviceHandle, next when
ServiceBinding we need to detect
all the available SB handles of the required type, parse their DevicePath and
take the one with a matching MAC.

Let me know if you see any alternative to MAC parsing considering this new info.

Best,
Patrick