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