Re: [Dnsmasq-discuss] ProxyDHCP mode is broken for serving ipxe.efi to UEFI pxe clents

[Simon Kelley]

On 15/05/16 14:39, Dreamcat4 wrote:
> Hi,
> Tried the 2.76rc2 this morning. Seems fine / OK for me.
> 

Great. Thanks for that.



Cheers,

Simon.

> Have uploaded the binary here again (same place as before):
> 
> https://dl.bintray.com/dreamcat4/linux/dnsmasq/
> 
> 
> 
> On Sun, May 15, 2016 at 9:03 AM, Michael Kuron <
> michael-li...@physcip.uni-stuttgart.de> wrote:
> 
>> Hi Simon,
>>
>> thanks, it’s working fine for me now. Before releasing 2.76, it would be
>> good if more people could test this on actual hardware.
>> Also, there’s one more item that needs to go into the release notes: we
>> now redirect all clients to port 4011, including the BIOS clients. This is
>> a change in behavior over the previous release, where the option 43 menu
>> was sent on port 68. This could potentially break things for some very old
>> and broken PXE implementations. It’s unlikely, since the port 4011 stuff
>> has always been part of the PXE spec, but possible. I don’t think it’s
>> really necessary, but I have included a patch below that restricts the port
>> 4011 redirect to CSA >= 6. With that patch, the PXE behavior for BIOS
>> clients is exactly what it was in older releases.
>>
>> Michael
>>
>>
>> --- a/src/rfc2131.c
>> +++ b/src/rfc2131.c
>> @@ -882,8 +882,13 @@ size_t dhcp_reply(struct dhcp_context *context, char
>> *iface_name, int int_index,
>>
>>   clear_packet(mess, end);
>>
>> - /* Redirect the client to port 4011 */
>> - mess->siaddr = tmp->local;
>> + /* Redirect EFI clients to port 4011 */
>> + int redirect4011 = 0;
>> + if (pxearch >= 6)
>> + {
>> + redirect4011 = 1;
>> + 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);
>> @@ -906,7 +911,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 (pxe && !workaround)
>> + if ((pxe && !workaround) || !redirect4011)
>> 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);
>>
>>
>> ___
>> Dnsmasq-discuss mailing list
>> Dnsmasq-discuss@lists.thekelleys.org.uk
>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>>
> 
> 
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] ProxyDHCP mode is broken for serving ipxe.efi to UEFI pxe clents

[Simon Kelley]

On 15/05/16 09:03, Michael Kuron wrote:
> Hi Simon,
> 
> thanks, it’s working fine for me now. Before releasing 2.76, it would
> be good if more people could test this on actual hardware. Also,
> there’s one more item that needs to go into the release notes: we now
> redirect all clients to port 4011, including the BIOS clients. This
> is a change in behavior over the previous release, where the option
> 43 menu was sent on port 68. This could potentially break things for
> some very old and broken PXE implementations. It’s unlikely, since
> the port 4011 stuff has always been part of the PXE spec, but
> possible. I don’t think it’s really necessary, but I have included a
> patch below that restricts the port 4011 redirect to CSA >= 6. With
> that patch, the PXE behavior for BIOS clients is exactly what it was
> in older releases.
> 
> Michael
> 

Patch applied. That makes me happy. I've also added a description of the
changes to CHANGELOG. Does that make sense, or have I horribly mangled this?

Cheers

Simon.


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] ProxyDHCP mode is broken for serving ipxe.efi to UEFI pxe clents

[Dreamcat4]

Hi,
Tried the 2.76rc2 this morning. Seems fine / OK for me.

Have uploaded the binary here again (same place as before):

https://dl.bintray.com/dreamcat4/linux/dnsmasq/



On Sun, May 15, 2016 at 9:03 AM, Michael Kuron <
michael-li...@physcip.uni-stuttgart.de> wrote:

> Hi Simon,
>
> thanks, it’s working fine for me now. Before releasing 2.76, it would be
> good if more people could test this on actual hardware.
> Also, there’s one more item that needs to go into the release notes: we
> now redirect all clients to port 4011, including the BIOS clients. This is
> a change in behavior over the previous release, where the option 43 menu
> was sent on port 68. This could potentially break things for some very old
> and broken PXE implementations. It’s unlikely, since the port 4011 stuff
> has always been part of the PXE spec, but possible. I don’t think it’s
> really necessary, but I have included a patch below that restricts the port
> 4011 redirect to CSA >= 6. With that patch, the PXE behavior for BIOS
> clients is exactly what it was in older releases.
>
> Michael
>
>
> --- a/src/rfc2131.c
> +++ b/src/rfc2131.c
> @@ -882,8 +882,13 @@ size_t dhcp_reply(struct dhcp_context *context, char
> *iface_name, int int_index,
>
>   clear_packet(mess, end);
>
> - /* Redirect the client to port 4011 */
> - mess->siaddr = tmp->local;
> + /* Redirect EFI clients to port 4011 */
> + int redirect4011 = 0;
> + if (pxearch >= 6)
> + {
> + redirect4011 = 1;
> + 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);
> @@ -906,7 +911,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 (pxe && !workaround)
> + if ((pxe && !workaround) || !redirect4011)
> 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);
>
>
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] ProxyDHCP mode is broken for serving ipxe.efi to UEFI pxe clents

[Michael Kuron]

Hi Simon,

thanks, it’s working fine for me now. Before releasing 2.76, it would be good 
if more people could test this on actual hardware.
Also, there’s one more item that needs to go into the release notes: we now 
redirect all clients to port 4011, including the BIOS clients. This is a change 
in behavior over the previous release, where the option 43 menu was sent on 
port 68. This could potentially break things for some very old and broken PXE 
implementations. It’s unlikely, since the port 4011 stuff has always been part 
of the PXE spec, but possible. I don’t think it’s really necessary, but I have 
included a patch below that restricts the port 4011 redirect to CSA >= 6. With 
that patch, the PXE behavior for BIOS clients is exactly what it was in older 
releases.

Michael


--- a/src/rfc2131.c
+++ b/src/rfc2131.c
@@ -882,8 +882,13 @@ size_t dhcp_reply(struct dhcp_context *context, char 
*iface_name, int int_index,
  
  clear_packet(mess, end);
  
- /* Redirect the client to port 4011 */
- mess->siaddr = tmp->local;
+ /* Redirect EFI clients to port 4011 */
+ int redirect4011 = 0;
+ if (pxearch >= 6)
+ {
+ redirect4011 = 1;
+ 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);
@@ -906,7 +911,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 (pxe && !workaround)
+ if ((pxe && !workaround) || !redirect4011)
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);


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] ProxyDHCP mode is broken for serving ipxe.efi to UEFI pxe clents

[Simon Kelley]

Great, thanks. I've applied your patch and made a further change:
instead of changing the filename behaviour based on CSA, it looks at the
filename provided. If it has a suffix (strictly, if it includes a '.'
character) then the filename is used as-is. Otherwise it as the layer
added as suffix.

That seems most sensible. It has a small risk of breaking existing
setups with files called boot.bios.0. but that can be handled with a
release-note in the changelog.


In git now.

Simon.





On 14/05/16 18:47, Michael Kuron wrote:
> 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)
>  {

Re: [Dnsmasq-discuss] ProxyDHCP mode is broken for serving ipxe.efi to UEFI pxe clents

[Michael Kuron]

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, >siaddr, (char *)mess->sname, INET_ADDRSTRLEN);
 }
   
