>>>> 1) There's not "any" SB protocol present (Elitebook 8460p/2560p) The only solution for these is to use our own stack (likely full TCP/IP like lwIP) and connect to the Net GUID (EFI_SIMPLE_NETWORK_PROTOCOL).? Does the handle for Pxebc contain a Net??>>>It does contain a Net but there are 2 issues with SNP: 1) The interface is different than UDPv4/TCPv4 protocols; this imply lot of code. 2) SNP has its non-blocking transmit issues ; see "Flaws in the design" at https://wiki.linaro.org/LEG/Engineering/Kernel/UEFI/UEFI_Network_Driver>>>I found out that my EFI shell on VMware VMs can also handle output redirection like: guid > fs0:\efi-guid.txt dh > fs0:\efi-dh.txt dh bd >> fs0:\efi-dh.txt fs0 being the EFI boot partition on the hard drive of the VM. <<< Yes, but I use empty virtual clients when testing Syslinux PXE then I prefer redirecting console commands to a USB pendrive >>> > 2) SB protocols are loaded under a different that LoadeImage's DeviceHandle, > while Pxebc is loaded under the LoadeImage's DeviceHandle. (Elitebook 8470p/2570p) a) Hunt for a Sb. b) use Net <<< I do a hunt for either UDPv4Sb or TCPv4Sb>>>> 3) SB protocols and Pxebc are loaded under the LoadeImage's DeviceHandle (VMware Workstation 10). a) use Sb on Pxebc handle b) use Net <<< I reuse the "Hunt for a Sb" approach (the overhead is not much) but I could easily use a)>>>> About MNPSb; even when it presents the same interface than all the Service Binding protocols > remember we have to create a child of the particular matching protocol and those do not have > the same interface. Correct, different interface but it seems dominantly the same EFI_HANDLE. <<< So far I've seen MNPSb is only available when the rest of SBs are also present then it makes no sense embracing a new MNP protocol when UDPv4Sb and TCPv4Sb are also available.>>>> I kept testing my patch and so far it proved to work in a multi-NIC environment: > I've set a VMware EFI client with 2 NICs connected to the same network, > using the VMware? DHCP server and Serva as proxyDHCP. > Setting a MAC filter in Serva I forced the client not receiving PXE redirection parameters > alternative on NIC_1 or NIC_2; the client always booted correctly from the NIC that received the > full set of PXE parameters. It seems to work. This sounds positive for cases 2&3 but still leaves #1 high and dry. <<< Case #1 is really a problem; the only alternative would be implementing SNP but as I've mentioned before this approach also has its issues... I also wonder if UEFI firmware w/o SB protocols is really UEFI compliant... i.e the Elitebook 8460p is an early 2011 model that probably should receive a firmware update including the missing SB protocols... I think the best alternative would be implementing SNP and use it as last resort "only" for Case #1. >>> Debating if this hunting should be more persistent so we don't go hunting at every binding.? It shouldn't affect large files but could affect lots of tiny files if we're hunting every time.? If it's to be more persistent, a table of known GUIDs to match to a handle should be stored. -- -Gene <<< I thought of it but I do not know if there's really much to get here; i.e. in a 4 NIC PC the parsing only involves 4 UDPv4Sb (or TCPv4Sb) handles. Anyway it can definitely be done if necessary. Best Patrick
On Thu, Jul 9, 2015 at 5:30 AM, Patrick Masotta <masottaus at yahoo.com> wrote:>>>> > > 1) There's not "any" SB protocol present (Elitebook 8460p/2560p) > > The only solution for these is to use our own stack (likely full > TCP/IP like lwIP) and connect to the Net GUID (EFI_SIMPLE_NETWORK_PROTOCOL). > Does the handle for Pxebc contain a Net? >>>> > > It does contain a Net but there are 2 issues with SNP: > 1) The interface is different than UDPv4/TCPv4 protocols; this imply lot of code.Not as much as you may think. We already have lwIP implemented into lpxelinux.0. It's more a matter of using more glue.> 2) SNP has its non-blocking transmit issues ; see "Flaws in the design" at > https://wiki.linaro.org/LEG/Engineering/Kernel/UEFI/UEFI_Network_Driverhttps://wiki.linaro.org/LEG/Engineering/Kernel/UEFI/UEFI_Network_Driver#Flaws_in_the_design certainly gives some things to think about. As a side note, I'd expect anything that used SNP should be able to shut everything else off and have to implement enough of a TCP/IP stack to be proper for its uses (ie no need to implement TCP or respond to TCP if it doesn't use TCP yet should respond to ARP requests).> >>> > > 2) SB protocols are loaded under a different that LoadeImage's DeviceHandle, > > while Pxebc is loaded under the LoadeImage's DeviceHandle. (Elitebook 8470p/2570p) > > a) Hunt for a Sb. > b) use Net > <<< > > I do a hunt for either UDPv4Sb or TCPv4SbJust summarizing choices.>>>> > > 3) SB protocols and Pxebc are loaded under the LoadeImage's DeviceHandle (VMware Workstation 10). > > a) use Sb on Pxebc handle > b) use Net > <<< > I reuse the "Hunt for a Sb" approach (the overhead is not much) but I could easily use a) > > >>>> > > About MNPSb; even when it presents the same interface than all the Service Binding protocols > > remember we have to create a child of the particular matching protocol and those do not have > > the same interface. > > Correct, different interface but it seems dominantly the same EFI_HANDLE. > <<< > > So far I've seen MNPSb is only available when the rest of SBs are also present then > it makes no sense embracing a new MNP protocol when UDPv4Sb and TCPv4Sb are also > available.Correct, MNPSb is the parent. We'd only use it if we wanted to create a new protocol like a TCP replacement which I expect is out of scope. My point is that unless the rule was set early, I'd expect to eventually find an oddball client where UDPSb and TCPSb live on different EFI_HANDLEs (but presumably still under an MNPSb).>>>> > > I kept testing my patch and so far it proved to work in a multi-NIC environment: > > I've set a VMware EFI client with 2 NICs connected to the same network, > > using the VMware DHCP server and Serva as proxyDHCP. > > Setting a MAC filter in Serva I forced the client not receiving PXE redirection parameters > > alternative on NIC_1 or NIC_2; the client always booted correctly from the NIC that received the > > full set of PXE parameters. It seems to work. > > This sounds positive > for cases 2&3 but still leaves #1 high and dry. > <<< > > Case #1 is really a problem; the only alternative would be implementing SNP but as I've > mentioned before this approach also has its issues... > I also wonder if UEFI firmware w/o SB protocols is really UEFI compliant... > i.e the Elitebook 8460p is an early 2011 model that probably should receive a firmware update > including the missing SB protocols...What firmware version is loaded? Available?> I think the best alternative would be implementing SNP and use it as last resort > "only" for Case #1. > > > >>> > Debating if this hunting should be more persistent so we don't go > hunting at every binding. It shouldn't affect large files but could > affect lots of tiny files if we're hunting every time. If it's to > be more persistent, a table of known GUIDs to match to a handle should be stored. > > -- > -Gene > <<< > I thought of it but I do not know if there's really much to get here; > i.e. in a 4 NIC PC the parsing only involves 4 UDPv4Sb (or TCPv4Sb) handles. > Anyway it can definitely be done if necessary.It's also a question of how fast the firmware bothers to be. Considering our rate, this in theory shouldn't matter. -- -Gene
On Thu, Jul 9, 2015 at 8:10 PM, Gene Cumm <gene.cumm at gmail.com> wrote:> On Thu, Jul 9, 2015 at 5:30 AM, Patrick Masotta <masottaus at yahoo.com> wrote:>> Case #1 is really a problem; the only alternative would be implementing SNP but as I've >> mentioned before this approach also has its issues... >> I also wonder if UEFI firmware w/o SB protocols is really UEFI compliant... >> i.e the Elitebook 8460p is an early 2011 model that probably should receive a firmware update >> including the missing SB protocols... > > What firmware version is loaded? Available?Oh how fun. UEFI Specifications version 2.0 states "An EFI_PXE_BASE_CODE_PROTOCOL will be layered on top of an EFI_SIMPLE_NETWORK_PROTOCOL protocol in order to perform packet level transactions." while version 2.1 states "An EFI_PXE_BASE_CODE_PROTOCOL will be layered on top of an EFI_MANAGED_NETWORK_PROTOCOL protocol in order to perform packet level transactions." -- -Gene
>>>> It does contain a Net but there are 2 issues with SNP: > 1) The interface is different than UDPv4/TCPv4 protocols; this imply lot of code. Not as much as you may think.? We already have lwIP implemented into lpxelinux.0.? It's more a matter of using more glue. > 2) SNP has its non-blocking transmit issues ; see "Flaws in the design" at > https://wiki.linaro.org/LEG/Engineering/Kernel/UEFI/UEFI_Network_Driver#Flaws_in_the_design certainly gives some things to think about. As a side note, I'd expect anything that used SNP should be able to shut everything else off and have to implement enough of a TCP/IP stack to be proper for its uses (ie no need to implement TCP or respond to TCP if it doesn't use TCP yet should respond to ARP requests).>>>OK, at the moment the updated code should be able to deal with cases #2 and #3 Let's put a pin on SNP for case #1 and see what the multi-NIC users report from the current patch. What do you think?>>>> > So far I've seen MNPSb is only available when the rest of SBs are also present then > it makes no sense embracing a new MNP protocol when UDPv4Sb and TCPv4Sb are also > available. Correct, MNPSb is the parent.? We'd only use it if we wanted to create a new protocol like a TCP replacement which I expect is out of scope. My point is that unless the rule was set early, I'd expect to eventually find an oddball client where UDPSb and TCPSb live on different EFI_HANDLEs (but presumably still under an MNPSb). <<< The current code either looks for UDPSb handles (or TCPSb depending on the received bgiud), then it really does not matter if UDPSb and TCPSb are created under different handles. As soon as I get the array of UDPSb (or TCPSb ) handles I parse their associated Path Protocol looking for the matching MAC.>>>> I also wonder if UEFI firmware w/o SB protocols is really UEFI compliant... > i.e the Elitebook 8460p is an early 2011 model that probably should receive a firmware update > including the missing SB protocols... What firmware version is loaded?? Available? <<< The last one; F.60 Rev.A(31 Mar 2015)>>> For absolute hilarity, Google "8460p firmware EFI". Your forum post was on top for me. <<<Yes; I know... HP silence says it all; they know they're guilty ;-) http://h30434.www3.hp.com/t5/Notebook-Operating-Systems-and-Software/EFI-firmware-bug-on-HP-EliteBook-2560p-8460p/td-p/4931486>>> > I thought of it but I do not know if there's really much to get here;> i.e. in a 4 NIC PC the parsing only involves 4 UDPv4Sb (or TCPv4Sb) handles. > Anyway it can definitely be done if necessary. It's also a question of how fast the firmware bothers to be. Considering our rate, this in theory shouldn't matter. <<< agreed>>>Oh how fun. UEFI Specifications version 2.0 states "An EFI_PXE_BASE_CODE_PROTOCOL will be layered on top of an EFI_SIMPLE_NETWORK_PROTOCOL protocol in order to perform packet level transactions." while version 2.1 states "An EFI_PXE_BASE_CODE_PROTOCOL will be layered on top of an EFI_MANAGED_NETWORK_PROTOCOL protocol in order to perform packet level transactions.">>>Could this be the reason why in the past Pxebc and the SBs where attached to different handles?? mmhhh I have to admit; UEFI development is a bit messy... Best, Patrick