similar to: [PATCH] efi/pxe.c: Allow ipv4 host names

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

On Sat, Jul 13, 2013 at 5:30 PM, Gene Cumm <gene.cumm at gmail.com> wrote: > On Sat, Jul 13, 2013 at 10:34 AM, Gene Cumm <gene.cumm at gmail.com> wrote: >> Digging more, loadfile("192.0.2.1::pxe.0", &file.data, &file.size), >> queries DNS, which sounds like it doesn't follow the same call path as >> a COM32 calling pxe_dns(). If the DNS

Digging more, loadfile("192.0.2.1::pxe.0", &file.data, &file.size), queries DNS, which sounds like it doesn't follow the same call path as a COM32 calling pxe_dns(). If the DNS won't resolve the IP, things won't load properly. pxechn.c32 sets sname in the intended packet to "192.0.2.1" which may be confusing something. More debugging needed. -- -Gene

2016-01-07 11:25 UTC+01:00, Stephen Bleazard via Syslinux <syslinux at zytor.com>: > Currently it appears that when PXE booting the domain search option is > ignored > and only the domain name option used for name resolution. > > The following patch adds support for domain search path usage when PXE > booting: > - adds parsing of the DHCP domain search option (119)

Hi - new to the list, can't find much on this using google. I'm trying to setup the dovecot DRAC plugin as described here: http://wiki.dovecot.org/HowTo/PopBSMTPAndDovecot#DRAC DRAC is installed and running using this startup command: /usr/local/sbin/rpc.dracd -i -e 5 /etc/postfix/dracd.db I downloaded the drac.c file linked on the above URL: http://www.dovecot.org/patches/1.1/drac.c

I have a small program that I am broadcasting out on port 36 and attempting to receive information back. Using "tcpdump port 36" I can see 2 devices responding to me but I get no data. The response my program gets is: Size IP Address Subnet MAC Address ID 20 0.0.0.0 0.0.0.0 00-00-00-00-00-00 Does someone know what I might not be doing

Hi, Gene Cumm wrote: > > 3) It feels like this is a moving target where gcc keeps changing and > > different results get reported. Do we have indications that different versions of gcc5 cause different behavior on the same build and boot machines ? Ady wrote: > Since the issue is only present on specific > hardware / firmware, whatever might seem to "solve" the

Domain naming parsing wise, I couldn't find any code or any cases where the domain search option (119) is processed. Pointer loop handling: I agree that 32 is pretty arbitrary, the issue I was trying to prevent is a pointer at the end of a label pointing at the same label. This would still be backwards but infinite. However, this does suggest a solution: The pointer must be before the

Hi Peter, The main part of this pull request includes commits that try to replace as many __intcall() invocations as possible. Some remain, but not many (and eventually they'll be gone too). There's also a patch to make better use of ld's --as-needed option and various other bug fixes/cleanups. The following changes since commit ff7334a2ce536b7f4b1f6d6f93ff4e285a3bd45a: Only

Currently it appears that when PXE booting the domain search option is ignored and only the domain name option used for name resolution. The following patch adds support for domain search path usage when PXE booting: - adds parsing of the DHCP domain search option (119) - When resolving names via dns_resolv uses the search path if there's no dot in the name. - Reverts to the

On Jul 13, 2013 9:00 AM, "Victor Sudakov" <vas at mpeks.tomsk.su> wrote: > > Gene Cumm wrote: > > >> pxelinux.0 since Syslinux-5.10 won't return the IP of a string like > > >> "192.0.2.1" (which is the source of the issue). > > > > > > Which means the correct syntax for the pxechn.c32 command line > > > should

On Sat, Jul 13, 2013 at 9:18 AM, Gene Cumm <gene.cumm at gmail.com> wrote: > On Jul 13, 2013 9:00 AM, "Victor Sudakov" <vas at mpeks.tomsk.su> wrote: >> >> Gene Cumm wrote: >> > >> pxelinux.0 since Syslinux-5.10 won't return the IP of a string like >> > >> "192.0.2.1" (which is the source of the issue). >> >

Hi Peter, Please pull the following changes. Paulo, I had to revert your "pxe: resolve names via DNS from protected-mode code" change because dns_resolv() is only implemented for PXELINUX and causes undefined symbol references for ISOLINUX, etc. Feel free to make the change again on top of the revert. The following changes since commit e7bd19def830e8341b1a100956345f1028740b9e:

Hi, trying to build syslinux on Linux. Please help. bash-2.05b$ uname -a Linux bongo 2.4.32-ARXc3 COHERENT #4-ARX (Build 2660) Sun May 21 15:35:22 CEST 2006 i686 i686 i386 GNU/Linux bash-2.05b$ BUILD/syslinux-3.11/opt/nasm-0.98.38-2/bin/nasm -version NASM version 0.98.38 compiled on Jun 26 2006 But failed with: + make NASM=/home/axel/p/rpm/BUILD/syslinux-3.11/opt/nasm/bin /nasm

On Fri, Jul 12, 2013 at 2:14 PM, Victor Sudakov <vas at mpeks.tomsk.su> wrote: > Gene Cumm wrote: >> pxelinux.0 since Syslinux-5.10 won't return the IP of a string like >> "192.0.2.1" (which is the source of the issue). > > Which means the correct syntax for the pxechn.c32 command line > should be like what? > > The example in doc/pxechn.txt is

2015-09-28 12:50 UTC+02:00, Gene Cumm <gene.cumm at gmail.com>: > On Fri, Sep 25, 2015 at 6:40 PM, Celelibi via Syslinux > <syslinux at zytor.com> wrote: >> 2015-09-25 21:27 UTC+02:00, Geert Stappers via Syslinux >> <syslinux at zytor.com>: >>> On Tue, Sep 15, 2015 at 05:22:40AM -0400, Gene Cumm via Syslinux wrote: >>>> On Sep 10, 2015 1:32

On Fri, Sep 25, 2015 at 6:40 PM, Celelibi via Syslinux <syslinux at zytor.com> wrote: > 2015-09-25 21:27 UTC+02:00, Geert Stappers via Syslinux <syslinux at zytor.com>: >> On Tue, Sep 15, 2015 at 05:22:40AM -0400, Gene Cumm via Syslinux wrote: >>> On Sep 10, 2015 1:32 AM, "celelibi--- via Syslinux" <syslinux at zytor.com> >>> wrote:

I have discovered that the JUNOS DHCP server in Juniper J-series routers doesn't support setting the next-server IP address field (I have filed a bug report with Juniper and they are working on it). Instead, it puts the "boot server" in the sname field, which PXELINUX currently ignores. Here's a simple patch (vs. 3.36) that will take an IP string in the field. My assembly is

On Tue, Sep 15, 2015 at 05:22:40AM -0400, Gene Cumm via Syslinux wrote: > On Sep 10, 2015 1:32 AM, "celelibi--- via Syslinux" <syslinux at zytor.com> wrote: > > > > 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

On Mon, Sep 28, 2015 at 06:36:24PM +0200, Celelibi via Syslinux wrote: > 2015-09-28 12:50 UTC+02:00, Gene Cumm > > On Fri, Sep 25, 2015 at 6:40 PM, Celelibi via Syslinux > >> 2015-09-25 21:27 UTC+02:00, Geert Stappers via Syslinux > >>> On Tue, Sep 15, 2015 at 05:22:40AM -0400, Gene Cumm via Syslinux wrote: > >>>> On Sep 10, 2015 1:32 AM,