-  snprintf((char *)mess->file, sizeof(mess->file), "%s.0", found->basename);
+  if (pxe_arch == 0)
+  snprintf((char 

Re: [Dnsmasq-discuss] ProxyDHCP mode is broken for serving ipxe.efi to UEFI pxe clents

[Simon Kelley]

On 11/05/16 07:04, Jarek Polok wrote:
> On 05/10/2016 06:44 PM, Simon Kelley wrote:

> The full up to date list of arches seems to be there:
> 
> 
> http://www.ietf.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml#processor-architecture
> 
> 
> (but only types 0 to 9 are defined in an rfc (rfc4578) ..)
> 

.. and RFC 4578 has an error and swaps BC_EFI and x86-64_EFI. Dnsmasq
followed 4578 and has the same error. I've just pushed the fix for that,
but it means that if people were using BC_EFI as the CSA, because that
made it work, they'll need to change their configs to  use x86-64_EFI
instead.


Cheers,

Simon.


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] ProxyDHCP mode is broken for serving ipxe.efi to UEFI pxe clents

[Simon Kelley]

On 11/05/16 07:04, Jarek Polok wrote:
> On 05/10/2016 06:44 PM, Simon Kelley wrote:
>> I just pushed my take on this to git. It's untested, and covers what I
>> think are the correct choices so far. Please could you all test?
>>
>> I picked
>>
>> 1) .0 in workaround mode, to match all other situations.
> 
> If I understand well then:
> 
> pxe-service=..., /path/pxelinux -> sends /path/pxelinux.0
> pxe-service=..., /path/bootx64.efi -> sends /path/bootx64.efi.0
> 
> ?

Yes. When the full menu code is used, and the PXE client makes a
boot-server request with a layer-number, then the filename becomes
.

When we're short-circuiting this by not sending a menu and just sending
a filename, to get the same behaviour we use the .0 name.
That's making the assumption that the client will always choose layer
zero, which seems to be true in practice.

To make is consistent, if we want to use just , we'd need to
stop adding the layer number in the boot-server code paths too, at least
for EFI CSAs. That's a change of behaviour that could break existing stuff.

> 
>> 2) Workaround in non-proxy mode too.
>> 3) Workaround engaged for CAS 6,7,8,9 only.
> 
> Could you please add CSA 10 and 11 there as well ?
> 
> 10 - ARM 32-bit UEFI -> most likely will need it too ..
> 11 - ARM 64-bit UEFI -> needs it (we have confirmed this
>   on 3 different models)
> 

Seems that the best condition to use is CSA >= 6

I should add those to the option parsing too.


Cheers,

Simon.

 >
> The full up to date list of arches seems to be there:
> 
> 
> http://www.ietf.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml#processor-architecture
> 
> 
> (but only types 0 to 9 are defined in an rfc (rfc4578) ..)
> 
> 
>> 4) sname filed always set.
>>
>> I'd like to release 2.76 ASAP so I've chosen to make an RC1 release, but
>> that doesn't mean that I think this patch is right, or that I won't
>> accept changes before the final release.
>>
> 
> 
> Thanks
> 
> Jarek
> 
>>
>> Cheers,
>>
>> Simon.
>>
>>
>>
>> On 10/05/16 16:42, Jarek Polok wrote:
>>> Hi
>>>
>>> On 05/10/2016 04:55 PM, Simon Kelley wrote:
 Lots of good info. Thanks everybody. Some more queries.

 First, I'm minded to go with Michael's choice for "enabling"
 workarounds; ie do what's needed to make things work with buggy PXe
 menu's when there's exactly one relevant menu entry.

>>>
>>> OK, so if num_services > 1 the current behavior is expected
>>> (working on BIOS not working on UEFI) , right ?
>>>
>>> Maybe an additional log message could be provided in such case ?
>>>
>>> Also, Michael's patch works for CSA = 6,7,8 and 9 -> please add CSA = 11
>>> too
>>>
>>> (aarch64 EFI, I have same problems there on 3 different arm 64
>>> systems):
>>>
>>> or maybe that should be the default for all CSA's ?
>>>
>>> (to avoid necessity of changing source code for any other arches in
>>> the future ?)
>>>
>>>
 Second,
Don't crash with divide-by-zero if an IPv6 dhcp-range
>>  is declared as a whole /64.
>>  (ie xx::0 to xx:::::)
>>  Thanks to Laurent Bendel for spotting this problem.
>>
>>  Add support for a TTL parameter in --host-record and
>>  --cname.
>>
>>  Add --dhcp-ttl option.
>>
>>  Add --tftp-mtu option. Thanks to Patrick McLean for the
>>  initial patch.
>>
>>  Check return-code of inet_pton() when parsing dhcp-option.
>>  Bad addresses could fail to generate errors and result in
>>  garbage dhcp-options being sent. Thanks to Marc Branchaud
>>  for spotting this.
>>
>>  Fix wrong value for EDNS UDP packet size when using
>>  --servers-file to define upstream DNS servers. Thanks to
>>  Scott Bonar for the bug report.
>>
>>  Move the dhcp_release and dhcp_lease_time tools from
>>  contrib/wrt to contrib/lease-tools.
>>
>>  Add dhcp_release6 to contrib/lease-tools. Many thanks
>>  to Sergey Nechaev for this code.
>>
>>  To avoid filling logs in configurations which define
>>  many upstream nameservers, don't log more that 30 servers.
>>  The number to be logged can be changed as SERVERS_LOGGED
>>  in src/config.h.
>>
>>
.0 vs. .efi

>>>
>>> [...]
>>>
 convention. But Jarek's patch doesn't do this and works, so this must
 only be a server-side thing (ie, using Jarek's patch, the file has
 to be
 renamed as .0 on the TFTP server, the client doesn't care what it
 is. Don't know what to do there, I'm tempted to make the behaviour the
 same in every case, but if everybody else is booting .efi files,
 that may be confusing.
>>>
>>> In our experience (lots of hw models PXE booted since .. some time) the
>>> .0 was only needed in some early PXE BIOSes  and only when using PXE
>>> menu (the 

Re: [Dnsmasq-discuss] ProxyDHCP mode is broken for serving ipxe.efi to UEFI pxe clents

[Jarek Polok]

On 05/10/2016 06:44 PM, Simon Kelley wrote:

I just pushed my take on this to git. It's untested, and covers what I
think are the correct choices so far. Please could you all test?

I picked

1) .0 in workaround mode, to match all other situations.


If I understand well then:

pxe-service=..., /path/pxelinux -> sends /path/pxelinux.0
pxe-service=..., /path/bootx64.efi -> sends /path/bootx64.efi.0

?


2) Workaround in non-proxy mode too.
3) Workaround engaged for CAS 6,7,8,9 only.


Could you please add CSA 10 and 11 there as well ?

10 - ARM 32-bit UEFI -> most likely will need it too ..
11 - ARM 64-bit UEFI -> needs it (we have confirmed this
  on 3 different models)


The full up to date list of arches seems to be there:


http://www.ietf.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml#processor-architecture

(but only types 0 to 9 are defined in an rfc (rfc4578) ..)



4) sname filed always set.

I'd like to release 2.76 ASAP so I've chosen to make an RC1 release, but
that doesn't mean that I think this patch is right, or that I won't
accept changes before the final release.




