[syslinux] [PATCH 0/1] EFI PXE DHCP/proxyDHCP issues fix

Gene Cumm gene.cumm at gmail.com
Sun May 24 04:04:15 PDT 2015


On Mon, Mar 16, 2015 at 12:22 PM, Patrick Masotta via Syslinux
<syslinux at zytor.com> wrote:
> This patch fixes some problems when parsing DHCP/proxyDHCP
> answers on PXE scenarios.
> Before the patch proxyDHCP answers were ignored, and the
> IPinfo structure was populated based on a DhcpDiscover pkt
> instead of  DhcpAck
> The BootFile detection now  follows the EDKII function
> PxeBcImpl.c\DiscoverBootFile()
>
>  It was tested on VMware BIOS/EFI clients and HP Elitebook
>  EFI notebooks,
>
>  Feedback appreciated.
>
>  Best,
>  Patrick
>
>
>   Signed-off-by: Patrick Masotta <masottaus at yahoo.com>
>   ---
>
> diff -uprN a/efi/pxe.c b/efi/pxe.c
> --- a/efi/pxe.c 2014-10-06 10:27:44.000000000 -0600
> +++ b/efi/pxe.c 2015-03-14 06:22:20.840557180 -0600
> @@ -123,7 +123,7 @@ void net_parse_dhcp(void)
>       * Get the DHCP client identifiers (query info 1)
>       */
>      Print(L"Getting cached packet ");
> -    parse_dhcp(&mode->DhcpDiscover.Dhcpv4, pkt_len);
> +    parse_dhcp(&mode->DhcpAck.Dhcpv4, pkt_len);

When do you find client identifiers like the Vendor Class Identifier
(option 60)?  DHCP servers generally don't respond with this data.

Could the client identifiers provide any useful data?  Likely not but
not sure entirely why the original author did this.  I'd probably lean
towards keeping it as-is for now and perhaps separating this from the
main reason for the patch.

>      /*
>       * We don't use flags from the request packet, so
>       * this is a good time to initialize DHCPMagic...
> @@ -135,26 +135,28 @@ void net_parse_dhcp(void)
>       */
>      *(char *)&DHCPMagic = 1;
>
> -    /*
> -     * Get the BOOTP/DHCP packet that brought us file (and an IP
> -     * address). This lives in the DHCPACK packet (query info 2)
> -     */
> -    parse_dhcp(&mode->DhcpAck.Dhcpv4, pkt_len);

This makes sense since we've already parsed it.

> -    /*
> -     * Save away MAC address (assume this is in query info 2. If this
> -     * turns out to be problematic it might be better getting it from
> -     * the query info 1 packet
> +   /*
> +     * Get the boot file and other info.
> +     * Based on EDKII PxeBcImpl.c\DiscoverBootFile()
>       */
> -    hardlen = mode->DhcpAck.Dhcpv4.BootpHwAddrLen;
> -    MAC_len = hardlen > 16 ? 0 : hardlen;
> -    MAC_type = mode->DhcpAck.Dhcpv4.BootpHwType;
> -    memcpy(MAC, mode->DhcpAck.Dhcpv4.BootpHwAddr, MAC_len);
>
> -    /*
> -     * Get the boot file and other info. This lives in the CACHED_REPLY
> -     * packet (query info 3)
> -     */
> -    parse_dhcp(&mode->PxeReply.Dhcpv4, pkt_len);
> +    EFI_PXE_BASE_CODE_DHCPV4_PACKET*     pkt_v4;
> +
> +    if(mode->PxeReplyReceived)
> +       pkt_v4 = &mode->PxeReply.Dhcpv4;
> +    else
> +    if(mode->ProxyOfferReceived)
> +       pkt_v4 = &mode->ProxyOffer.Dhcpv4;
> +    else
> +       pkt_v4 = &mode->DhcpAck.Dhcpv4;
> +
> +    parse_dhcp(pkt_v4, pkt_len);
> +
> +    hardlen    = pkt_v4->BootpHwAddrLen;
> +    MAC_len    = hardlen > 16 ? 0 : hardlen;
> +    MAC_type   = pkt_v4->BootpHwType;
> +    memcpy(MAC, pkt_v4->BootpHwAddr, MAC_len);
> +
>      Print(L"\n");
>
>      /*

This is the real reason for the patch.  Seems good here.  Pick the one
with the highest priority.

-- 
-Gene


More information about the Syslinux mailing list