[Dnsmasq-discuss] ProxyDHCP mode is broken for serving ipxe.efi to UEFI pxe clents
Simon Kelley
simon at thekelleys.org.uk
Wed May 11 22:01:19 BST 2016
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
>>> 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
>>
>
>
More information about the Dnsmasq-discuss
mailing list