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 > [email protected] > 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 [email protected] http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
