search for: bguid

...nding 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 works. Everything is done within efi_create_binding(EFI_GUID *bguid, EFI_GUID *pguid) from image_DeviceHandle I get the right DevPath handle, I parse it and I get the MAC address. Next I LibLocateHandle(ByProtocol, bguid, NULL, &nr_handles, &handles) what gives me all the handles that include the Service Binding Protocol "bguid". For each of this...

...> @@ -40,36 +40,27 @@ efi_close_protocol(EFI_HANDLE handle, EFI_GUID *guid, EFI_HANDLE agent, > guid, agent, controller); > } > > +/* As of UEFI-2.4.0, all EFI_SERVICE_BINDINGs are for networking */ > struct efi_binding *efi_create_binding(EFI_GUID *bguid, EFI_GUID *pguid) > { > EFI_SERVICE_BINDING *sbp; > struct efi_binding *b; > EFI_STATUS status; > - EFI_HANDLE protocol, child, *handles = NULL; > - UINTN i, nr_handles = 0; > + EFI_HANDLE protocol, child; > > b = malloc(sizeof(*b)); >...

On Fri, Aug 28, 2015 at 03:34:12AM -0700, Patrick Masotta via Syslinux wrote: Derrick wrote: > > More importantly: look at the actual captured text.? It does NOT > > specify a valid MAC in its entirety and leaves off the leading nibble > > (11 characters, not 12).? Handle 267 shows "065F36E00EE" not "0065F36E00EE". > > I saw that, they might even be

...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 works. > Everything is done within efi_create_binding(EFI_GUID *bguid, EFI_GUID *pguid) > from image_DeviceHandle I get the right DevPath handle, I parse it and I get the MAC address. > Next I LibLocateHandle(ByProtocol, bguid, NULL, &nr_handles, &handles) > what gives me all the handles that include the Service Binding Protocol "bguid". &g...

...reate a service binding.? If unsuccessful, hunt for a handle that provides the target service binding and matches the MAC address. Best case, it's 1 binding attempt.? Worst case it's about N+1. -- -Gene <<< I see; on fail you fall back getting all handles again by "bguid". This approach would have no benefit if there are consecutive alternative binding (UDP/TCP) but that's unlikely to happen. 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

From: Sylvain Gault <sylvain.gault at gmail.com> I don't know if I should merge those trivial warning fix into one commit. I can reformat it as requested. Those are a few warning fixes for the efi part. The code involved has mainly been introduced in recent commits. Sylvain Gault (3): efi: fix warnings about argument types efi: fix pointer-type mismatch assigment warning efi: fix

...0; i < nr_handles; i++) { DevicePath = DevicePathFromHandle(handles[i]); if (efi_get_MAC(DevicePath, &mac_2, PXE_MAC_LENGTH) && memcmp(mac_1, mac_2, PXE_MAC_LENGTH) == 0) { sb_handle = handles[i]; status = uefi_call_wrapper(BS->OpenProtocol, 6, sb_handle, bguid, (void **)&sbp, image_handle, sb_handle, EFI_OPEN_PROTOCOL_GET_PROTOCOL); if (status == EFI_SUCCESS) { mnpsb_handle = sb_handle; break; } } } } if (status != EFI_SUCCESS) goto free_binding; child = NULL; status = uefi_call_wrapper(sbp->...

...ne to mitigate the following error when trying to 'make all': main.c:(.text+0x3b9): undefined reference to `BSWAP_64' More specifically I made this change: diff ../syslinux_ppatpat_orig/efi/main.c efi/main.c 13a14 > #include <byteswap.h> 178c179 < BSWAP_64(*(uint64_t*)&bguid->Data4), --- > This build of syslinux works on my HP ProLiant DL380 Gen9 server while netbooting from nic1 (not nic0) :-) == output booting pxe == Don't know if it is useful, but I saw this output when booting from pxe over IPv4: ... NBP file downloaded successfully. Booting from: Ac...

...nevers asks for ldlinux.e64, and immediately gives up. I have traced the problem to: /syslinux-6.03/efi/udp.c\core_udp_open() /syslinux-6.03/efi/main.c\efi_create_binding(&Udp4ServiceBindingProtocol, &Udp4Protocol); /syslinux-6.03/gnu-efi/gnu-efi-3.0/lib/hand.c\LibLocateHandle(ByProtocol, bguid, NULL, &nr_handles, &handles); When LibLocateHandle() try to locate EFI_UDP4_SERVICE_BINDING_PROTOCOL it fails with EFI_NOT_FOUND (14) which looks like an HP firmware issue. Newer versions of the HP Elitebook family like 2570p and 8470p PXE boot syslinux.efi correctly. Unfortunately this...

...E parameters. It seems to work. It would be really interesting if the HP guys having this issue can give it a try... Please see the new code at https://github.com/ppatpat/syslinux/blob/master/efi/main.c Patched: efi_main(EFI_HANDLE image, EFI_SYSTEM_TABLE *table) {} efi_create_binding(EFI_GUID *bguid, EFI_GUID *pguid) {} Best, Patrick

...ould be really interesting if the HP guys having this issue can give it a try... > > > Please see the new code at > https://github.com/ppatpat/syslinux/blob/master/efi/main.c > > Patched: > efi_main(EFI_HANDLE image, EFI_SYSTEM_TABLE *table) {} > efi_create_binding(EFI_GUID *bguid, EFI_GUID *pguid) {} 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 ha...

...> hunt for a handle that provides the target service > binding and matches the MAC address. > > Best case, it's 1 binding attempt. Worst case it's about N+1. > > -- > -Gene > <<< > > I see; on fail you fall back getting all handles again by "bguid". > This approach would have no benefit if there are consecutive alternative > binding (UDP/TCP) but that's unlikely to happen. Only if consecutive alternate bindings AND the bindings live on different handles. I believe we have yet to see a machine that has these two bindings on d...

..._MAC(DevicePath, &mac_2, PXE_MAC_LENGTH) > && memcmp(mac_1, mac_2, PXE_MAC_LENGTH) == 0) { > sb_handle = handles[i]; > status = uefi_call_wrapper(BS->OpenProtocol, 6, sb_handle, > bguid, (void **)&sbp, > image_handle, sb_handle, > EFI_OPEN_PROTOCOL_GET_PROTOCOL); > if (status == EFI_SUCCESS) { > mnpsb_handle = sb_handle; > break...

> Hi All, > > My PXE configurations works fine for a bios PXE (the server in legacy > mode) but hangs in an EUFI mode. Look like it can transfer the bootx64.efi > but not the next one ldlinux.e64 > > > Any ideas? > > Thanks > Latest updates (including firmware) for the HP ML350 Gen9 were released on 2014DEC19 (v1.21); I would suggest double-checking

>>> Jeff, Patrick: Could you try my code from my github repo branch efi-multinic?? It's derived from Patrick's code 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

...nd immediately gives up. > > I have traced the problem to: > > /syslinux-6.03/efi/udp.c\core_udp_open() > /syslinux-6.03/efi/main.c\efi_create_binding(&Udp4ServiceBindingProtocol, &Udp4Protocol); > /syslinux-6.03/gnu-efi/gnu-efi-3.0/lib/hand.c\LibLocateHandle(ByProtocol, bguid, NULL, &nr_handles, &handles); > > When LibLocateHandle() try to locate EFI_UDP4_SERVICE_BINDING_PROTOCOL it fails with > EFI_NOT_FOUND (14) which looks like an HP firmware issue. > Newer versions of the HP Elitebook family like 2570p and 8470p PXE boot syslinux.efi correctly....

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

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

Hi All, My PXE configurations works fine for a bios PXE (the server in legacy mode) but hangs in an EUFI mode. Look like it can transfer the bootx64.efi but not the next one ldlinux.e64 Any ideas? Thanks Software> syslinux ver 6.3 atftp 7.1 Log server side >> Booting Embedded LOM 1 Port 1 : HP Ethernet 1Gb 4-port 331i Adapter - NIC (PXE IPv4) >> Booting PXE over