dnsmasq to support ProxyDHCP for UEFI ?


  • Moderator

    I’m on dnsmasq’s mailing list, got this in my inbox today:


    Re: ProxyDHCP mode is broken for serving ipxe.efi to UEFI pxe
    clents (Michael Kuron)

    Message: 1
    Date: Sat, 14 May 2016 19:47:06 +0200
    From: Michael Kuron michael-lists@physcip.uni-stuttgart.de
    To: dnsmasq-discuss@lists.thekelleys.org.uk
    Subject: Re: [Dnsmasq-discuss] ProxyDHCP mode is broken for serving
    ipxe.efi to UEFI pxe clents
    Message-ID:
    C5794A5E-3A85-4D49-A7D6-1084B7263A52@physcip.uni-stuttgart.de
    Content-Type: text/plain; charset=us-ascii

    I have included a patch below that makes essentially two modifications to get PXE working with the UEFI firmware in VMware.

    • It only appends the layer number to the file name on BIOS x86.
    • It always redirects the client to port 4011. To do that, only the siaddr is set and neither a boot file nor a PXE menu are included in the Offer sent upon receiving the Discover. In reaction to the ACK it then sends an ACK which includes either the single boot file name and server, or the PXE menu.

    This patch works to the same degree as my patch did. VMware boots fine with a single boot service, and the menu also works if you specify multiple, however you have to blindly navigate the menu because it is not shown on screen.

    Michael

    --- a/src/rfc2131.c
    +++ b/src/rfc2131.c
    @@ -63,7 +63,7 @@ static void pxe_misc(struct dhcp_packet *mess, unsigned char *end, unsigned char
     static int prune_vendor_opts(struct dhcp_netid *netid);
     static struct dhcp_opt *pxe_opts(int pxe_arch, struct dhcp_netid *netid, struct in_addr local, time_t now);
     struct dhcp_boot *find_boot(struct dhcp_netid *netid);
    -static int pxe_uefi_workaround(int pxe_arch, struct dhcp_netid *netid, struct dhcp_packet *mess, struct in_addr local, time_t now);
    +static int pxe_uefi_workaround(int pxe_arch, struct dhcp_netid *netid, struct dhcp_packet *mess, struct in_addr local, time_t now, int pxe);
    
     size_t dhcp_reply(struct dhcp_context *context, char *iface_name, int int_index,
                      size_t sz, time_t now, int unicast_dest, int *is_inform, int pxe, struct in_addr fallback)
    @@ -824,7 +824,10 @@ size_t dhcp_reply(struct dhcp_context *context, char *iface_name, int int_index,
              else
                mess->siaddr = context->local;
    
    -         snprintf((char *)mess->file, sizeof(mess->file), "%s.%d", service->basename, layer);
    +         if (pxearch == 0)
    +             snprintf((char *)mess->file, sizeof(mess->file), "%s.%d", service->basename, layer);
    +         else
    +             strncpy((char *)mess->file, service->basename, sizeof(mess->file));
              option_put(mess, end, OPTION_MESSAGE_TYPE, 1, DHCPACK);
              option_put(mess, end, OPTION_SERVER_IDENTIFIER, INADDRSZ, htonl(context->local.s_addr));
              pxe_misc(mess, end, uuid);
    @@ -879,11 +882,10 @@ size_t dhcp_reply(struct dhcp_context *context, char *iface_name, int int_index,
    
                      clear_packet(mess, end);
    
    -                 /* Only do workaround for replies to 4011 */
    -                 if (!pxe)
    -                   mess->siaddr = tmp->local;
    -                 else
    -                   workaround = pxe_uefi_workaround(pxearch, tagif_netid, mess, tmp->local, now);
    +                 /* Redirect the client to port 4011 */
    +                 mess->siaddr = tmp->local;
    +                 /* Returns true if only one matching service is available. On port 4011, it also inserts the boot file and server name. */
    +                 workaround = pxe_uefi_workaround(pxearch, tagif_netid, mess, tmp->local, now, pxe);
    
                      if (!workaround && boot)
                        {
    @@ -903,7 +905,7 @@ size_t dhcp_reply(struct dhcp_context *context, char *iface_name, int int_index,
                      option_put(mess, end, OPTION_SERVER_IDENTIFIER, INADDRSZ, htonl(tmp->local.s_addr));
                      pxe_misc(mess, end, uuid);
                      prune_vendor_opts(tagif_netid);
    -                 if (!workaround)
    +                 if (pxe && !workaround)
                        do_encap_opts(pxe_opts(pxearch, tagif_netid, tmp->local, now), OPTION_VENDOR_CLASS_OPT, DHOPT_VENDOR_MATCH, mess, end, 0);
    
                      log_packet("PXE", NULL, emac, emac_len, iface_name, ignore ? "proxy-ignored" : "proxy", NULL, mess->xid);
    @@ -1989,7 +1991,7 @@ static int prune_vendor_opts(struct dhcp_netid *netid)
        and jamb the data direct into the DHCP file, siaddr and sname fields.
        Note that in this case, we have to assume that layer zero would be requested
        by the client PXE stack. */
    -static int pxe_uefi_workaround(int pxe_arch, struct dhcp_netid *netid, struct dhcp_packet *mess, struct in_addr local, time_t now)
    +static int pxe_uefi_workaround(int pxe_arch, struct dhcp_netid *netid, struct dhcp_packet *mess, struct in_addr local, time_t now, int pxe)
     {
       struct pxe_service *service, *found;
    
    @@ -2009,6 +2011,9 @@ static int pxe_uefi_workaround(int pxe_arch, struct dhcp_netid *netid, struct dh
       if (!found)
         return 0; /* No relevant menu items. */
    
    +  if (!pxe)
    +     return 1;
    +
       if (found->sname)
         {
           mess->siaddr = a_record_from_hosts(found->sname, now);
    @@ -2024,7 +2029,10 @@ static int pxe_uefi_workaround(int pxe_arch, struct dhcp_netid *netid, struct dh
           inet_ntop(AF_INET, &mess->siaddr, (char *)mess->sname, INET_ADDRSTRLEN);
         }
    
    -  snprintf((char *)mess->file, sizeof(mess->file), "%s.0", found->basename);
    +  if (pxe_arch == 0)
    +      snprintf((char *)mess->file, sizeof(mess->file), "%s.0", service->basename);
    +  else
    +      strncpy((char *)mess->file, found->basename, sizeof(mess->file));
    
       return 1;
     }
    @@ -2563,7 +2571,7 @@ static void do_options(struct dhcp_context *context,
       if (context && pxe_arch != -1)
         {
           pxe_misc(mess, end, uuid);
    -      if (!pxe_uefi_workaround(pxe_arch, tagif, mess, context->local, now))
    +      if (!pxe_uefi_workaround(pxe_arch, tagif, mess, context->local, now, 0))
            config_opts = pxe_opts(pxe_arch, tagif, context->local, now);
         }
    

  • Moderator

    Message: 1
    Date: Wed, 18 May 2016 16:44:39 +0100
    From: Simon Kelley simon@thekelleys.org.uk
    To: dnsmasq-discuss Dnsmasq-discuss@lists.thekelleys.org.uk
    Subject: [Dnsmasq-discuss] Announce: dnsmasq-2.76
    Message-ID: 573C8DE7.3030603@thekelleys.org.uk
    Content-Type: text/plain; charset=utf-8

    I’ve just released dnsmasq 2.76.

    Download from http://thekelleys.org.uk/dnsmasq/dnsmasq-2.76.tar.gz

    It’s more than nine months since the last release, so get the new code
    quick, there’s lots to go at.

    Cheers,

    Simon.


  • Moderator


  • Developer

    So who is gonna build it from source and give it a try? :D


  • Moderator

    My message:


    Hello,

    I’m inquiring about the status of dnsmasq being able to operate in ProxyDHCP mode and serve option 066 and 067 boot file and file name to UEFI type systems.

    In the last digest, Vol 132, Issue 17 it was talked about but in regards to VMware. I’m wondering if there has been any progress with regular physical UEFI type machines?

    Thanks,
    Wayne


    Reply:


    It looks like this is solved problem for the forthcoming 2.76 release,
    for physical as well as virtual hosts.

    Cheers,

    Simon.


  • Developer

    Interesting stuff! Looking forward to see if dnsmasq will be able to PXE boot any kind of UEFI machines in the near future. Co-existence configuration with BIOS will still be a huge mess I reckon. :-)


  • Moderator

    I’ve sent an email requesting clarification. I’ll post the response when it’s released.


  • Moderator

    @Tom-Elliott I guess, I’m honestly not all that savvy with… you know… all that stuff above. Perhaps the issue was specific to VMware? I should ask again about regular UEFI ProxyDHCP. I did maybe a year ago and Simon said he would work on it… The thread about it is somewhere around here. I’ll ask again.


  • Senior Developer

    @Wayne-Workman I suppose that would mean for anything really right?


  • Moderator

    @Tom-Elliott It means that Simon Kelly and the Dnsmasq community are actively working on supporting UEFI based ProxyDHCP for dnsmasq in VMware.


  • Senior Developer

    What does this mean?


Log in to reply
 

421
Online

38953
Users

10704
Topics

101564
Posts

Looks like your connection to FOG Project was lost, please wait while we try to reconnect.