[Dnsmasq-discuss] Fwd: [PATCH] Re: pxe-service entries in dnsmasq conf seem to fail non-proxy EFI boot

Shrenik Bhura shrenik.bhura at gmail.com
Sat Oct 16 05:21:10 UTC 2021


@Alkis Georgopoulos <alkisg at gmail.com> Though no changes may be needed in
the existing ltsp-dnsmasq.conf, I just recalled that I had made some
modifications (lines 35-54) in mine for the sake of clarity for any future
hardware specific scenarios that I may encounter. Herein is attached the
no-proxy version of the same.

On Fri, 15 Oct 2021 at 18:41, Shrenik Bhura <shrenik.bhura at gmail.com> wrote:

> No changes need in ltsp-dnsmasq.conf . Just checked out from Petr's
> branch, compiled and replaced /usr/sbin/dnsmasq with the new one.
>
> Regards,
> Shrenik
>
> On Fri, 15 Oct, 2021, 17:16 Alkis Georgopoulos, <alkisg at gmail.com> wrote:
>
>> @Petr, thank you very much for troubleshooting this!
>>
>> @Shrenik, are any changes required in ltsp-dnsmasq.conf?
>> Or we just need to apply Petr's patch, compile/install, and it works?
>> Thank you as well for your persistence and testing!
>>
>> Cheers,
>> Alkis
>>
>> On 10/15/21 2:42 PM, Shrenik Bhura wrote:
>> The below response is to be read in the thread prior to the "all success
>> scenario" email.
>>
>> Apologies for the confusion but I only realised now that the post went
>> off-list just to Petr.
>>
>> Regards,
>> Shrenik
>>
>> ---------- Forwarded message ---------
>> From: *Shrenik Bhura* <shrenik.bhura at gmail.com
>> <mailto:shrenik.bhura at gmail.com>>
>> Date: Tue, 12 Oct, 2021, 09:58
>> Subject: Re: [Dnsmasq-discuss] [PATCH] Re: pxe-service entries in
>> dnsmasq conf seem to fail non-proxy EFI boot
>> To: Petr Menšík <pemensik at redhat.com <mailto:pemensik at redhat.com>>
>>
>>
>> Thanks Petr for the detailed revert.
>>
>> I shall try again with the pxe-services branch and revert with my test
>> results.
>>
>> Meanwhile I am trying to answer few of your queries -
>>
>>   > I have had trouble with proxy mode and I am not sure what is its
>> purpose. Do you know when proxy mode should be used? When is it required?
>>
>> proxy mode is being used when we have another server/router on the same
>> network that is handling dhcp and dhcp is not being done by dnsmasq
>> "authoritatively". Line 29 in ltsp-dnsmasq-proxy.conf
>> dhcp-range=set:proxy,192.168.2.0,proxy,255.255.255.0 takescare of that.
>>
>>  > It does not rely on option 43 PXE menus support, just plain old DHCP
>> boot file. Requires dnsmasq to be the (authoritative?) DHCP server on
>> the network.
>>
>> I actually had no problem with proxy mode with the current stable
>> release. My only issues have been with non-proxy + efi scenarios.  So
>> what you have suggested, already works for me.
>>
>> Just to clarify further -
>> When I am testing dnsmasq in non-proxy mode I use
>> ltsp-dnsmasq-noproxy.conf.
>> When I am testing dnsmasq in proxy mode I use ltsp-dnsmasq-proxy.conf.
>> The only difference is line 29 being commented or not respectively. I
>> hope you had made the switch of the configuration and had another device
>> on your network to serve dhcp requests.
>>
>> All the very best.
>>
>>
>> On Tue, 12 Oct 2021 at 07:12, Petr Menšík <pemensik at redhat.com
>> <mailto:pemensik at redhat.com>> wrote:
>>
>>      Okay, sorry for omitting others.
>>
>>      On 10/9/21 11:49, Shrenik Bhura wrote:
>>  >     Adding Alkis and Jigish back to the thread via cc.
>>  >>
>>  >     On Sat, 9 Oct 2021 at 15:18, Shrenik Bhura
>>  >     <shrenik.bhura at gmail.com <mailto:shrenik.bhura at gmail.com>> wrote:
>>  >>
>>  >         Hey Petr,
>>  >>
>>  >         I have read your post a few times but am only partially able
>>  >         to understand everything. It may be my lack of knowledge of
>>  >         the inner workings of all things involved. I shall give it a
>>  >         go again later and even try the patch. But where do you want
>>  >         me to apply the patch - on the master branch or on your
>>  >         pxe-services branch (
>>  >
>> https://github.com/InfrastructureServices/dnsmasq/tree/pxe-services
>>  >
>> <https://github.com/InfrastructureServices/dnsmasq/tree/pxe-services>
>>  >         ) ?
>>  >>
>>      That patch is against master from Simon's official repository. I
>>      have rebased that branch on github, the change is already there. You
>>      can just try that branch code as it is. That patch were more for
>>      Simon, because he does not merge remote branches directly.
>>  >>
>>  >>
>>  >         Meanwhile, from a novice point of view and from what I know
>>  >         works in dnsmasq, I have this query -
>>  >>
>>  >         Could dnsmasq not be made to ignore the pxe-service lines or
>>  >         bypass the corresponding logic from the ltsp-dnsmasq.conf when
>>  >         1. is_tag_set("proxy") == "False" i.e ignore these lines -
>>  >
>>
>> pxe-service=tag:proxy,tag:!ipxe-ok,X86PC,"undionly.kpxe",ltsp/undionly.kpxe
>>  >
>>
>> pxe-service=tag:proxy,tag:!ipxe-ok,X86-64_EFI,"snponly.efi",ltsp/snponly.efi
>>  >
>> pxe-service=tag:proxy,tag:ipxe-ok,X86PC,"ltsp.ipxe",ltsp/ltsp.ipxe
>>  >
>> pxe-service=tag:proxy,tag:ipxe-ok,X86-64_EFI,"ltsp.ipxe",ltsp/ltsp.ipxe
>>  >>
>>      My change attempts to do exactly that. Current released code enables
>>      special handling when pxe-service is present in configuration.
>>      Without any relation about required tags for it. I have tried to
>>      modify it to require matching pxe-service to be found for current
>>      request. In a case any service does not match, it should fallback to
>>      classic DHCP. Could you try how much I were successful? This should
>>      work on my pxe-services branch.
>>  >>
>>  >>
>>  >         2. and when is_tag_set("rpi") == "False" i.e. ignore this line
>>  >         or bypass corresponding logic -
>>  >         pxe-service=tag:rpi,X86PC,"Raspberry Pi Boot ",unused
>>  >         when dnsmasq is processing a request in /non-proxy mode/ and
>>  >         the request is from /X86-64_EFI clients/?
>>  >>
>>      Again, should work with my change. You should use a number to set a
>>      type, with 0 being order to boot from local disk instead.
>>
>>      pxe-service=tag:rpi,X86PC,"Raspberry Pi Boot   ",0
>>
>>      Note other pxe-services should not match rpi tag, so only above is
>>      offered to RPi.
>>
>>
>>
>> pxe-service=tag:proxy,tag:!rpi,tag:!ipxe-ok,X86PC,"undionly.kpxe",ltsp/undionly.kpxe
>>
>>
>> pxe-service=tag:proxy,tag:!rpi,tag:!ipxe-ok,X86-64_EFI,"snponly.efi",ltsp/snponly.efi
>>
>>
>> pxe-service=tag:proxy,tag:!rpi,tag:ipxe-ok,X86PC,"ltsp.ipxe",ltsp/ltsp.ipxe
>>
>>
>> pxe-service=tag:proxy,tag:!rpi,tag:ipxe-ok,X86-64_EFI,"ltsp.ipxe",ltsp/ltsp.ipxe
>>
>>  >>
>>  >         If possible, then everything would just work as expected for
>>  >         all scenarios - *(BIOS or UEFI or RPI) and proxy*, *(BIOS or
>>  >         UEFI or RPI) and non-proxy*.
>>  >         It may be possible to handle this just within dnsmasq.
>>  >>
>>      In ipxe.efi you have sent there seems to be missing support for
>>      menus defined by pxe-service (and option 43). That is a reason why
>>      pxe-service and pxe-prompt is there. If you don't need those menus,
>>      I would suggest using tags for
>>      dhcp-match=set:efi,option:client-arch,7 instead and using just pure
>>      dhcp-boot or dhcp-option=option:bootfile-name. Those should work
>>      more reliably and contrary to pxe-service should work also on IPv6.
>>
>>      I were not successful booting with ipxe.efi built you sent and
>>      pxe-service=*,X86-64_EFI,*. It just did not work on my Lenovo laptop
>>      or brother's Dell. I don't have more machines to test EFI. pcbios
>>      mode worked fine with menus, their support is enabled in ipxe bios
>>      builds by default.
>>
>>  >>
>>  >         Please do consider this if not already done so.
>>  >>
>>      I have had trouble with proxy mode and I am not sure what is its
>>      purpose. Do you know when proxy mode should be used? When is it
>>      required? It seems to be related to pxe-service, which I think does
>>      not work reliably on EFI. Should it be possible to offer PXEClient
>>      next-server and it would ask that server via pxe 4011 port? Do you
>>      need it somewhere in a real world?
>>
>>      Would this config work instead, without any pxe-service enabled?
>>
>>      # Specify the boot filename for each tag, relative to tftp-root.
>>      # If multiple lines with tags match, the last one is used.
>>      # See: https://www.syslinux.org/wiki/index.php?title=PXELINUX#UEFI
>>      <https://www.syslinux.org/wiki/index.php?title=PXELINUX#UEFI>
>>      dhcp-vendorclass=set:pxe,PXEClient
>>      dhcp-boot=tag:!rpi,tag:!ipxe-ok,tag:pxe,tag:X86PC,ltsp/undionly.kpxe
>>
>>  dhcp-boot=tag:!rpi,tag:!ipxe-ok,tag:pxe,tag:X86-64_EFI,ltsp/snponly.efi
>>      dhcp-boot=tag:!rpi,tag:ipxe-ok,ltsp/ltsp.ipxe
>>
>>      It does not rely on option 43 PXE menus support, just plain old DHCP
>>      boot file. Requires dnsmasq to be the (authoritative?) DHCP server
>>      on the network.
>>
>>      Hope that helps.
>>
>>      Cheers,
>>      Petr
>>
>>  >>
>>  >         Thanks,
>>  >         Shrenik
>>  >>
>>  >         On Sat, 9 Oct 2021 at 03:43, Petr Menšík <pemensik at redhat.com
>>  >         <mailto:pemensik at redhat.com>> wrote:
>>  >>
>>  >             I have made some attempts at PXE booting. I have to say,
>>  >             it is a mess.
>>  >>
>>  >             Put my booting attempts at fedorapeople [1]. I have asked
>>  >             on #ipxe IRC
>>  >             channel. It seems pxe-service works only on biospc,
>>  >             client-arch == 0. I
>>  >             were able to make simple menu on my father's lenovo
>>  >             desktop and my work
>>  >             Thinkpad 490s. One instance of Raspberry 3. In Legacy
>>  >             mode, it works
>>  >             somehow well. You are even to make local boot menu
>>  >             entries. I made it
>>  >             possible to boot to memtest just fine.
>>  >>
>>  >             However, any my attempt in EFI mode to boot using menus
>>  >             failed. There is
>>  >             special function pxe_uefi_workaround, but to me it did not
>>  >             work. Current
>>  >             code did never return reply from pxe port request. Because
>>  >             my laptop
>>  >             does not send option 43 stuff in ipxe.efi request and I
>>  >             have not used
>>  >             proxy, it just does not answer. I were able to make it
>>  >             return something.
>>  >             It seems not well supported and should be avoided.
>>  >>
>>  >             Guys at ipxe channel told me EFI does not include option
>>  >             43 menu
>>  >             support, which seems to be true. At that results, I think
>>  >             pxe-service
>>  >             should be in general avoided if you want to support EFI.
>>  >             Just use tags
>>  >             to offer first boot-file as ipxe.efi, then use ipxe script
>>  >             with possible
>>  >             menus inside. That seems to be more reliable and well
>>  >             documented way.
>>  >>
>>  >             I have fixed previous patch, it has to offer just based on
>>  >             boot item
>>  >             supplied type. Client arch is not always sent in a
>>  >             request, even when it
>>  >             is always present in discover, as I have noticed in
>>  >             Shrenik's dumps. I
>>  >             think that patch makes improvement and allows pxe-service
>>  >             work just for
>>  >             platforms related. Others should use dhcp-file with tags,
>>  >             depending on
>>  >             their clients.
>>  >>
>>  >             Custom setting of tags depending on option:client-arch
>>  >             seems to be more
>>  >             understandable and reliable.
>>  >>
>>  >             I have had enough of PXE today.
>>  >>
>>  >             Cheers,
>>  >             Petr
>>  >>
>>  >             1. https://pemensik.fedorapeople.org/dnsmasq/
>>  >             <https://pemensik.fedorapeople.org/dnsmasq/>
>>  >>
>>  >             On 10/7/21 23:10, Simon Kelley wrote:
>>  >             > As an aside the the discussion, can I just point out
>>  >             that I don't have
>>  >             > any way to test any of this dnsmasq functionality at the
>>  >             moment, and I'm
>>  >             > very rusty on the PXE spec, especially as it relates to
>> EFI.
>>  >             >
>>  >             > I don't therefore have much to contribute to this
>>  >             discussion, but I do
>>  >             > think this is valuable work, and when you find a
>>  >             solution, I'll give the
>>  >             > resulting patchset my full attention.
>>  >             >
>>  >             >
>>  >             > Cheers,
>>  >             >
>>  >             > Simon.
>>  >>
>>      --
>>      Petr Menšík
>>      Software Engineer
>>      Red Hat,http://www.redhat.com/  <http://www.redhat.com/>
>>      email:pemensik at redhat.com  <mailto:pemensik at redhat.com>
>>      PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20211016/a1e72fa3/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ltsp-dnsmasq-noproxy.conf
Type: application/octet-stream
Size: 3459 bytes
Desc: not available
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20211016/a1e72fa3/attachment-0001.obj>


More information about the Dnsmasq-discuss mailing list