similar to: EFI: PXE: "My IP is 0.0.0.0"

On Mon, Jun 22, 2015 at 6:03 AM, S. Schauenburg <s.schauenburg at gmail.com> wrote: > Ady2 suggested to me on IRC to add additional information to the ML. > > With BIOS P89 v1.32 (03/05/2015) I saw errors from core_udp_sendto: > Getting cached packet > My IP is 0.0.0.0 > core_udp_sendto: stalling on configure with no mapping > core_udp_sendto: stalling on configure with

Hello Gene, thanks a lot for your patch! It doesn't work yet, but I have some more information. Before the patch, the boot sequence ended with the following: NBP file download successfully. Getting cached packet My IP is 0.0.0.0 After the patch it ended with the following (note that the IP is the same as the Station IP address): NBP file download successfully. LibLocateHandle returned

On Sat, Jun 20, 2015 at 5:09 PM, Gene Cumm <gene.cumm at gmail.com> wrote: > Starting a new thread for the moment and BCCing the two reporters of the issue. > > Looking over the code, I think I finally see why we get junk data from > the PXE base. If we tell the PXE base that a buffer is 0 bytes long, > we should expect junk/null data. > > I'm hoping to have a patch

Ady2 suggested to me on IRC to add additional information to the ML. With BIOS P89 v1.32 (03/05/2015) I saw errors from core_udp_sendto: Getting cached packet My IP is 0.0.0.0 core_udp_sendto: stalling on configure with no mapping core_udp_sendto: stalling on configure with no mapping core_udp_sendto: stalling on configure with no mapping core_udp_sendto: stalling on configure with no mapping

On Mon, Jun 22, 2015 at 2:54 AM, S. Schauenburg <s.schauenburg at gmail.com> wrote: > Hello Gene, > > thanks a lot for your patch! It doesn't work yet, but I have some more > information. > > Before the patch, the boot sequence ended with the following: > NBP file download successfully. > Getting cached packet > My IP is 0.0.0.0 > > After the patch it

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

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

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

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

On Wed, Nov 29, 2017 at 6:30 AM, Gene Cumm <gene.cumm at gmail.com> wrote: > On Tue, Nov 28, 2017 at 2:38 PM, Joakim Tjernlund > <Joakim.Tjernlund at infinera.com> wrote: >> On Mon, 2017-11-27 at 18:18 -0500, Gene Cumm wrote: > >>> On Mon, Nov 27, 2017 at 6:07 PM, Joakim Tjernlund >>> <Joakim.Tjernlund at infinera.com> wrote: >>> > On

On Wed, 2017-12-13 at 10:34 -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 Wed, Dec 13, 2017 at 7:03 AM, Joakim Tjernlund > <Joakim.Tjernlund at infinera.com> wrote: > > On Mon, 2017-12-11 at 08:59 +0100, Joakim

>>> 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 <<< Hi there I think in the case of a particular

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

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

Hey everyone, sorry for the delay in replying. First off, thanks for all the help, effort and support so far! == build == I built and used syslinux from https://github.com/ppatpat/syslinux (latest commit 43f5efa2db4a7880c7a2c6485d8fd8a64f0f33c3). On top of that I had to patch main.c. This had to be done to mitigate the following error when trying to 'make all': main.c:(.text+0x3b9):

>>> > 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 Fri, Jul 3, 2015 at 11:05 AM, Patrick Masotta <masottaus at yahoo.com> wrote: >>>> > 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

Hi there, I have experienced problems on HP Elitebook 2560p and 8460p latest firmware installed: 2560p 68SSU ver. F50. 08/04/2014 8460p 68SCF ver. F50. 08/04/2014 PXE boot, syslinux.efi gets perfectly TFTP transferred, it nevers asks for ldlinux.e64, and immediately gives up. I have traced the problem to: /syslinux-6.03/efi/udp.c\core_udp_open()

> 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