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

Shrenik Bhura shrenik.bhura at gmail.com
Fri Oct 15 11:39:04 UTC 2021

Hey Petr,

You have nailed it. :)

Rpi + proxy success
Rpi + noproxy success
Efi + proxy success
Efi + noproxy success
BIOS + proxy success
BIOS + noproxy success


@Alkis Georgopoulos <alkisg at gmail.com> , @Jigish Gohil
<jigish.gohil at gmail.com> may give it a shot to reconfirm all scenario.


On Tue, 12 Oct, 2021, 09:58 Shrenik Bhura, <shrenik.bhura at gmail.com> wrote:

> 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,,proxy, takes care 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> 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>
>> 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 ) ?
>> 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
>> 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> 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/
>>>> 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/
>> email: pemensik at redhat.com
>> PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20211015/e56b7446/attachment-0001.htm>

More information about the Dnsmasq-discuss mailing list