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

Simon Kelley simon at thekelleys.org.uk
Tue May 10 15:55:34 BST 2016


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,

 <name>.0 vs. <name>.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 <name>.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 <name>.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 <tag> and <CSA> (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:
>>
>>  <name>.0 vs. <name>.efi
>
> The <name>.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 at 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.




More information about the Dnsmasq-discuss mailing list