Thanks

Jarek



Cheers,

Simon.



On 10/05/16 16:42, Jarek Polok wrote:

Hi

On 05/10/2016 04:55 PM, Simon Kelley wrote:

Lots of good info. Thanks everybody. Some more queries.

First, I'm minded to go with Michael's choice for "enabling"
workarounds; ie do what's needed to make things work with buggy PXe
menu's when there's exactly one relevant menu entry.



OK, so if num_services > 1 the current behavior is expected
(working on BIOS not working on UEFI) , right ?

Maybe an additional log message could be provided in such case ?

Also, Michael's patch works for CSA = 6,7,8 and 9 -> please add CSA = 11
too

(aarch64 EFI, I have same problems there on 3 different arm 64
systems):

or maybe that should be the default for all CSA's ?

(to avoid necessity of changing source code for any other arches in
the future ?)



Second,
   Don't crash with divide-by-zero if an IPv6 dhcp-range

 is declared as a whole /64.
 (ie xx::0 to xx:::::)
 Thanks to Laurent Bendel for spotting this problem.

 Add support for a TTL parameter in --host-record and
 --cname.

 Add --dhcp-ttl option.

 Add --tftp-mtu option. Thanks to Patrick McLean for the
 initial patch.

 Check return-code of inet_pton() when parsing dhcp-option.
 Bad addresses could fail to generate errors and result in
 garbage dhcp-options being sent. Thanks to Marc Branchaud
 for spotting this.

 Fix wrong value for EDNS UDP packet size when using
 --servers-file to define upstream DNS servers. Thanks to
 Scott Bonar for the bug report.

 Move the dhcp_release and dhcp_lease_time tools from
 contrib/wrt to contrib/lease-tools.

 Add dhcp_release6 to contrib/lease-tools. Many thanks
 to Sergey Nechaev for this code.

 To avoid filling logs in configurations which define
 many upstream nameservers, don't log more that 30 servers.
 The number to be logged can be changed as SERVERS_LOGGED
 in src/config.h.



   .0 vs. .efi



[...]


convention. But Jarek's patch doesn't do this and works, so this must
only be a server-side thing (ie, using Jarek's patch, the file has to be
renamed as .0 on the TFTP server, the client doesn't care what it
is. Don't know what to do there, I'm tempted to make the behaviour the
same in every case, but if everybody else is booting .efi files,
that may be confusing.


In our experience (lots of hw models PXE booted since .. some time) the
.0 was only needed in some early PXE BIOSes  and only when using PXE
menu (the proxy DHCP mode).

I personally think that current PXE/BIOS behavior is confusing (auto
adding .0): but as it was pointed out already changing that would
break backwards compatibility ... so guess .0 for x86PC and .efi for CSA
= 6,7,8,9 and 11 (perhaps other ??) will be more consistent ..

(or perhaps an option to make dnsmasq not to add suffixes there would
be a possibility too ? ...)




Third,

both patches, AFAIK only address Proxy-DHCP mode, which has separate
code from that sending PXE options with "normal" DHCP when a proxy-dhcp
server isn't used. Should the modifications to the PXE options be made
in that case too?


There should not be a need for that I believe: when dnsmasq operates
in 'standard' mode it acts as a boot server already: what Michael's
patch does for proxyDHCP is to 'downgrade' the 'PXE built-in menu
system' to reply as a boot server.



Fourth,>> - It gives more flexibility: the workaround can be applied only

   to predefined  and  (sorry - patched man page should be
   improved to state that clearly): so we can use that to implement
   for example sthg like this:

- match on 

Re: [Dnsmasq-discuss] ProxyDHCP mode is broken for serving ipxe.efi to UEFI pxe clents

[Simon Kelley]

I just pushed my take on this to git. It's untested, and covers what I
think are the correct choices so far. Please could you all test?

I picked

1) .0 in workaround mode, to match all other situations.
2) Workaround in non-proxy mode too.
3) Workaround engaged for CAS 6,7,8,9 only.
4) sname filed always set.

I'd like to release 2.76 ASAP so I've chosen to make an RC1 release, but
that doesn't mean that I think this patch is right, or that I won't
accept changes before the final release.


Cheers,

Simon.



On 10/05/16 16:42, Jarek Polok wrote:
> Hi
> 
> On 05/10/2016 04:55 PM, Simon Kelley wrote:
>> Lots of good info. Thanks everybody. Some more queries.
>>
>> First, I'm minded to go with Michael's choice for "enabling"
>> workarounds; ie do what's needed to make things work with buggy PXe
>> menu's when there's exactly one relevant menu entry.
>>
> 
> OK, so if num_services > 1 the current behavior is expected
> (working on BIOS not working on UEFI) , right ?
> 
> Maybe an additional log message could be provided in such case ?
> 
> Also, Michael's patch works for CSA = 6,7,8 and 9 -> please add CSA = 11
> too
> 
> (aarch64 EFI, I have same problems there on 3 different arm 64
> systems):
> 
> or maybe that should be the default for all CSA's ?
> 
> (to avoid necessity of changing source code for any other arches in
> the future ?)
> 
> 
>> Second,
>>   Don't crash with divide-by-zero if an IPv6 dhcp-range
is declared as a whole /64.
(ie xx::0 to xx:::::)
Thanks to Laurent Bendel for spotting this problem.

Add support for a TTL parameter in --host-record and
--cname.

Add --dhcp-ttl option.

Add --tftp-mtu option. Thanks to Patrick McLean for the
initial patch.

Check return-code of inet_pton() when parsing dhcp-option.
Bad addresses could fail to generate errors and result in
garbage dhcp-options being sent. Thanks to Marc Branchaud
for spotting this.

Fix wrong value for EDNS UDP packet size when using
--servers-file to define upstream DNS servers. Thanks to
Scott Bonar for the bug report.

Move the dhcp_release and dhcp_lease_time tools from
contrib/wrt to contrib/lease-tools.

Add dhcp_release6 to contrib/lease-tools. Many thanks
to Sergey Nechaev for this code.

To avoid filling logs in configurations which define
many upstream nameservers, don't log more that 30 servers.
The number to be logged can be changed as SERVERS_LOGGED
in src/config.h.


