> 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
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 packet (PxeReply) will overwrite > the value gathered from the ProxyOffer and that leads > to "Nest-server"= DHCP Server IP (wrong)Order: at syslinux-6.03/efi/pxe.c void net_parse_dhcp(void) { ... parse_dhcp(&mode->PxeReply.Dhcpv4, pkt_len); //genemod start if(&mode->ProxyOfferReceived) parse_dhcp(&mode->ProxyOffer.Dhcpv4, pkt_len); //genemod end Print(L"\n"); ... } Though I'm trying to think of a DHCP option that wouldn't be in the earlier packets.> 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..Which sounds like a server operator error.> Reading the standard does not say much about how/when these structures > really get populated.If they're the on-wire frames, it's the server. If it's the packet buffer in RAM, it's the server. If it's how Syslinux variants use the packet buffer, that's up to the Syslinux variant to (hopefully) follow the standards to utilize them. -- -Gene
> Though I'm trying to think of a DHCP option > that wouldn't be in the > earlier > packets.If I'm not wrong in the case of a single PXE provider ("DHCP Server + PXE options" or "DHCP Server + proxyDHCP") PxeReply and ProxyOffer should be mutually exclusive; both structures should not be populated at the same time. I repeat in the case of a single PXE provider; If there are more than one then the case would fall under the typical PXE offer uncertainty.>> 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.. > > Which sounds like a > server operator error. >I think more of an error in the client EFI firmware mistakenly populating both structures PxeReply and ProxyOffer >> Reading the standard does not say much about how/when these >>structures >> really get >>populated. > >If they're the on-wire frames, it's the server.? If >it's the packet >buffer in RAM, it's >the server.? If it's how Syslinux variants use the >packet buffer, that's up to the Syslinux >variant to (hopefully) follow >the standards >to utilize them. > The problem here are who populates PxeReply and ProxyOffer I think this is done by the client's EFI firmware; Syslinux reads those structures by the GNU-EFI interface, that's why I'd like to know more about how and when those structures are populated but the standard doesn't say much... Best, Patrick -- -Gene