<div dir="auto"><div dir="auto">Hey Petr,</div><div dir="auto"><br></div><div dir="auto">You have nailed it. :)</div><div dir="auto"><br></div><div dir="auto">Now:</div><div dir="auto">Rpi + proxy success</div><div dir="auto">Rpi + noproxy success</div><div dir="auto">Efi + proxy success</div><div dir="auto">Efi + noproxy success</div><div dir="auto">BIOS + proxy success</div><div dir="auto">BIOS + noproxy success</div><div dir="auto"><br></div>Thanks.<div dir="auto"><br></div><div dir="auto"><span class="gmail_chip gmail_plusreply" dir="auto"><a href="mailto:alkisg@gmail.com" style="color:#15c;text-decoration:underline">@Alkis Georgopoulos</a></span><span> , <span class="gmail_chip gmail_plusreply" dir="auto"><a href="mailto:jigish.gohil@gmail.com" style="color:#15c;text-decoration:underline">@Jigish Gohil</a></span><span> may give it a shot to reconfirm all scenario.</span></span></div><div dir="auto"><br><div data-smartmail="gmail_signature" dir="auto">Regards,<br>Shrenik</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 12 Oct, 2021, 09:58 Shrenik Bhura, <<a href="mailto:shrenik.bhura@gmail.com">shrenik.bhura@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thanks Petr for the detailed revert.<div><br></div><div>I shall try again with the pxe-services branch and revert with my test results.</div><div><br></div><div>Meanwhile I am trying to answer few of your queries -</div><div><br></div><div>> 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?<br></div><div><br></div><div>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 <font face="monospace">dhcp-range=set:proxy,192.168.2.0,proxy,255.255.255.0 </font>takes<span style="font-family:arial,sans-serif"> care of that. </span></div><div><span style="font-family:arial,sans-serif"><br></span></div><div><span style="font-family:arial,sans-serif">> </span>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.</div><br><div><span style="font-family:arial,sans-serif">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.</span></div><div><span style="font-family:arial,sans-serif"><br></span></div><div><span style="font-family:arial,sans-serif">Just to clarify further -</span></div><div><span style="font-family:arial,sans-serif">When I am testing dnsmasq in non-proxy mode I use ltsp-dnsmasq-noproxy.conf.</span></div><div><span style="font-family:arial,sans-serif">When I am testing dnsmasq in proxy mode I use ltsp-dnsmasq-proxy.conf.</span></div><div><span style="font-family:arial,sans-serif">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.</span></div><div><br></div><div><span style="font-family:arial,sans-serif">All the very best.</span><br></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">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>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>Okay, sorry for omitting others.<br>
</p>
<div>On 10/9/21 11:49, Shrenik Bhura wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>Adding Alkis and Jigish back to the thread via cc.<br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Sat, 9 Oct 2021 at 15:18,
Shrenik Bhura <<a href="mailto:shrenik.bhura@gmail.com" target="_blank" rel="noreferrer">shrenik.bhura@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote">
<div dir="ltr">
<div>Hey Petr,</div>
<div><br>
</div>
<div>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 ( <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>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
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.<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_quote">
<blockquote class="gmail_quote">
<div dir="ltr">
<div><br>
</div>
<div>Meanwhile, from a novice point of view and from what
I know works in dnsmasq, I have this query -</div>
<div><br>
</div>
<div>Could dnsmasq not be made to ignore the <span>pxe-service</span>
lines or bypass the corresponding logic from the
ltsp-dnsmasq.conf when <br>
</div>
<div>1. <span>is_tag_set("proxy") == "False" <span>i.e
ignore these lines -</span></span></div>
<div><span>pxe-service=tag:proxy,tag:!ipxe-ok,X86PC,"undionly.kpxe",ltsp/undionly.kpxe<br>
pxe-service=tag:proxy,tag:!ipxe-ok,X86-64_EFI,"snponly.efi",ltsp/snponly.efi<br>
pxe-service=tag:proxy,tag:ipxe-ok,X86PC,"ltsp.ipxe",ltsp/ltsp.ipxe<br>
pxe-service=tag:proxy,tag:ipxe-ok,X86-64_EFI,"ltsp.ipxe",ltsp/ltsp.ipxe</span></div>
</div>
</blockquote>
</div>
</div>
</blockquote>
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.<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_quote">
<blockquote class="gmail_quote">
<div dir="ltr">
<div><span></span></div>
<div><span><span><br>
</span></span></div>
<div><span><span>2. and when </span>is_tag_set("rpi") ==
"False" i.e. ignore this line or bypass corresponding
logic -</span></div>
<div><span>pxe-service=tag:rpi,X86PC,"Raspberry Pi Boot
",unused<br>
</span></div>
<div><span></span></div>
<div><span>when dnsmasq is processing a request in <i>non-proxy
mode</i> and the request is from <i>X86-64_EFI
clients</i>? <br>
</span></div>
</div>
</blockquote>
</div>
</div>
</blockquote>
<p>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.<br>
</p>
<p><span>pxe-service=tag:rpi,X86PC,"Raspberry Pi Boot ",0</span></p>
<p><span>Note other pxe-services should not match rpi tag, so only
above is offered to RPi.<br>
</span></p>
<p><span><span>pxe-service=tag:proxy,tag:!rpi,tag:!ipxe-ok,X86PC,"undionly.kpxe",ltsp/undionly.kpxe<br>
pxe-service=tag:proxy,</span></span><span><span><span><span>tag:!rpi,</span></span>tag:!ipxe-ok,X86-64_EFI,"snponly.efi",ltsp/snponly.efi<br>
pxe-service=tag:proxy,</span></span><span><span><span><span>tag:!rpi,</span></span>tag:ipxe-ok,X86PC,"ltsp.ipxe",ltsp/ltsp.ipxe<br>
pxe-service=tag:proxy,</span></span><span><span><span><span>tag:!rpi,</span></span>tag:ipxe-ok,X86-64_EFI,"ltsp.ipxe",ltsp/ltsp.ipxe</span></span></p>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_quote">
<blockquote class="gmail_quote">
<div dir="ltr">
<div><span><br>
</span></div>
<div><span>If possible, then everything would just work as
expected for all scenarios - <b>(BIOS or UEFI or RPI)
and proxy</b>, <b>(BIOS or UEFI or RPI) and
non-proxy</b>. <br>
</span></div>
<div><span>It may be possible to handle this just within
dnsmasq.<br>
</span></div>
</div>
</blockquote>
</div>
</div>
</blockquote>
<p>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.</p>
<p>I were not successful booting with ipxe.efi built you sent and
pxe-service=*<span>,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.<br>
</span></p>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_quote">
<blockquote class="gmail_quote">
<div dir="ltr">
<div><span><br>
</span></div>
<div><span>Please do consider this if not already done so.</span></div>
</div>
</blockquote>
</div>
</div>
</blockquote>
<p>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?<br>
</p>
<p>Would this config work instead, without any pxe-service enabled?<span></span></p>
<p><span># 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" target="_blank" rel="noreferrer">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</span></p>
<p><span>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.<br>
</span></p>
<p><span>Hope that helps.</span></p>
<p><span>Cheers,<br>
Petr<br>
</span></p>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_quote">
<blockquote class="gmail_quote">
<div dir="ltr">
<div><br>
</div>
<div>Thanks,<br>
</div>
<div>Shrenik<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">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>>
wrote:<br>
</div>
<blockquote class="gmail_quote">I have made some attempts
at PXE booting. I have to say, it is a mess.<br>
<br>
Put my booting attempts at fedorapeople [1]. I have
asked on #ipxe IRC<br>
channel. It seems pxe-service works only on biospc,
client-arch == 0. I<br>
were able to make simple menu on my father's lenovo
desktop and my work<br>
Thinkpad 490s. One instance of Raspberry 3. In Legacy
mode, it works<br>
somehow well. You are even to make local boot menu
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
failed. There is<br>
special function pxe_uefi_workaround, but to me it did
not work. Current<br>
code did never return reply from pxe port request.
Because my laptop<br>
does not send option 43 stuff in ipxe.efi request and I
have not used<br>
proxy, it just does not answer. I were able to make it
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
43 menu<br>
support, which seems to be true. At that results, I
think pxe-service<br>
should be in general avoided if you want to support EFI.
Just use tags<br>
to offer first boot-file as ipxe.efi, then use ipxe
script with possible<br>
menus inside. That seems to be more reliable and well
documented way.<br>
<br>
I have fixed previous patch, it has to offer just based
on boot item<br>
supplied type. Client arch is not always sent in a
request, even when it<br>
is always present in discover, as I have noticed in
Shrenik's dumps. I<br>
think that patch makes improvement and allows
pxe-service work just for<br>
platforms related. Others should use dhcp-file with
tags, depending on<br>
their clients.<br>
<br>
Custom setting of tags depending on option:client-arch
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>
<br>
On 10/7/21 23:10, Simon Kelley wrote:<br>
> As an aside the the discussion, can I just point
out that I don't have<br>
> any way to test any of this dnsmasq functionality
at the moment, and I'm<br>
> very rusty on the PXE spec, especially as it
relates to EFI.<br>
><br>
> I don't therefore have much to contribute to this
discussion, but I do<br>
> think this is valuable work, and when you find a
solution, I'll give the<br>
> resulting patchset my full attention.<br>
><br>
><br>
> Cheers,<br>
><br>
> Simon.<br>
</blockquote>
</div>
</blockquote>
</div>
</div>
</blockquote>
<pre cols="72">--
Petr Menšík
Software Engineer
Red Hat, <a href="http://www.redhat.com/" target="_blank" rel="noreferrer">http://www.redhat.com/</a>
email: <a href="mailto:pemensik@redhat.com" target="_blank" rel="noreferrer">pemensik@redhat.com</a>
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB</pre>
</div>
</blockquote></div>
</blockquote></div>