search for: mnpsb

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

...ex 990 A19 (EFI 2.0 Revision 4.632 American Megatrends): Shell> dh -p Net Handle dump by protocol 'Net' Dell OptiPlex 9010 A22 (EFI 2.31 Revision 4.653 American Megatrends): Shell> dh -p Net Handle dump by protocol 'Net' 326: DevPath (..9,0x0)/MAC(xxxxxxxxxxxx,0x0))Net MNPSb ARPSb DHCPv4Sb IPv4Sb IPv4Config UDPv4Sb MTFTPv4Sb HiiConfAccess 341: DevPath (..HCP,0.0.0.0,0.0.0.0,0.0.0.0))Load Net Pxebc 349: DevPath (..00:0000:0000:0000:0000:0000))Load Net Pxebc Dell OptiPlex 9020 A16 (EFI 2.31 Revision 4.653 American Megatrends): Shell> dh -p Net Handle dump b...

..., 2017 at 6:45 AM, Joakim Tjernlund via Syslinux <syslinux at zytor.com> wrote: > But I have tried older versions too. Seems my Lenovo EFI is too "modern" for syslinux > but I think Gene has an idea how to solve it. Too modern? Nope, again, broken. A PxeBc should be atop a MNPSb atop a Net. (EDK shell uses the short names for the GUIDs; EDK2 shell uses longer names). Yours has PxeBc atop a Net with MNPSb on another handle. This is not the first and doubtfully the last we'll encounter. UEFI-2.0 allows this but starting in UEFI-2.1, it MUST live atop an MNPSb. I'...

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

...; > > > But I have tried older versions too. Seems my Lenovo EFI is too "modern" for syslinux > > > > > > but I think Gene has an idea how to solve it. > > > > > > > > > > Too modern? Nope, again, broken. A PxeBc should be atop a MNPSb atop > > > > > a Net. (EDK shell uses the short names for the GUIDs; EDK2 shell uses > > > > > longer names). Yours has PxeBc atop a Net with MNPSb on another > > > > > handle. This is not the first and doubtfully the last we'll > > > &gt...

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

>>> I'm just debating what's the 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). -- -Gene <<< What I've found: (from older to newer hardware) 1) There's not "any" SB prot...

...; > > >> > > > But I have tried older versions too. Seems my Lenovo EFI is too "modern" for syslinux >> > > > but I think Gene has an idea how to solve it. >> > > >> > > Too modern? Nope, again, broken. A PxeBc should be atop a MNPSb atop >> > > a Net. (EDK shell uses the short names for the GUIDs; EDK2 shell uses >> > > longer names). Yours has PxeBc atop a Net with MNPSb on another >> > > handle. This is not the first and doubtfully the last we'll >> > > encounter. UEFI-...

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

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

...t data from fs0 (the >> first mounted FAT* file system). >> >> >> guid > fs0:\efi-guid.txt >> dh > fs0:\efi-dh.txt >> dh -p Net > fs0:\efi-dh-net.txt >> >> >> In particular, I'm looking for where the Pxebc lives relative to >> MNPSb/UDPv4Sb (Net is a common Simple Network Protocol alias). >> >> -- >> -Gene

...s): > > Shell> dh -p Net > Handle dump by protocol 'Net' > > > > Dell OptiPlex 9010 A22 (EFI 2.31 Revision 4.653 American Megatrends): > > Shell> dh -p Net > Handle dump by protocol 'Net' > > 326: DevPath (..9,0x0)/MAC(xxxxxxxxxxxx,0x0))Net MNPSb ARPSb DHCPv4Sb > IPv4Sb IPv4Config UDPv4Sb MTFTPv4Sb HiiConfAccess > > 341: DevPath (..HCP,0.0.0.0,0.0.0.0,0.0.0.0))Load Net Pxebc > > 349: DevPath (..00:0000:0000:0000:0000:0000))Load Net Pxebc > > > > Dell OptiPlex 9020 A16 (EFI 2.31 Revision 4.653 American Megatrends...

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

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

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

On Mon, 2017-11-27 at 18:18 -0500, Gene Cumm wrote: > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. > > > On Mon, Nov 27, 2017 at 6:07 PM, Joakim Tjernlund > <Joakim.Tjernlund at infinera.com> wrote: > > On Mon, 2017-11-27 at 18:03 -0500, Gene Cumm

...mware 10 client with double NIC. > I'll test a bit more and I'll upload the code. I'm just debating what's the 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 (...

...#39;s DeviceHandle, > while Pxebc is loaded under the LoadeImage's DeviceHandle. (Elitebook 8470p/2570p) a) Hunt for a Sb. b) use Net > 3) SB protocols and Pxebc are loaded under the LoadeImage's DeviceHandle (VMware Workstation 10). a) use Sb on Pxebc handle b) use Net > 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. > I kept testing...

...rent handles?? mmhhh > I have to admit; UEFI development is a bit messy... I'd suspect possibly. I also have yet to see evidence your HP EliteBook 2560p is not UEFI-2.0 compliant. It's safe to assume the 2560p and 2570p are not 2.1 compliant as the Pxebc appears backed by a Net not an MNPSb. -- -Gene

>>> > > Why promiscuous?? That seems to want to accept it on any local address > and put the NIC into promiscuous mode, avoiding the default MAC filter > in the NIC.? This should be uncessary as we're not capturinig. If I remember correctly, this was required for TFTP boot because otherwise it's impossible to accept DHCP packets when we have no IP address