similar to: [PATCH 0/1] EFI PXE DHCP/proxyDHCP issues 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 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

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

This patch adds to Com32 modules the capabilities of accessing the EFI environment The idea is simple, the EFI parameters "image" and "table" received by syslinux.efi's efi_main() are stored in the "firmware" structure, next they are retrieved from the Com32 module which is linked against the gnu-efi static library. The Com32 module can use the EFI

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

>>> The real DHCP server supplies client ip address only. Everything else comes from proxyDHCP. The proxyDHCP server supplies boot file name, boot file (syslinux.efi), boot loader (ldlinux.e64), config file, tinycore and OS image files. <<< This is not completely correct: your DHCP server provides an IP and your proxyDHCP server only processes a complementary DHCP

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

> 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

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

On Fri, Feb 20, 2015 at 05:08:26AM -0800, Patrick Masotta via Syslinux wrote: > 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

Hi guys, I have re-implemented /efi/udp.c The new code fixes: 1) The low and decreasing throughput on TFTP transfers. 2) The added delay between consecutive TFTP transfers. 3) The TFTP errors induced by broadcast traffic like ARP. Initial tests on a 50MB transfer showed times going from 3 minutes to ~12 seconds, also tested OK with nested TFTP transfers (include command). This

> >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 Sat, Oct 03, 2015 at 09:20:10AM +0300, Ady via Syslinux wrote: > > > I have a patch that I think may help your situation of syslinux.efi > > being unable to load ldlinux.e64/ldlinux.e32 (though I don't know if > > any of you are using an EFI ia32 platform). > > > > The basics are that we try to enable UseDefaultAddress as it helps > > certain clients

On Sat, Oct 3, 2015 at 3:28 AM, Geert Stappers via Syslinux <syslinux at zytor.com> wrote: > On Sat, Oct 03, 2015 at 09:20:10AM +0300, Ady via Syslinux wrote: >> >> > I have a patch that I think may help your situation of syslinux.efi >> > being unable to load ldlinux.e64/ldlinux.e32 (though I don't know if >> > any of you are using an EFI ia32

On Thu, May 9, 2013 at 6:39 AM, syslinux-bot for Matt Fleming <matt.fleming at intel.com> wrote: > Commit-ID: fe283b78c973268f2d1f0309826ceeb5c9e8978d > Gitweb: http://www.syslinux.org/commit/fe283b78c973268f2d1f0309826ceeb5c9e8978d > Author: Matt Fleming <matt.fleming at intel.com> > AuthorDate: Fri, 22 Mar 2013 14:54:09 +0000 > Committer: Matt Fleming

On Sat, 2015-07-18 at 07:43 -0400, Gene Cumm wrote: > On Thu, May 9, 2013 at 6:39 AM, syslinux-bot for Matt Fleming > <matt.fleming at intel.com> wrote: > > Commit-ID: fe283b78c973268f2d1f0309826ceeb5c9e8978d > > Gitweb: http://www.syslinux.org/commit/fe283b78c973268f2d1f0309826ceeb5c9e8978d > > Author: Matt Fleming <matt.fleming at intel.com> > >

Without an assigned source port, Transmit function assign a random new source port to the packet being sent. It thus have to be set before calling Transmit if the source port have already been decided. Conversly, we have to save the assigned port to reuse it later if needed. Resolve bug #35. Signed-off-by: Celelibi <celelibi at gmail.com> --- efi/udp.c | 18 ++++++++++++++++++ 1 file