<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hello,</p>
<p>I made a mistake when reading the code. You are right. The part I
mentioned is only affected on vendor-class information option 43,
only in DHCPREQUEST or DHCPINFORM. Which is not in request in pcap
you have sent.</p>
<p>It seems to me problem is somewhere on IPXE side in decoding
reply dnsmasq sent to it. I took a look at the second offer of
both without-pxe and default-ltsp. It seems the only difference is
in vendorclass information containing PXE menu. Without pxe
continues to TFTP, where default is stuck. The answer is on its
decoding side. Assignment got the same boot file successfully in
both configurations. I am afraid it would be problem at PXE
decoding client, which may not understand menu dnsmasq tried to
send.</p>
<p>According to option 43 decoding in wireshark, pxe suboptions look
well. Except suboption 9 boot menu. Type unknown 0x8000 does seem
weird, but should be just Vendor use according to IBM docs [1].
Why it did not do anything else should be answered by ipxe people.
It should continue after 2 seconds even without any action. Did it
display at least boot menu on that station? Did it show anything?
Are those machines with normal VGA output? Perhaps LOG_LEVEL in
PXE [2] might reveal true reason.</p>
<p>Cheers,<br>
Petr<br>
</p>
<p>1.
<a class="moz-txt-link-freetext" href="https://www.ibm.com/docs/en/aix/7.2?topic=daemon-pxe-vendor-container-suboptions">https://www.ibm.com/docs/en/aix/7.2?topic=daemon-pxe-vendor-container-suboptions</a><br>
2. <a class="moz-txt-link-freetext" href="https://ipxe.org/buildcfg/log_level">https://ipxe.org/buildcfg/log_level</a><br>
</p>
<div class="moz-cite-prefix">On 9/27/21 16:04, Shrenik Bhura wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CANKp9xfOV_ysmebu-Z+xDhevk_+PjyUni1yZw4jKzbZdxSUVMw@mail.gmail.com">
<div dir="ltr">
<div>Hello Petr,</div>
<div><br>
</div>
<div>Thanks for your guidance.</div>
<div><br>
</div>
<div>It does seem that dhcp-boot is being reached even when
pxe-service is successfully executed. Taking a hint from this
discussion on UEFI and PXE (<a
href="https://bbs.archlinux.org/viewtopic.php?id=237655"
moz-do-not-send="true" class="moz-txt-link-freetext">https://bbs.archlinux.org/viewtopic.php?id=237655</a>),
we tried this custom configuration -</div>
<div><br>
<span>pxe-prompt="Press any key for boot menu",2<br>
pxe-service=X86-64_EFI,"PXELINUX
(X86-64_EFI)",ltsp/snponly.efi<br>
pxe-service=7,"PXELINUX (EFI)",ltsp/snponly.efi</span></div>
<div><span>dhcp-boot=tag:!iPXE,tag:X86PC,ltsp/undionly.kpxe<br>
dhcp-boot=tag:!iPXE,tag:X86-64_EFI,ltsp/snponly.efi<br>
dhcp-boot=tag:iPXE,ltsp/ltsp.ipxe</span></div>
<div><br>
</div>
<div>(full file attached below)</div>
<div><br>
</div>
<div>Server does proceed to offering ltsp.ipxe to the client via
dhcp but is eventually not being transferred via tftp.<br>
</div>
<div><br>
</div>
<div>Have attached logs, pcap and dnsmasq configuration of three
scenarios -</div>
<div>1. Default dnsmasq config with default ltsp's pxe-service
entries<br>
</div>
<div>2. Custom pxe-service entries <br>
</div>
<div>3. Without pxe-service entries<br>
</div>
<div><br>
</div>
<div>We have tested these with two systems - Intel NUC and Dell
Optiplex 3040 with their updated firmware and have found the
same results. <br>
</div>
<div><br>
</div>
<div>I hope this helps to zoom further into the problem area. <br>
</div>
<div><br>
</div>
<div>Best regards,<br>
</div>
<div>Shrenik</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, 27 Sept 2021 at 17:00,
Petr Menšík <<a href="mailto:pemensik@redhat.com"
moz-do-not-send="true" class="moz-txt-link-freetext">pemensik@redhat.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote">Hi Alkis,<br>
<br>
It would be helpful, if you could record pcap with those lines
commented<br>
out and enabled. It seems suspicious dhcp-boot option is
present at the<br>
same time with pxe-service. From what I undestood, pxe-service
should<br>
offer boot options only to PXEClient vendor string. I think it
saves you<br>
the need to dhcp-match=set:X86PC,option:client-arch,0<br>
<br>
then matched in<br>
dhcp-boot=tag:!iPXE,tag:X86PC,ltsp/undionly.kpxe<br>
dhcp-boot=tag:iPXE,tag:X86PC,ltsp/ltsp.ipxe<br>
<br>
I just checked my Raspberry 3. I guess architecture of RPi in
DHCP<br>
request is clearly wrong. Unfortunately it reports it wrong
also in<br>
vendorclass ARCH:0000.<br>
<br>
Anyway, it might not handle tags correctly. Around
src/rfc2131.c:891, it<br>
searches for pxe service without using tags. It is not used to
find<br>
correct service, just to find correct context.<br>
<br>
Also it seems if any pxe-service is defined and incoming DHCP
packet<br>
contains PXEClient in VendorClass option, it MUST be handled
by<br>
pxe-service. If no correct service & context is found,
reply is not<br>
handled for it. It cannot fall back to normal DHCP reply in
that case,<br>
which can be fixed. But current situation seems to me clear.
If any<br>
pxe-service is present, all PXEClient packets has to be
handled by it.<br>
It seems to me you define tags per arch anyway, so I guess you
can avoid<br>
pxe-service just fine.<br>
<br>
I made an attempt to respond to PXE request only when correct
service<br>
matches. But I have no setup prepared for it, I tested just it
compiles.<br>
Could you try it would help?<br>
<br>
Cheers,<br>
Petr<br>
<br>
On 3/19/21 10:05, Alkis Georgopoulos wrote:<br>
> Hi all,<br>
><br>
> I'm one of the LTSP developers; I asked Shrenik to
contact the dnsmasq<br>
> mailing list because I feel this might be a dnsmasq
issue.<br>
><br>
> Specifically, success or failure depends on whether these
five lines<br>
> are commented out or not:<br>
><br>
>
#pxe-service=tag:proxy,tag:!iPXE,X86PC,"undionly.kpxe",ltsp/undionly.kpxe<br>
>
#pxe-service=tag:proxy,tag:!iPXE,X86-64_EFI,"snponly.efi",ltsp/snponly.efi<br>
><br>
>
#pxe-service=tag:proxy,tag:iPXE,X86PC,"ltsp.ipxe",ltsp/ltsp.ipxe<br>
>
#pxe-service=tag:proxy,tag:iPXE,X86-64_EFI,"ltsp.ipxe",ltsp/ltsp.ipxe<br>
> #pxe-service=tag:rpi,X86PC,"Raspberry Pi Boot ",unused<br>
><br>
> You may find the full configuration files and logs at:<br>
> <a href="https://github.com/ltsp/ltsp/pull/417"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://github.com/ltsp/ltsp/pull/417</a><br>
><br>
> The reason I feel it might be a dnsmasq issue, is that
these tags are<br>
> NOT matched in Shrenik's use case. He's not using proxy
mode and he's<br>
> not booting a Raspberry Pi.<br>
><br>
> So, "pxe-service" lines that are NOT matched, cause the
problem,<br>
> yet if they're commented out, the problem is gone...<br>
><br>
> Would that be an issue with dnsmasq, or with the UEFI PXE
stack?<br>
><br>
> Thanks,<br>
> Alkis Georgopoulos<br>
><br>
> _______________________________________________<br>
> Dnsmasq-discuss mailing list<br>
> <a href="mailto:Dnsmasq-discuss@lists.thekelleys.org.uk"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">Dnsmasq-discuss@lists.thekelleys.org.uk</a><br>
> <a
href="https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss</a><br>
><br>
-- <br>
Petr Menšík<br>
Software Engineer<br>
Red Hat, <a href="http://www.redhat.com/" rel="noreferrer"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">http://www.redhat.com/</a><br>
email: <a href="mailto:pemensik@redhat.com" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">pemensik@redhat.com</a><br>
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB<br>
_______________________________________________<br>
Dnsmasq-discuss mailing list<br>
<a href="mailto:Dnsmasq-discuss@lists.thekelleys.org.uk"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">Dnsmasq-discuss@lists.thekelleys.org.uk</a><br>
<a
href="https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss</a><br>
</blockquote>
</div>
</blockquote>
<pre class="moz-signature" cols="72">--
Petr Menšík
Software Engineer
Red Hat, <a class="moz-txt-link-freetext" href="http://www.redhat.com/">http://www.redhat.com/</a>
email: <a class="moz-txt-link-abbreviated" href="mailto:pemensik@redhat.com">pemensik@redhat.com</a>
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB</pre>
</body>
</html>