>>   .0 vs. .efi
>>
> 
> [...]
> 
>> convention. But Jarek's patch doesn't do this and works, so this must
>> only be a server-side thing (ie, using Jarek's patch, the file has to be
>> renamed as .0 on the TFTP server, the client doesn't care what it
>> is. Don't know what to do there, I'm tempted to make the behaviour the
>> same in every case, but if everybody else is booting .efi files,
>> that may be confusing.
> 
> In our experience (lots of hw models PXE booted since .. some time) the
> .0 was only needed in some early PXE BIOSes  and only when using PXE
> menu (the proxy DHCP mode).
> 
> I personally think that current PXE/BIOS behavior is confusing (auto
> adding .0): but as it was pointed out already changing that would
> break backwards compatibility ... so guess .0 for x86PC and .efi for CSA
> = 6,7,8,9 and 11 (perhaps other ??) will be more consistent ..
> 
> (or perhaps an option to make dnsmasq not to add suffixes there would
> be a possibility too ? ...)
> 
> 
>>
>> Third,
>>
>> both patches, AFAIK only address Proxy-DHCP mode, which has separate
>> code from that sending PXE options with "normal" DHCP when a proxy-dhcp
>> server isn't used. Should the modifications to the PXE options be made
>> in that case too?
> 
> There should not be a need for that I believe: when dnsmasq operates
> in 'standard' mode it acts as a boot server already: what Michael's
> patch does for proxyDHCP is to 'downgrade' the 'PXE built-in menu
> system' to reply as a boot server.
> 
>>
>> Fourth,>> - It gives more flexibility: the workaround can be applied only
   to predefined  and  (sorry - patched man page should be
   improved to state that clearly): so we can use that to implement
   for example sthg like this:

- match on given hwaddr prefix with dhcp-match, then tag
- match on tag and client architecture and apply workaround only
  then.
>>>
>>> You can also use tags with my patch and achieve the same thing.
> 
> Yes, indeed, - sorry must have been looking at wrong code ...
> 
> [...]
> 
> Thanks !
> 
> Best Regards
> 
> Jarek
> 
> __
> ---
> _ Jaroslaw_Polok ___ CERN - IT/CM/LCS _
> _ http://cern.ch/~jpolok  tel_+41_22_767_1834 _
> 

Re: [Dnsmasq-discuss] ProxyDHCP mode is broken for serving ipxe.efi to UEFI pxe clents

[Jarek Polok]

Hi

On 05/10/2016 04:55 PM, Simon Kelley wrote:

Lots of good info. Thanks everybody. Some more queries.

First, I'm minded to go with Michael's choice for "enabling"
workarounds; ie do what's needed to make things work with buggy PXe
menu's when there's exactly one relevant menu entry.



OK, so if num_services > 1 the current behavior is expected
(working on BIOS not working on UEFI) , right ?

Maybe an additional log message could be provided in such case ?

Also, Michael's patch works for CSA = 6,7,8 and 9 -> please add CSA = 11 
too


(aarch64 EFI, I have same problems there on 3 different arm 64
systems):

or maybe that should be the default for all CSA's ?

(to avoid necessity of changing source code for any other arches in
the future ?)



Second,

  .0 vs. .efi



[...]


convention. But Jarek's patch doesn't do this and works, so this must
only be a server-side thing (ie, using Jarek's patch, the file has to be
renamed as .0 on the TFTP server, the client doesn't care what it
is. Don't know what to do there, I'm tempted to make the behaviour the
same in every case, but if everybody else is booting .efi files,
that may be confusing.


In our experience (lots of hw models PXE booted since .. some time) the 
.0 was only needed in some early PXE BIOSes  and only when using PXE 
menu (the proxy DHCP mode).


I personally think that current PXE/BIOS behavior is confusing (auto 
adding .0): but as it was pointed out already changing that would
break backwards compatibility ... so guess .0 for x86PC and .efi for CSA 
= 6,7,8,9 and 11 (perhaps other ??) will be more consistent ..


(or perhaps an option to make dnsmasq not to add suffixes there would
be a possibility too ? ...)




Third,

both patches, AFAIK only address Proxy-DHCP mode, which has separate
code from that sending PXE options with "normal" DHCP when a proxy-dhcp
server isn't used. Should the modifications to the PXE options be made
in that case too?


There should not be a need for that I believe: when dnsmasq operates
in 'standard' mode it acts as a boot server already: what Michael's 
patch does for proxyDHCP is to 'downgrade' the 'PXE built-in menu 
system' to reply as a boot server.




Fourth,>> - It gives more flexibility: the workaround can be applied only

  to predefined  and  (sorry - patched man page should be
  improved to state that clearly): so we can use that to implement
  for example sthg like this:

   - match on given hwaddr prefix with dhcp-match, then tag
   - match on tag and client architecture and apply workaround only
 then.


You can also use tags with my patch and achieve the same thing.


Yes, indeed, - sorry must have been looking at wrong code ...

[...]

Thanks !

Best Regards

Jarek

__
---
_ Jaroslaw_Polok ___ CERN - IT/CM/LCS _
_ http://cern.ch/~jpolok  tel_+41_22_767_1834 _
__+41_75_411_9487 _



___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] ProxyDHCP mode is broken for serving ipxe.efi to UEFI pxe clents

[Simon Kelley]

Lots of good info. Thanks everybody. Some more queries.

First, I'm minded to go with Michael's choice for "enabling"
workarounds; ie do what's needed to make things work with buggy PXe
menu's when there's exactly one relevant menu entry.

Second,

 .0 vs. .efi

What's not been mentioned here is that the 0-suffix is actually a
integer. There's a field in the pxe-boot-item called "layer" and that's
what's used to make the suffix. That could be any number less that 2^15.
What the function of this is seems to somewhat lost on time:

ftp://download.intel.com/design/archives/wfm/downloads/pxespec.pdf

says

   This option is required to discover Boot Servers. Only the client
   may change the type field; either the client or the server may
   change the layer field. Layer 0 always indicates the first boot file
   for a particular Boot Server type. Boot Servers capable of providing
   the boot file requested in the PXE_BOOT_ITEM must respond.

Which is about as clear and useful is the rest of that document :)

I guess we're assuming that this layer business has been found to be
useless (layer is always zero) and that the "efi" suffix is the new
convention. But Jarek's patch doesn't do this and works, so this must
only be a server-side thing (ie, using Jarek's patch, the file has to be
renamed as .0 on the TFTP server, the client doesn't care what it
is. Don't know what to do there, I'm tempted to make the behaviour the
same in every case, but if everybody else is booting .efi files,
that may be confusing.

Third,

both patches, AFAIK only address Proxy-DHCP mode, which has separate
code from that sending PXE options with "normal" DHCP when a proxy-dhcp
server isn't used. Should the modifications to the PXE options be made
in that case too?

Fourth,>> - It gives more flexibility: the workaround can be applied only
>>  to predefined  and  (sorry - patched man page should be
>>  improved to state that clearly): so we can use that to implement
>>  for example sthg like this:
>>
>>   - match on given hwaddr prefix with dhcp-match, then tag
>>   - match on tag and client architecture and apply workaround only
>> then.
>
> You can also use tags with my patch and achieve the same thing. For
example, if you want clients with tag abcd to display a menu with two
entries and all other clients to boot directly to the first entry (which
for them is the only entry, thus invoking my workaround), you should be
able to use something like
> pxe-service=BC_EFI,iPXE,pxelinux
> pxe-service=tag:abcd,BC_EFI,iPXE,ipxe
>
>> - setting of sname is indeed because I found 2 clients which did not
>>  want to boot without it ..
>
> Ok, then I suggest we add that to my patch.
>
>> - naming convention:
>>
>>  .0 vs. .efi
>
> The .0 for X86PC can’t be changed due to backwards
compatibility, otherwise everybody would have to update their config
files. I’d be ok with not automatically adding an extension for all
other architectures though. However, that would be inconsistent and also
backwards-incompatible, though I wouldn’t worry too much about the
latter as googling for "pxe-service=..." does not yield any meaningful
hits for anything but x86PC, IA32_EFI, BC_EFI and X86-64_EFI.
>
> Michael
>
>
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>


Setting ->siaddr

My feeling that that ->siaddr should be set to the local address
whenever the discover is received on port 68, no matter how many menu
items there are. And related, the code below

 /* Provide the bootfile here, for gPXE, and in case we have no menu
and and set discovery_control = 8 */

which also sets ->siaddr, should be lower priority, it should only run
when receiving on 4011. That code can also only run when num_services ==
0, given its function.


Comments?


Cheers,

Simon.


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] ProxyDHCP mode is broken for serving ipxe.efi to UEFI pxe clents

