[Dnsmasq-discuss] ProxyDHCP mode is broken for serving ipxe.efi to UEFI pxe clents
Jarek Polok
Jaroslaw.Polok at cern.ch
Wed May 11 07:04:30 BST 2016
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
?
> 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::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
>> Dnsmasq-discuss at lists.thekelleys.org.uk
>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>>
>
>
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>
--
__
-------------------------------------------------------
_ Jaroslaw_Polok ___________________ CERN - IT/CM/LCS _
_ http://cern.ch/~jpolok ________ tel_+41_22_767_1834 _
______________________________________+41_75_411_9487 _
More information about the Dnsmasq-discuss
mailing list