search for: efi_pxe_base_code_protocol

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

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

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

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

On Fri, Jul 10, 2015 at 5:00 AM, Patrick Masotta <masottaus at yahoo.com> wrote: >>>> > 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...

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

...On Sun, Jul 12, 2015 at 3:35 AM, Gene Cumm via Syslinux <syslinux at zytor.com> wrote: > On Fri, Jul 10, 2015 at 5:00 AM, Patrick Masotta <masottaus at yahoo.com> > wrote: > > >>>> > > 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...

...ke we both had part of the right idea. You even addressed machines that implement dual stack (IPv4+IPv6) versus single stack in efi_create_binding(), presuming it's symmetric. Recently I posted a patch to efi/pxe.c that's similar but uses more data to determine the potential validity of a EFI_PXE_BASE_CODE_PROTOCOL handle. Regarding UseDefaultAddress (as mentioned recently), some implementations don't route automatically unless it's used. -- -Gene

Signed-off-by: Beno?t Allard <benoit.allard at greenbone.net> --- efi/fio.h | 9 --------- 1 file changed, 9 deletions(-) diff --git a/efi/fio.h b/efi/fio.h index 65fff8d..a1bfe68 100644 --- a/efi/fio.h +++ b/efi/fio.h @@ -11,15 +11,6 @@ #define MAX_EFI_ARGS 64 #define WS(c16) (c16 == L' ' || c16 == CHAR_TAB) -/* VPrint is not in export declarations in gnu-efi lib yet

...e should really understand what bootmgfw.efi does and avoid (when possible) other experiments in the EFI arena. In the past few days I have been comparing bootmgfw.efi and syslinux.efi TFTP strategies and these are differences I've found so far: 1) bootmgfw.efi uses the UDP capabilities of EFI_PXE_BASE_CODE_PROTOCOL (PXEbc is layered on top of an EFI_MANAGED_NETWORK_PROTOCOL protocol in order to perform packet level transactions) _UdpFunctionTable _UdpOpen() _UdpClose() _UdpRead() _UdpWrite() _UdpGetInformation() _UdpSetInformation() on the other hand syslinux.efi uses EFI_UDP4_SERV...

...don't seem to be able to find a release-note or such. Fact is, syslinux has some difficulties building with that version. - The declaration of VPrint is now in the gnu-efi headers, and is incompatible with syslinux one (CONST missing in syslinux) - The EFI_PXE_BASE_CODE struct is now called EFI_PXE_BASE_CODE_PROTOCOL - The declaration of the various longjump types is incompatible with syslinux's. I've stopped when investigating that last one, so there might be more. Is there any interest in making syslinux compatible with the latest gnu-efi release ? Regards, Ben. -------------- next part --------...

> On 2/6/19 11:44 AM, Joakim Tjernlund wrote: > > On Wed, 2019-02-06 at 11:34 -0800, H. Peter Anvin wrote: > > > > Great, that tree now against a somewhat old gnu-efi though. > > > > To build against >= 3.0.8 I need to do: > > #gnu-efi >= 3.0.8 has memset/memcpy defined causing multiple syms errors > > sed -i 's/LDFLAGS =/LDFLAGS =

...m <gene.cumm at gmail.com> > AuthorDate: Thu, 25 Jun 2015 22:04:08 -0400 > Committer: Gene Cumm <gene.cumm at gmail.com> > CommitDate: Thu, 25 Jun 2015 22:04:08 -0400 > > efi/pxe: Reuse handle > > Store and reuse handle found with EFI_LOADED_IMAGE_PROTOCOL for > EFI_PXE_BASE_CODE_PROTOCOL and EFI_UDP4_SERVICE_BINDING_PROTOCOL > > This caused machines with multiple NICs to not reliably attach to the > correct NIC handle. > > gnu-efi LoadedImageProtocol PxeBaseCodeProtocol Udp4ServiceBindingProtocol > > Reported-By: Holger Baust <holger.baust at freenet.ag>...

On Wed, Sep 23, 2015 at 4:24 PM, Patrick Masotta <masottaus at yahoo.com> wrote: >>>> > > > BTW if you take a minute and read the first report > > https://communities.vmware.com/message/2536774 > > You'll realize that VMWare TFTP "surprisingly" does not present slow TFTP transfers > > when they are driven by MS