[Michael Kuron]

> - I think that this is just a workaround (because what
>  dnsmasq implements should be working for PXE/UEFI ...)
>  and it may not be needed in the future ..  so kind more 'elegant' to
>  implement it this way (option could be called 'pxe-menu-workaround'
>  perhaps ?

This workaround will be required for at least a decade to come, as many current 
UEFI implementation still don’t correctly implement menus. So 99% of setups 
would need to enable the workaround, which means it should be default to avoid 
confusion.
Also, what’s wrong with disabling the menu if there is only one entry for the 
architecture, like my patch does? It doesn’t reduce functionality in any way 
and reduces the number of configuration options needed in the most common 
scenarios.

> - It gives more flexibility: the workaround can be applied only
>  to predefined  and  (sorry - patched man page should be
>  improved to state that clearly): so we can use that to implement
>  for example sthg like this:
> 
>   - match on given hwaddr prefix with dhcp-match, then tag
>   - match on tag and client architecture and apply workaround only
> then.

You can also use tags with my patch and achieve the same thing. For example, if 
you want clients with tag abcd to display a menu with two entries and all other 
clients to boot directly to the first entry (which for them is the only entry, 
thus invoking my workaround), you should be able to use something like
pxe-service=BC_EFI,iPXE,pxelinux
pxe-service=tag:abcd,BC_EFI,iPXE,ipxe

> - setting of sname is indeed because I found 2 clients which did not
>  want to boot without it ..

Ok, then I suggest we add that to my patch.

> - naming convention:
> 
>  .0 vs. .efi

The .0 for X86PC can’t be changed due to backwards compatibility, 
otherwise everybody would have to update their config files. I’d be ok with not 
automatically adding an extension for all other architectures though. However, 
that would be inconsistent and also backwards-incompatible, though I wouldn’t 
worry too much about the latter as googling for "pxe-service=..." does not 
yield any meaningful hits for anything but x86PC, IA32_EFI, BC_EFI and 
X86-64_EFI.

Michael


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] ProxyDHCP mode is broken for serving ipxe.efi to UEFI pxe clents

[Jarek Polok]

Hello all, (and sorry for top-posting, but trying to catch up with this 
thread)


Since I believe that you already described what I had in mind in my 
version of the patch ;-) I'll like to just add few comments on remaining

points:

Simon:

yes of course that would be possible to skip the option 'pxe-skip-menu' 
alltogether: but



- I think that this is just a workaround (because what
  dnsmasq implements should be working for PXE/UEFI ...)
  and it may not be needed in the future ..  so kind more 'elegant' to
  implement it this way (option could be called 'pxe-menu-workaround'
  perhaps ?

- It gives more flexibility: the workaround can be applied only
  to predefined  and  (sorry - patched man page should be
  improved to state that clearly): so we can use that to implement
  for example sthg like this:

   - match on given hwaddr prefix with dhcp-match, then tag
   - match on tag and client architecture and apply workaround only
 then.


I think the 'tagging' capability of dnsmasq is rather nice feature
and should not be removed for this kind of workaround...


Dreamcat4:

Yes, the option could take multiple arguments:

pxe-skip-menu="TAG1,CSA1,TAG2,CSA2" .. etc (tags being optional)..
not sure that this is  more readable than having the option specified 
multiple times ... (but have no strong opinion about that ..)


I think that explaining in man page as you proposed - should be enough ..


wkitty42/Dreamcat4/Simon:

I also think that a workaround would better not be enabled by default,
just used when really needed.


Michael/Simon:

- setting of sname is indeed because I found 2 clients which did not
  want to boot without it ..

- naming convention:

  .0 vs. .efi -  (I believe that I actually added .0 for efi
  there): I think this is just convention (I believe initial idea was
  that boot rom will be able to recognize the boot loader executable
  format by extension and act accordingly to run it ... but I dont
  think this really matters in current implementations .. for example
  the Windows Deployment Server serves an .com or .exe or .efi this
  days ...)

  I think that actually the fact that dnsmasq adds '.0' for x86PC
  is little bit confusing (yeah, I know its documented ..): and I
  think that maybe it would be better not to add anything
  'automagically' there .. but of course that would break backwards
  compatibility ...

  Then this will be confusing even more if sometimes .0
  and sometimes .efi is added, as an example:

  pxe-service=tag:TAG1,x86PC, "a", /path/loader
  pxe-service=tag:TAG2,X86-64_EFI, "a" , /path/loader

  first line would send /path/loader.0
  second would send /path/loader.efi

  So my personal opinion would be that adding no suffix
  at all would be better ..

...

OK, so there are my 0.02EUR, thanks everybody !

Best Regards

Jarek


__
---
_ Jaroslaw_Polok ___ CERN - IT/CM/LCS _
_ http://cern.ch/~jpolok  tel_+41_22_767_1834 _
__+41_75_411_9487 _



___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] ProxyDHCP mode is broken for serving ipxe.efi to UEFI pxe clents

[Michael Kuron]

> The difference between Michael's patch and Jarek's seems to be that
> Michael's works automatically when there is precisely one valid boot
> service line, but Jarek's needs explicit configuration. What situation
> does Jarek's approach cover, that Michael's doesn’t?

I’ve also been wondering about that. Comparing the patches, I believe that, 
when skipping the menu, the only difference is that Jarek additionally sets the 
sname field, while I only set siaddr and file. I think Jarek said that without 
sname, some of his clients didn’t boot. I think it would be fine to add the 
sname line to my patch and hopefully that should fix Jarek’s clients too 
without needing all that pxe_skip_menu code.

> Michael's path sets the boot filename to .efi rather than .0
> when the CSA is "IA32_EFI", "BC_EFI", "Xscale_EFI", or "x86-64_EFI" but
> Jarek's doesn't. Should that be added to Jarek's patch?

Absolutely. .0 is correct for x86 BIOS and .efi is correct for EFI 
on any platform. Not sure about other (less common) platforms, but the current 
. is probably not right for anything except x86 BIOS.

> Sorry if these seem like stupid questions. I'm working blind here,
> without a test system to experiment with.

If you have access to a recent version of VMware, I can send you a VMX file and 
an EFI binary for testing.

Michael


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] ProxyDHCP mode is broken for serving ipxe.efi to UEFI pxe clents

[Simon Kelley]

I don't think that doing bug work-around behavior automagically is a
good idea. If it is required to do non-standard stuff, that should be
explicit.

The difference between Michael's patch and Jarek's seems to be that
Michael's works automatically when there is precisely one valid boot
service line, but Jarek's needs explicit configuration. What situation
does Jarek's approach cover, that Michael's doesn't?

Second question:

Michael's path sets the boot filename to .efi rather than .0
when the CSA is "IA32_EFI", "BC_EFI", "Xscale_EFI", or "x86-64_EFI" but
Jarek's doesn't. Should that be added to Jarek's patch?

Sorry if these seem like stupid questions. I'm working blind here,
without a test system to experiment with.


Cheers,

Simon.



