search for: efi_managed_network_protocol

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

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

...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... I'd suspect possibly. I also have yet t...

>>> 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 command that made things "click" in my mind to understand the relationship. <<< This is somehow surprising but dumping handles at the shell I've verified that in m...

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

...le "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 command that made things "click" in my mind to understand the relationship. > I'm also trying to fix this bug but unfortunately I'm not having much time. I just need to...

...oid (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_SERVICE_BINDING_PROTOCOL/EFI_UDP4_PROTOCOL instead. About PXEbc...

...ion 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... > > I'...

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