search for: tcpv4sb

...10 (firmware A22), nor 9020 (firmware A16) seem have a built-in EFI shell option, but in all three cases I had success running the external EFI shell from github.com/tianocore/edk2/tree/master/EdkShellBinPkg (naming it /efi/boot/bootx64.efi on a FAT USB stick). > I'm guessing a lack of TCPv4Sb (an alias for the > EFI_TCP4_SERVICE_BINDING_PROTOCOL ). You're onto something. All three systems do report TCPv4Sb identically in their "guid" output, TCPv4Sb : 00720665-67EB-4A99-BAF7-D3C33A1C7CC9 yet in the "dh -p Net" output, only the OptiPlex 9020 lists TCPv4Sb....

...gt; I had success running the external EFI shell from > github.com/tianocore/edk2/tree/master/EdkShellBinPkg (naming it > /efi/boot/bootx64.efi on a FAT USB stick). Examining a 9020 I have access to, I'm guessing that depends on what's on the HDD. >> I'm guessing a lack of TCPv4Sb (an alias for the >> EFI_TCP4_SERVICE_BINDING_PROTOCOL ). > > > You're onto something. All three systems do report TCPv4Sb identically in > their "guid" output, > > TCPv4Sb : 00720665-67EB-4A99-BAF7-D3C33A1C7CC9 > > yet in the "dh -p Net" output...

> > Is syslinux.efi supposed to be able to handle HTTP URLs? > > If the underlying firmware can. Try just specifying an HTTP URL in the > config or on the command line instead of the path-prefix option. Doesn't work. Apparently the Dell UEFI PXE firmware doesn't know HTTP. Somehow I was under the impression improvements from pxelinux variants like lpxelinux were

...and I finally see good responses with a VMware VM's e1000e NIC (never saw ANYTHING good from it until now). git://github.com/geneC/syslinux.git https://github.com/geneC/syslinux.git -- -Gene <<<< I've seen your code. Your first patch considered Pxebc, UDPv4Sb and TCPv4Sb are created under the same handle but now we know this is not the case. Your new patch now considers UDPv4Sb and TCPv4Sb are created under the same handle thing that we really do not know if is always true or not. My patch looks slower than yours because it parses the handles on every attempt o...

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

On Wed, Jul 8, 2015 at 7:34 PM, Gene Cumm <gene.cumm at gmail.com> wrote: > What about the observed symptoms? Have you performed an inline packet Jeff, there's specific code that creates specific responses that if you had mentioned what you saw, I'd expect we could have seen something sooner. -- -Gene

...000e NIC > (never saw ANYTHING good from > it until > now). > > git://github.com/geneC/syslinux.git > https://github.com/geneC/syslinux.git > > -- > -Gene > <<<< > > I've seen your code. > Your first patch considered Pxebc, UDPv4Sb and TCPv4Sb are created under the same > handle but now we know this is not the case. > Your new patch now considers UDPv4Sb and TCPv4Sb are created under the same > handle thing that we really do not know if is always true or not. Not strictly. Look closer. > My patch looks slower than yours be...

...dle, 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 Hard...

...st algorithm here.? It would seem if the LoadeImage's DeviceHandle provides UDPv4Sb, use it as it's guaranteed to be the same interface.? Otherwise, we need a MNPSb (EFI_MANAGED_NETWORK_SERVICE_BINDING) that provides UDPv4Sb across the same interface.? Presumably it should also provide TCPv4Sb (rather than being on a separate handle). -- -Gene <<< What I've found: (from older to newer hardware) 1) There's not "any" SB protocol present (Elitebook 8460p/2560p) 2) SB protocols are loaded under a different that LoadeImage's DeviceHandle, while Pxebc is...

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

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

...nses with a VMware VM's e1000e NIC (never saw ANYTHING good from it until now). git://github.com/geneC/syslinux.git https://github.com/geneC/syslinux.git -- -Gene <<< Hi there I think in the case of a particular driver that implements Pxebc but it does not implement UDPv4Sb/TCPv4Sb (HP Elitebook 2560p/8460p) your patch crashes; In that case the following for(;;) structure will never have a MAC match, then the BS->OpenProtocol will never fail returning the needed "status != EFI_SUCCESS" to avoid de-referencing an undefined pointer (sbp->CreateChild) in the nex...

>>> Lovely, the ServiceBindings are on a handle that resembles the NIC while the Pxebc is IP-type specific.? Looks like we should try to do a ServiceBinding based on Pxebc but fall back to MAC-based searching, saving all 3 handles, the image handle, Pxebc handle, and ServiceBinding handle.? Presumably the UDP and TCP handles _should_ be the same... -- -Gene <<< OK now it

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

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

...he best algorithm here. It would seem if the LoadeImage's DeviceHandle provides UDPv4Sb, use it as it's guaranteed to be the same interface. Otherwise, we need a MNPSb (EFI_MANAGED_NETWORK_SERVICE_BINDING) that provides UDPv4Sb across the same interface. Presumably it should also provide TCPv4Sb (rather than being on a separate handle). Additional note for reference: The HP EliteBook 2570p appears to have been announced in May of 2012 and use Ivy Bridge-based (Intel Core-i series third generation) processors. Relatively speaking, this should be a reasonably recent machine. -- -Gene

...ANYTHING good from > it until now). > > git://github.com/geneC/syslinux.git > https://github.com/geneC/syslinux.git > > -- > -Gene > <<< > > Hi there > I think in the case of a particular driver that implements Pxebc but it does not implement UDPv4Sb/TCPv4Sb > (HP Elitebook 2560p/8460p) your patch crashes; > > In that case the following for(;;) structure will never have a MAC match, then the > BS->OpenProtocol will never fail returning the needed "status != EFI_SUCCESS" > to avoid de-referencing an undefined pointer (sbp-&gt...

...p://www.syslinux.org/archives/2015-August/024005.html and http://www.syslinux.org/archives/2015-August/024055.html version > fs0:\efi-ver.txt guid > fs0:\efi-guid.txt or alias > fs0:\efi-alias.txt dh > fs0:\efi-dh.txt dh -p Net > fs0:\efi-dh-net.txt I'm guessing a lack of TCPv4Sb (an alias for the EFI_TCP4_SERVICE_BINDING_PROTOCOL ). > Somehow I was under the impression improvements from pxelinux variants like > lpxelinux were already wrapped into the EFI version. > > Is there an "l" version of syslinux.efi? No. > Or any way to get HTTP transfers...