On 08/05/16 17:32, Dreamcat4 wrote:
> On Sun, May 8, 2016 at 3:41 PM,  wrote:
> 
>> how about going the other way... reverse the logic so that those two are
>> skipped all the time... then only if they are needed, add an option to
>> enable them...
>>
>>   pxe-add-menu=X86-64_EFI
>>   pxe-add-menu=BC_EFI
>>
> 
> Yeah that is not an unwelcome suggestion. Actually I was originally going
> to say that same thing myself. Unfortunately, looking more closely a
> similar type of problems comes up with doing it like that (either way
> around).
> 
> AFAIKT...
> 
> people should only need to care / override this option if the client is
> mis-behaving (client cannot show menu / hangs on menu / is buggy). So doing
> a positive logic (pxe-add-menu=) is also not elegant. In fact, then there
> may be even more default cases to specify and set. (a majority of working
> clients).
> 
> Well if we must hard-code some behaviour, then for the fewest exception
> cases is better, no? Well that seems to be for skip (not add). Because
> people come here scratching out heads why pxe menu does not work for UEFI
> clients. That is why skip-menu direction was chosen by Jarek. Perhaps
> others can comment.
> 
> 
> Anyhow regardless whether the direction is add or skip... that is apart
> from my previous question. Which is:
> 
> Is it not best? (and simplest!) to modify Jarek's patch in this following
> ways:
> 
> pxe-skip-menu=",,etc"
> 
> With a quiet *default* setting of:
> 
> pxe-skip-menu="X86-64_EFI,BC_EFI"
> 
> + document it.
> 
> 
> That user can clear with:
> 
> pxe-skip-menu=""
> 
> If they ever need.
> 
> 
> 
> Instead of:
> 
> pxe-skip-menu=CSA1
> pxe-skip-menu=CSA2
> 
> Or:
> 
> pxe-add-menu=PC-DOS
> 
> Many thanks.
> 
> 
> 
> Kind Regards
> Dreamcat4
> 
> 
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] ProxyDHCP mode is broken for serving ipxe.efi to UEFI pxe clents

[Dreamcat4]

On Sun, May 8, 2016 at 3:41 PM,  wrote:

> how about going the other way... reverse the logic so that those two are
> skipped all the time... then only if they are needed, add an option to
> enable them...
>
>   pxe-add-menu=X86-64_EFI
>   pxe-add-menu=BC_EFI
>

Yeah that is not an unwelcome suggestion. Actually I was originally going
to say that same thing myself. Unfortunately, looking more closely a
similar type of problems comes up with doing it like that (either way
around).

AFAIKT...

people should only need to care / override this option if the client is
mis-behaving (client cannot show menu / hangs on menu / is buggy). So doing
a positive logic (pxe-add-menu=) is also not elegant. In fact, then there
may be even more default cases to specify and set. (a majority of working
clients).

Well if we must hard-code some behaviour, then for the fewest exception
cases is better, no? Well that seems to be for skip (not add). Because
people come here scratching out heads why pxe menu does not work for UEFI
clients. That is why skip-menu direction was chosen by Jarek. Perhaps
others can comment.


Anyhow regardless whether the direction is add or skip... that is apart
from my previous question. Which is:

Is it not best? (and simplest!) to modify Jarek's patch in this following
ways:

pxe-skip-menu=",,etc"

With a quiet *default* setting of:

pxe-skip-menu="X86-64_EFI,BC_EFI"

+ document it.


That user can clear with:

pxe-skip-menu=""

If they ever need.



Instead of:

pxe-skip-menu=CSA1
pxe-skip-menu=CSA2

Or:

pxe-add-menu=PC-DOS

Many thanks.



Kind Regards
Dreamcat4
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] ProxyDHCP mode is broken for serving ipxe.efi to UEFI pxe clents

[wkitty42]

On 05/08/2016 06:52 AM, Dreamcat4 wrote:

But it is bad for each UEFI pc users going forwards to know to need to
manually specify:

pxe-skip-menu=X86-64_EFI
pxe-skip-menu=BC_EFI

Every time around. Because that is nearly everybody going forwards. How to
solve? Can we then make the option logic work better?


how about going the other way... reverse the logic so that those two are skipped 
all the time... then only if they are needed, add an option to enable them...


  pxe-add-menu=X86-64_EFI
  pxe-add-menu=BC_EFI

in this manner, ONLY those that need to support the above UEFI mess need add the 
option(s)... everyone else sails on clean clear waters none the wiser ;)


if other UEFIs are found needing to be skipped, they can be added to the next 
binary with new options like the above...


--
 NOTE: No off-list assistance is given without prior approval.
   *Please keep mailing list traffic on the list* unless
   private contact is specifically requested and granted.

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] ProxyDHCP mode is broken for serving ipxe.efi to UEFI pxe clents

[Dreamcat4]

On Sat, May 7, 2016 at 9:49 PM, Simon Kelley 
wrote:

> On 06/05/16 12:58, Jaroslaw Polok wrote:
> > Hi
> >
> > On 06/05/16 12:40, Dreamcat4 wrote:
> >
> >>
> >> Perhaps later down the line (once more people get onboard and can start
> >> using it), then this pxe UEFI mode can be improved even further. Either
> >> buy some fresh eyes coming along to fix problems in ipxe.efi, or else
> >> here in the dnsmasq behaviour. Or both. But we need to make it easier
> >> for those guys to run it at least, so can see ahead to the next problem.
> >
> > In case you would be interested:
> >
> >
> http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2016q1/010383.html
> >
> > That is my version of the patch, using a configuration option
> > to allow more fine-grained control on how systems boot
> > (by optionally matching by tag and/or architecture).
> >
> > We are using that patch in production since two months
> > successfully booting all PXE/UEFI systems (x64 and aarch64)
> > we have used so far (about 10 different x64 and 3 different
> > aarch64 systems, plus qemu-kvm with Tianocore firmware)
> >
> > Dear Simon: would it be possible to review and include one
> > of this patches in dnsmasq please ?
> >
>
>
> Yes, That's the last thing on my list to do before I start to release
> 2.76. You and Dreamcat are going to have to help me though, since I
> don't have a usable test environment for this stuff, and my PXE
> knowledge is buried under several years of other stuff.
>

No problem, happy to help.

My main question is, is there a way to make this work without needing
> the --pxe-skip-menu option. I appreciate that this engages a workaround
> for buggy UEFI netboot implementations, but what's wrong with doing that
> automatically when there's only one possible boot?


Yeah I was thinking that too. But then I looked more carefully at Jarek's
patch this morning. And it gets me to understanding why he made the option
that way around.

It is a lot to do with how-to-set-options in dnsmasq (the options
conventions of your program).


> Are we loosing
> functionality (maybe with a hypothetical fully working BIOS) by doing that?
>

OK lets start with what we know:

pxe-skip-menu=X86-64_EFI
pxe-skip-menu=BC_EFI

is the best thing to cover all of the regular PC users. Which is nearly
everybody. That is great.



Now lets imagine we take away the option. So there is no exposed option
whatsoever.  New Drawback:

we cannot accomodate the situation where there are different behaving
clients identifying under a single CSA type. Which seems to be the case
(already known) for BC_EFI.

http://serverfault.com/questions/349693/pxe-architecture-bc-efi

What that link says ^^ is that BC_EFI is a non-descript (generic) client.
Which may be odd ones, like an old PowerPC mac or IBM PowerPC server. Or
equally it could be some early x86 UEFI client. That is a potential to need
to be flipped on/off a case-by-case basis. Depending upon the specific set
of client hardware models which exist at that site.

