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) <filename>.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 <filename>.<layer-no> When we're short-circuiting this by not sending a menu and just sending a filename, to get the same behaviour we use the <filename>.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 <filename>, 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::ffff:ffff:ffff:ffff) >> 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. >> >> >>>> <name>.0 vs. <name>.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 <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. >>> >>> 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 <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. >>> >>> 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 >>> [email protected] >>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss >>> >> >> >> _______________________________________________ >> Dnsmasq-discuss mailing list >> [email protected] >> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss >> > > _______________________________________________ Dnsmasq-discuss mailing list [email protected] http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
