similar to: Makefile race condition with parallel make

Signed-off-by: Julien Viard de Galbert <jviarddegalbert at online.net> --- efi/udp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/efi/udp.c b/efi/udp.c index 1088f47..b0f13ad 100644 --- a/efi/udp.c +++ b/efi/udp.c @@ -163,7 +163,7 @@ void core_udp_connect(struct pxe_pvt_inode *socket, uint32_t ip, } else { udata.UseDefaultAddress = FALSE;

The variable 'ok' is never used and generates a warning. Remove it. Also ntfssect.c is designed to be compiled in non Unicode mode when using MSVC compilers, so remove all ambiguity about it (LPCTSTR -> LPCSTR, use of 'A' API calls) so that it doesn't break when compiled in Unicode mode, which is what Rufus uses with MSVC. -------------- next part --------------

On Sun, Feb 28, 2016 at 04:26:07PM +0000, Patrick Masotta via Syslinux wrote: > > > I have re-implemented /efi/udp.c > Signed-off-by: Patrick Masotta <masottaus at yahoo.com> > > diff -uprN a/core/fs/pxe/pxe.h b/core/fs/pxe/pxe.h > --- a/core/fs/pxe/pxe.h 2014-10-06 10:27:44.000000000 -0600 > +++ b/core/fs/pxe/pxe.h 2016-02-28 08:44:47.127996962 -0700 > @@

I did change both instances of txdata->GatewayAddress, but I think something may be wrong in my toolchain. If I extract syslinux.zip and attempt to make from there (without modifying any files), the cached DHCP packet isn't read on the same subnet. I receive "Succeed to download NBP file." twice before anything from syslinux is loaded, so I believe the duplicate request for

The attached patch resolves a buffer reuse bug in the efi/tcp.c code. The bug can be triggered when multiple TCP connections are opened when using the EFI bootloader. Signed-off-by: Joshua Weage <joshua.weage at dell.com> --- --- master/core/fs/pxe/pxe.h 2017-07-22 14:45:46.561674329 -0500 +++ jw/core/fs/pxe/pxe.h 2017-07-23 19:44:46.466498950 -0500 @@ -144,6 +144,7 @@ struct

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

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 Thu, Nov 28, 2013 at 9:47 PM, Gene Cumm <gene.cumm at gmail.com> wrote: > On Thu, Nov 28, 2013 at 9:34 PM, Celelibi <celelibi at gmail.com> wrote: >> 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.

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

On Thu, Nov 28, 2013 at 10:24 PM, Celelibi <celelibi at gmail.com> wrote: > 2013/11/29, Gene Cumm <gene.cumm at gmail.com>: >> On Thu, Nov 28, 2013 at 9:47 PM, Gene Cumm <gene.cumm at gmail.com> wrote: >>> On Thu, Nov 28, 2013 at 9:34 PM, Celelibi <celelibi at gmail.com> wrote: >>>> Without an assigned source port, Transmit function assign a

Signed-off-by: Julien Viard de Galbert <jviarddegalbert at online.net> --- efi/udp.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/efi/udp.c b/efi/udp.c index b0f13ad..8f4d7dc 100644 --- a/efi/udp.c +++ b/efi/udp.c @@ -52,7 +52,7 @@ EFI_STATUS core_udp_configure(EFI_UDP4 *udp, EFI_UDP4_CONFIG_DATA *udata, } } else { if (status !=

I have just got a Cisco 7941G and am experiencing the exact same problem (phone is requesting .tlv file from TFTP server and never asks for .cnf.xml file). The phone originally had SCCP on it, but I downloaded and flashed with the latest Cisco SIP image (8.4(3) released 2009-01-13). In reading your message below, it looks like you were going to try an incremental upgrade?did you have any

Here is a completely untested patch if someone wants to try and take it for a spin? -hpa -------------- next part -------------- diff --git a/efi/udp.c b/efi/udp.c index 59bb426..60a8fe9 100644 --- a/efi/udp.c +++ b/efi/udp.c @@ -41,8 +41,7 @@ int core_udp_open(struct pxe_pvt_inode *socket) udp = (EFI_UDP4 *)udp_reader->this; memset(&udata, 0, sizeof(udata)); -

This extra socket cause the EFI udp stack to duplicate every packet to be able to provide them to both udp_reader and socket->net.efi.binding. The ones in socket->net.efi.binding were never read so they accumulated in the stack on EFI side making the stack slower and slower. Slow enough to not be able to download a kernel+initramfs before the EFI timeout (5 minutes). Signed-off-by: Julien

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

From: Sylvain Gault <sylvain.gault at gmail.com> Despite having native network capabilities, UEFI 2.4 (the most widely deployed at the moment) has no native DNS resolver. I propose here an implementation more or less inspired by the one found in core/legacynet/dnsresolv.c. Since it's non-trivial, I'd like to ask for a deep review of this code. I tried to make it as strong as

Hello guys, Today we faced an unique problem. We have about 120 stations and we are reaching 40k simultaneous listeners monday/friday (~ 11 AM GMT -3). We also use url auth to log, audit and build audience reports. But today, at the end of the day we were about 10k simultaneous and listeners start get errors (403, busy, please try again later), and after digging, delete logs and restart

Sebastian, On 01/15/2015 12:49 AM, Sebastian Herbszt wrote: > which version of pxelinux were you trying? Looks like < 5.x. the one from Fedora 20, syslinux-4.05. It turns out that pxelinux.0 from Fedora 21, syslinux-6.03, reports "Failed to load ldlinux.c32" when ldlinux.c32 can't be read, and "Loading <FILE>... failed: No such file or directory" when the

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, Nov 28, 2013 at 9:34 PM, Celelibi <celelibi at gmail.com> wrote: > 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