It may be true or false for lesser CSA types too. (depending the model of
hardware). 2nd example I can think of now is ARM64 uefi. Because IPXE
project just added support for ARM64 efi booting. For devices like rPi /
similar - very popular now. Don't see it listed as a CSA named type. Maybe
its going to identify as some new (higher) CSA number. Else re-use again
that generic catchall BC_EFI (yet again).

That is why I think having some kind of a user setting might be worth it.
For best comptibility to all users. We cannot be expected to know / test
all possible hardware. And there are many types of speciality devices /
quirky hardware.

But it is bad for each UEFI pc users going forwards to know to need to
manually specify:

pxe-skip-menu=X86-64_EFI
pxe-skip-menu=BC_EFI

Every time around. Because that is nearly everybody going forwards. How to
solve? Can we then make the option logic work better?

===
What about this idea:


Solution Part a)

Modify existing patch, make it a single string list of all CSAs for doing
pxe-skip-menu.

* Default value:

pxe-skip-menu="X86-64_EFI, BC_EFI".

* So if user says nothing, it 'just works'. If its wrong, simple for other
guys to come along later, tell us to update the setting ^^. Like to add
another one etc.

* User can overide it however they wish. To cover any quirky hardware they
might have (including to omit the troublesom BC_EFI on a per-user basis):

pxe-skip-menu=","


Solution Part b)

Add in to the man page a clear paragraph, saying what is the SYMPTOM (of a
UEFI hanging boot). Which is exactly why / when the user should be setting
this option to override the mask list of CSAs.




> Cheers,
>
> Simon.
>
>
>
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>
___
Dnsmasq-discuss mailing 

Re: [Dnsmasq-discuss] ProxyDHCP mode is broken for serving ipxe.efi to UEFI pxe clents

[Simon Kelley]

On 06/05/16 12:58, Jaroslaw Polok wrote:
> Hi
> 
> On 06/05/16 12:40, Dreamcat4 wrote:
> 
>>
>> Perhaps later down the line (once more people get onboard and can start
>> using it), then this pxe UEFI mode can be improved even further. Either
>> buy some fresh eyes coming along to fix problems in ipxe.efi, or else
>> here in the dnsmasq behaviour. Or both. But we need to make it easier
>> for those guys to run it at least, so can see ahead to the next problem.
> 
> In case you would be interested:
> 
> http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2016q1/010383.html
> 
> That is my version of the patch, using a configuration option
> to allow more fine-grained control on how systems boot
> (by optionally matching by tag and/or architecture).
> 
> We are using that patch in production since two months
> successfully booting all PXE/UEFI systems (x64 and aarch64)
> we have used so far (about 10 different x64 and 3 different
> aarch64 systems, plus qemu-kvm with Tianocore firmware)
> 
> Dear Simon: would it be possible to review and include one
> of this patches in dnsmasq please ?
> 


Yes, That's the last thing on my list to do before I start to release
2.76. You and Dreamcat are going to have to help me though, since I
don't have a usable test environment for this stuff, and my PXE
knowledge is buried under several years of other stuff.


My main question is, is there a way to make this work without needing
the --pxe-skip-menu option. I appreciate that this engages a workaround
for buggy UEFI netboot implementations, but what's wrong with doing that
automatically when there's only one possible boot? Are we loosing
functionality (maybe with a hypothetical fully working BIOS) by doing that?


Cheers,

Simon.



___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] ProxyDHCP mode is broken for serving ipxe.efi to UEFI pxe clents

[Dreamcat4]

Thanks Jarek!

Have tried your patch and switched to it in my auto builds now. Same
Bintray download URL as before:

https://dl.bintray.com/dreamcat4/linux/dnsmasq/

Re-formatted it so the patch will apply cleanly on v2.75 current release
version. Which is available here:

https://github.com/dreamcat4/docker-images/blob/master/linux-bin/dnsmasq/fix--dhcp-proxy-for-uefi-clients_02-mar-2016_jpolok.patch

The reason am using your patch now, is since you say it will be compatible
with more other uefi clients. So that is more good news to me. However it
is now necessary to add the following extra lines to dnsmasq.conf file.
Which is about this new option you added (skip menu). Otherwise uefi pxe
boot wont work at all. Like back to old days, where it just hangs, does
nothing like without any such uefi patch.

New lines to add to dnsmasq.conf:

pxe-skip-menu=X86-64_EFI
pxe-skip-menu=BC_EFI

The 2nd line was added for better compatibility (after other reports of
misbehaving clients), which is mentioned by David on other thread:

http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2015q4/010041.html


Anyway then it loads up the ipxe.efi. BTW, sorry for not being clear in my
previous mesg but the version of ipxe.efi have been testing with today is
v1.0.0+ (2d42d).

This lets me get forward enough to be encountering other bugs arounds
netbooting uefi. But those other new issue I am seeing now is nothing
related to dnsmasq itself. As that has finished / done its job by time of
those stages in the boot process.


Kind Regards
Dreamcat4



On Fri, May 6, 2016 at 12:58 PM, Jaroslaw Polok 
wrote:

> Hi
>
> On 06/05/16 12:40, Dreamcat4 wrote:
>
>
>> Perhaps later down the line (once more people get onboard and can start
>> using it), then this pxe UEFI mode can be improved even further. Either
>> buy some fresh eyes coming along to fix problems in ipxe.efi, or else
>> here in the dnsmasq behaviour. Or both. But we need to make it easier
>> for those guys to run it at least, so can see ahead to the next problem.
>>
>
> In case you would be interested:
>
> http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2016q1/010383.html
>
> That is my version of the patch, using a configuration option
> to allow more fine-grained control on how systems boot
> (by optionally matching by tag and/or architecture).
>
> We are using that patch in production since two months
> successfully booting all PXE/UEFI systems (x64 and aarch64)
> we have used so far (about 10 different x64 and 3 different
> aarch64 systems, plus qemu-kvm with Tianocore firmware)
>
> Dear Simon: would it be possible to review and include one
> of this patches in dnsmasq please ?
>
> Thanks
>
> Jarek
>
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] ProxyDHCP mode is broken for serving ipxe.efi to UEFI pxe clents

[Jaroslaw Polok]

Hi

On 06/05/16 12:40, Dreamcat4 wrote:



Perhaps later down the line (once more people get onboard and can start
using it), then this pxe UEFI mode can be improved even further. Either
buy some fresh eyes coming along to fix problems in ipxe.efi, or else
here in the dnsmasq behaviour. Or both. But we need to make it easier
for those guys to run it at least, so can see ahead to the next problem.


In case you would be interested:

http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2016q1/010383.html

That is my version of the patch, using a configuration option
to allow more fine-grained control on how systems boot
(by optionally matching by tag and/or architecture).

We are using that patch in production since two months
successfully booting all PXE/UEFI systems (x64 and aarch64)
we have used so far (about 10 different x64 and 3 different
aarch64 systems, plus qemu-kvm with Tianocore firmware)

Dear Simon: would it be possible to review and include one
of this patches in dnsmasq please ?

Thanks

Jarek

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] ProxyDHCP mode is broken for serving ipxe.efi to UEFI pxe clents

[Dreamcat4]

OK,
So I have 2 UEFI PCs. And today tested the patch. It worked! Very happy
about this.

I encourage other people to try it too, now the patched binary is available
from my bintray repo here:

