[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