>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 binaries (w/o recompiling) from https://www.kernel.org/pub/linux/utils/boot/syslinux/syslinux-6.03.zip\efi32\efi\syslinux.efi config.version = "8" virtualHW.version = "9" ethernet0.virtualDev = "e1000e" guestOS = "windows8" firmware = "efi" option-93 = Client System Architecture: EFI IA32 (6) option-60 =Vendor class identifier: "PXEClient:Arch:00006:UNDI:003016" I've performed a deeper analysis and this is what's going on. The client get's its IP from VMware DHCP server, the ACK includes NextServer=192.168.62.254 (the DHCP Server IP) The client gets PXE parameters from a proxyDHCP NextServer=192.168.62.1 (the PXE Server IP) While the NBP syslinux.efi is correctly retrieved considering the PXE parameters given by the proxyDHCP (192.168.62.1) the TFTP request of the file ldlinux.e32 is performed with the data included in the DHCP answer (192.168.62.254) instead. That's why the PXE server never receives the ldlinux.e32 TFTP request. Also I see ldlinux.e32 is requested plain, w/o any path component. I think this is a bug in syslinux.efi retrieving its components w/o considering proxyDHCP scenarios. If using the same DHP+proxyDHCP scenario I boot MS bootmgfw.efi the MS boot manager correctly detects who is the real PXE server and conducts its further TFTP requests correctly.> No, I'm stating that binaries built with > gcc-4.6 will likely fail and > that gcc-4.7+ > is likely needed.? One example of a system is a build VM > I have with Debian-7 that I use to build some > of my test binaries.What OS is used by syslinux maintainers??? Best, Patrick
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 = "efi" > >> I see: > >> option-93 = 0x07 >> option-60 ="PXEClient:Arch:00007:UNDI:003016" > > OK I take binaries (w/o recompiling) from > https://www.kernel.org/pub/linux/utils/boot/syslinux/syslinux-6.03.zip\efi32\efi\syslinux.efi > > config.version = "8" > virtualHW.version = "9" > ethernet0.virtualDev = "e1000e" > guestOS = "windows8" > firmware = "efi" > > option-93 = Client System Architecture: EFI IA32 (6) > option-60 =Vendor class identifier: "PXEClient:Arch:00006:UNDI:003016"Good. These match.> I've performed a deeper analysis and this is what's going on. > > The client get's its IP from VMware DHCP server, the ACK includes NextServer=192.168.62.254 (the DHCP Server IP) > The client gets PXE parameters from a proxyDHCP NextServer=192.168.62.1 (the PXE Server IP) > > While the NBP syslinux.efi is correctly retrieved considering the PXE parameters given by the proxyDHCP (192.168.62.1) > the TFTP request of the file ldlinux.e32 is performed with the data included in the DHCP answer (192.168.62.254) instead. > That's why the PXE server never receives the ldlinux.e32 TFTP request. > Also I see ldlinux.e32 is requested plain, w/o any path component. > > I think this is a bug in syslinux.efi retrieving its components w/o considering proxyDHCP scenarios. > > If using the same DHP+proxyDHCP scenario I boot MS bootmgfw.efi the MS boot manager correctly detects > who is the real PXE server and conducts its further TFTP requests correctly.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. -- -Gene
Patrick Masotta through Geert as being moderator
2015-Jan-12 10:41 UTC
[syslinux] PXE Booting EFI
>>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 (syslinux.efi), it is the NBP the one that makes mistakes when deciding where the PXE server is located. syslinux.efi is taking the next-server IP from an answer from a DHCP server that did not identified itself as a PXE server (no option 60). It looks like a bug to me. I think I "kind" of fixed the bug; at syslinux-6.03/efi/pxe.c void net_parse_dhcp(void) { ... //patmod start if(&mode->ProxyOfferReceived) parse_dhcp(&mode->ProxyOffer.Dhcpv4, pkt_len); else //patmod end parse_dhcp(&mode->PxeReply.Dhcpv4, pkt_len); Print(L"\n"); ... } just add the code surrounded by comments the idea is to ask if there was a proxyOffer first then parse the corresponding packet. a more robust fix probably should include more checking. I compiled the patch (using Ubuntu 14.04) and now it works ! Best, Patrick
DMARC damage control
2015-Jan-12 17:44 UTC
[syslinux] [syslinux-bounces@zytor.com: Forward of moderated message]
DMARC damage control
----- Forwarded message from syslinux-bounces at zytor.com -----
Date: Mon, 12 Jan 2015 09:18:22 -0800
From: syslinux-bounces at zytor.com
To: syslinux-owner at zytor.com
Subject: Forward of moderated message
Date: Mon, 12 Jan 2015 02:41:55 -0800
From: Patrick Masotta <masottaus at yahoo.com>
To: Gene Cumm <gene.cumm at gmail.com>
Cc: Ady <ady-sf at hotmail.com>, For discussion of Syslinux and tftp-hpa
<syslinux at zytor.com>
Subject: Re: [syslinux] PXE Booting EFI
X-Mailer: YahooMailClassic/905 YahooMailWebService/0.8.203.740
>
>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 (syslinux.efi), it is the NBP the one that makes mistakes when deciding
where the PXE
server is located. syslinux.efi is taking the next-server IP from an answer from
a DHCP server that
did not identified itself as a PXE server (no option 60). It looks like a bug to
me.
I think I "kind" of fixed the bug;
at syslinux-6.03/efi/pxe.c
void net_parse_dhcp(void)
{
...
//patmod start
if(&mode->ProxyOfferReceived)
parse_dhcp(&mode->ProxyOffer.Dhcpv4, pkt_len);
else
//patmod end
parse_dhcp(&mode->PxeReply.Dhcpv4, pkt_len);
Print(L"\n");
...
}
just add the code surrounded by comments
the idea is to ask if there was a proxyOffer first then parse the corresponding
packet.
a more robust fix probably should include more checking.
I compiled the patch (using Ubuntu 14.04) and now it works !
Best,
Patrick
----- End forwarded message -----
--
Groeten
Geert Stappers
--
Leven en laten leven