https://dl.bintray.com/dreamcat4/linux/dnsmasq/

In coming days shall also be releasing a 'dreamcat4/pxe' docker image,
which will contain it + other necessary configuration / setup files for
serving up iPXE in both modes (legacy AND uefi). That is just not ready yet.

For this patch, I can only test in ProxyDHCP mode. Due to my other
technical limitations of available hardware / servers etc.

In proxy mode, this patch:

a) greatly improves the functionality of UEFI pxe booting, from nothing
(0%) --> to 'usable'
b) does not break the existing legacy BIOS pxe booting. both types can be
served simultaneously.

Was tested with iPXE pre-built binaries downloaded from iPXE website. They
were:


[image: [ ]]undionly.kpxe 06-May-2016
11:00 63K

[image: [ ]]ipxe.efi 06-May-2016 11:00 888K




Those observations seem to agree / confirm Michael's own findings about
about his last patch (of oct-31-2015). And what is mentioned bout iPXE.efi
on the iPXE website. For example that in UEFI mode, there is some
considerable delay, waiting about, where it says:

iPXE initialising devices

but then it eventually finds / goes into the menu. Perhaps with help of the
user pressing 'enter' key if stuck. So not perfect. But can be made to work.

Simon to pls take a look at this patch, be sight-checked for errors / risks
(anything amiss?), then if nothing bad found, pls consider adding to head
for next 'testing' tag future releases. That would be priceless. Appreciate
it.


Perhaps later down the line (once more people get onboard and can start
using it), then this pxe UEFI mode can be improved even further. Either buy
some fresh eyes coming along to fix problems in ipxe.efi, or else here in
the dnsmasq behaviour. Or both. But we need to make it easier for those
guys to run it at least, so can see ahead to the next problem. Many thanks.


Dreamcat4




On Thu, May 5, 2016 at 11:58 PM, Dreamcat4  wrote:

> In the meantime,
>
> Have setup an auto-builds. To make linux binary tarball of last released
> version. In debian / ubunt filesystem layout.
>
> Added with the necessary (but missing) uefi patch ^^ from Micahael
>
>
> Its built here:
>
>
> https://github.com/dreamcat4/docker-images/blob/master/linux-bin/Dockerfile#L26-63
>
>
>
> Binary is available here:
>
> https://dl.bintray.com/dreamcat4/linux/dnsmasq/
>
>
> Haven't tested it for myself yet. (but will try soon). Hope it works.
>
>
> Kind Regards
> Dreamcat4
>
>
>
>
>
> On Thu, May 5, 2016 at 8:26 PM, Dreamcat4  wrote:
>
>> Hi there,
>> Was hit by this undocumented bug in dnsmasq today / yesterday. It took a
>> fair whilefor me to realize this was the cause of my problem. But now
>> finally here! Coming across this list, and several threads in it, Michael
>> has kindly posted a patch to help get PXE working for UEFI clients:
>>
>>
>> http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2015q4/010007.html
>>
>> So today checked out the dnsmasq source code in git, and see this patch
>> is still missing / not applied. Therefore the bug remains in HEAD.
>>
>> So since then further searching, has unturned more affected people(s), on
>> here:
>>
>> http://serverfault.com/questions/758384/dnsmasq-proxy-mode-and-efi-boot
>>
>> And to breifly highlight one of those guys' comments, in hopes it might
>> be relevant to finding best solution possible. Michael can you comment? As
>> it was written about after you already made your last patch.
>>
>> "I have read the whole thread (
>> lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2015q4/…
>> )
>> and I'm shocked; those guys are completely lost; UEFI perfectly supports
>> proxyDHCP w/o using option 60, also using option 43 when not necessary
>> makes no sense. If I were I'd look away from dnsmasq; Sorry I didn't know
>> they were having this kind of unresolved problems. – Pat
>>  Feb 20 at 14:59
>> 
>> (2016)"
>>
>> Reading that, I do wonder where he got his information from. It seems to
>> suggest maybe there exists some working windows PXE server(s). Which work
>> in proxyDHCP mode for UEFI pxe clients. Something that could be wiresharked
>> / pcap tcpdump'd.
>>
>> Anyhow, unfortunately it doesnt seem theres any alternative to dnsmasq on
>> linux, for acting as a proxy DHCP server. At least not that I know of.
>> Several other answers on StackOverflow seem to confirm that view:
>>
>>
>> http://serverfault.com/questions/415857/can-isc-dhcpd-operate-as-a-proxy-dhcp-server-for-pxe-boot
>>
>>
>> So assuming that dnsmasq is still 

Re: [Dnsmasq-discuss] ProxyDHCP mode is broken for serving ipxe.efi to UEFI pxe clents

[Dreamcat4]

In the meantime,

Have setup an auto-builds. To make linux binary tarball of last released
version. In debian / ubunt filesystem layout.

Added with the necessary (but missing) uefi patch ^^ from Micahael


Its built here:

https://github.com/dreamcat4/docker-images/blob/master/linux-bin/Dockerfile#L26-63



Binary is available here:

https://dl.bintray.com/dreamcat4/linux/dnsmasq/


Haven't tested it for myself yet. (but will try soon). Hope it works.


Kind Regards
Dreamcat4





On Thu, May 5, 2016 at 8:26 PM, Dreamcat4  wrote:

> Hi there,
> Was hit by this undocumented bug in dnsmasq today / yesterday. It took a
> fair whilefor me to realize this was the cause of my problem. But now
> finally here! Coming across this list, and several threads in it, Michael
> has kindly posted a patch to help get PXE working for UEFI clients:
>
> http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2015q4/010007.html
>
> So today checked out the dnsmasq source code in git, and see this patch is
> still missing / not applied. Therefore the bug remains in HEAD.
>
> So since then further searching, has unturned more affected people(s), on
> here:
>
> http://serverfault.com/questions/758384/dnsmasq-proxy-mode-and-efi-boot
>
> And to breifly highlight one of those guys' comments, in hopes it might be
> relevant to finding best solution possible. Michael can you comment? As it
> was written about after you already made your last patch.
>
> "I have read the whole thread (
> lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2015q4/…
> )
> and I'm shocked; those guys are completely lost; UEFI perfectly supports
> proxyDHCP w/o using option 60, also using option 43 when not necessary
> makes no sense. If I were I'd look away from dnsmasq; Sorry I didn't know
> they were having this kind of unresolved problems. – Pat
>  Feb 20 at 14:59
> 
> (2016)"
>
> Reading that, I do wonder where he got his information from. It seems to
> suggest maybe there exists some working windows PXE server(s). Which work
> in proxyDHCP mode for UEFI pxe clients. Something that could be wiresharked
> / pcap tcpdump'd.
>
> Anyhow, unfortunately it doesnt seem theres any alternative to dnsmasq on
> linux, for acting as a proxy DHCP server. At least not that I know of.
> Several other answers on StackOverflow seem to confirm that view:
>
>
> http://serverfault.com/questions/415857/can-isc-dhcpd-operate-as-a-proxy-dhcp-server-for-pxe-boot
>
>
> So assuming that dnsmasq is still our best shot here, and that UEFI
> compatibility its becoming much more common now, can we please look again
> at michaels patch for inclusion? Or else have this known bug (of proxy
> mode) documented in the man page? Would really appreciate that. Many thanks.
>
>
>
> Dreamcat4
>
>
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss