>>>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 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. I'm also trying to fix this bug but unfortunately I'm not having much time. 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. Best, Patrick
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.htmlApparently 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
>>>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