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
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. > > > 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.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.> I compiled the patch (using Ubuntu 14.04) and now it works !Excellent. -- -Gene
> 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 (wrong) Fore some reason I think there might be also a bug on EFI firmware code: If the DHCP server provides an answer with "next server" populated but no file field populated nor the corresponding option either that's not a PxeReply then that structure should be empty... Reading the standard does not say much about how/when these structures really get populated. Best, Patrick