similar to: [PATCH 0/1] Network UEFI PXE DHCP/proxyDHCP fix

from: Jeff Sloan <jeff_sloan at selinc.com> Update UEFI PXE proxyDHCP handling. This patch is based on commit ID 8a00e49 Modify two files to specify valid ip addresses. These files are efi/pxe.c and efi/udp.c. In efi/pxe.c: In net_parse_dhcp function. If ProxyOffer has been received, start with DhcpAck packet since it is the most complete. This requires a minimum of changes to the

On Fri, Jun 26, 2015 at 10:15 AM, <jeff_sloan at selinc.com> wrote: > Will do, Gene. I'll let you (and the mailing list) know. Jeff, what's your status? -- -Gene > From: Gene Cumm <gene.cumm at gmail.com> > To: jeff_sloan at selinc.com, > Cc: For discussion of Syslinux and tftp-hpa <syslinux at zytor.com>, > masotta <masottaus

On Thu, Jun 11, 2015 at 4:02 PM, <jeff_sloan at selinc.com> wrote: > from: Jeff Sloan <jeff_sloan at selinc.com> > > Update UEFI PXE proxyDHCP handling. > > This patch is based on commit ID 8a00e49 > > Modify two files to specify valid ip addresses. These files are efi/pxe.c > and efi/udp.c. 1) In commit 2e266c35, I proposed using UseDefaultAddress. As I

The UEFI PXE boot DHCP/proxyDHCP issue is very timely. I am working on that very topic now. Our scenario is a manufacturing environment set up to format and load/install custom hard drive images in our systems. Our environment: This is a manufacturing floor setup where we build computers for our customers. We have two servers and a client in the mix, all connected via Ethernet (IPv4 only).

On Fri, Jun 26, 2015 at 8:58 AM, <jeff_sloan at selinc.com> wrote: > from: Jeff Sloan <jeff_sloan at selinc.com> > > Update UEFI PXE proxyDHCP handling updated. > > This patch is based on commit ID 8a00e49 This commit is outdated. Could you try commit ID 23b2707b as-is first? Thanks. > Updated pxe.c and udp.c to incorporate feedback.In addition to the previous

from: Jeff Sloan <jeff_sloan at selinc.com> Based on commit: 9314e330 Setting UseDefaultAddress to TRUE uses invalid StationAddress and SubnetMask values. This is in a network with a local TFTP/MTFTP server. If the server is local, on the same subnet, UseDefaultAddress is set to false and the client ip and subnetmask are loaded, otherwise set UseDefaultAddress to TRUE. This is added to

>>> And I stand corrected Patrick.? Apparently some clients are stuffing bad values into packets and moving the code to save the MAC resolves the deafness I observed. Commit 8a00e49 is the change. -- -Gene <<< OK; I was about to ask you a few wiershark captures... I looked at the last commit and I think if (mode->PxeReplyReceived) pkt_v4 =

On Sun, Jun 7, 2015 at 5:09 PM, Patrick Masotta <masottaus at yahoo.com> wrote: >>>> > Patrick, I think I've been able to figure out some missing details > about your VMware Workstation tests. For a proxyDHCP, > I'm using dnsmasq. Could you try to confirm your test was the > same basic setup? > > On VMware Workstation 10 with a VMHWv10 VM set to

Gene, I am very sorry. I did try the patch you suggested and had the same issue. Then, I grabbed the latest patch on Patrick's git repo. That's the commit that I listed. It was posted two days ago. I just noticed this on Patrick's repo: This branch is 6 commits ahead, 2 commits behind geneC:master Jeff Sloan Software Engineer - Computing Systems Schweitzer Engineering

> EFI has proven to be more robust.? The catch > here is order.? The > ProxyOffer data must > take precedence over the PxeReply data but both > of them probably need to be parsed. Not really; If you parse both "next server" from the last parsed packet (PxeReply) will overwrite the value gathered from the ProxyOffer and that leads to "Nest-server"= DHCP Server IP

On Mon, Jan 19, 2015 at 3:09 PM, Patrick Masotta <masottaus at yahoo.com> wrote: > >> EFI has proven to be more robust. The catch >> here is order. The >> ProxyOffer data must >> take precedence over the PxeReply data but both >> of them probably need to be parsed. > > Not really; If you parse both "next server" from the > last parsed

>First, I was looking for the actual values.? >For a VM with (among other values): > config.version = "8" > virtualHW.version = "10" > ethernet0.virtualDev = "e1000" > guestOS = "rhel6-64" > firmware = "efi" > I see: > option-93 = 0x07 > option-60 ="PXEClient:Arch:00007:UNDI:003016" OK I take

On Mon, Jun 8, 2015 at 4:07 PM, <jeff_sloan at selinc.com> wrote: > Gene, > Where do you keep the development tree? It's probably staring me in the face > but I can't find any updates beyond initial 6.03. Officially listed at http://www.syslinux.org/wiki/index.php/Development The primary repo at kernel.org is behind. The development repo at zytor.com is up to date but

On Sun, Jan 11, 2015 at 10:32 AM, Patrick Masotta <masottaus at yahoo.com> wrote: > >>First, I was looking for the actual values. >>For a VM with (among other values): > >> config.version = "8" >> virtualHW.version = "10" >> ethernet0.virtualDev = "e1000" >> guestOS = "rhel6-64" >> firmware =

On Wed, Jul 8, 2015 at 4:10 PM, <jeff_sloan at selinc.com> wrote: > Gene, > > I am very sorry. I did try the patch you suggested and had the same issue. > Then, I grabbed the latest patch on Patrick's git repo. That's the commit > that I listed. It was posted two days ago. > > I just noticed this on Patrick's repo: This branch is 6 commits ahead, 2 >

> >Excellent investigation and >details.? Thank you for this help.? Given >the details of your situation, I'm >reasonably certain it's a SYSLINUX >bug >but there is still a small chance of it being some sort >of negative interaction. > I do not think there's a negative interaction, while the VMware EFI environment correctly retrieves the NBP

On Tue, Jun 9, 2015 at 9:05 AM, Patrick Masotta <masottaus at yahoo.com> wrote: >>>> > And I stand corrected Patrick. Apparently some clients are > stuffing bad values into packets and moving the code to save the MAC resolves > the deafness I observed. > Commit 8a00e49 is the change. > -- > -Gene > <<< > > OK; I was about to ask you a

On Sat, Aug 15, 2015 at 9:50 AM, Gene Cumm <gene.cumm at gmail.com> wrote: > On Jul 27, 2015 12:30 PM, "Patrick Masotta" <masottaus at yahoo.com> wrote: >> >> >>> >> > I think these changes would solve the thing. >> > >> > ... >> > -EFI_SERVICE_BINDING *sbp; >> > +EFI_SERVICE_BINDING *sbp =NULL;

This patch adds to the core EFI image booting capabilities. It was tested on VMware EFI clients and HP Elitebook EFI notebooks, only on PXE environments but it should work on non-PXE scenarios as well. Feedback appreciated. Best, Patrick Signed-off-by: Patrick Masotta <masottaus at yahoo.com> --- diff -uprN a/com32/elflink/ldlinux/execute.c b/com32/elflink/ldlinux/execute.c ---

On Mon, Jan 12, 2015 at 5:41 AM, Patrick Masotta <masottaus at yahoo.com> wrote: > > > >Excellent investigation and > >details. Thank you for this help. Given > >the details of your situation, I'm > >reasonably certain it's a SYSLINUX > >bug > >but there is still a small chance of it being some sort > >of negative interaction.