<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">https://bbs.archlinux.org/viewtopic.php?id=237655</a>), we tried this custom configuration -</div><div><br><span style="font-family:monospace">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 style="font-family:monospace">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">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">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">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">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">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">http://www.redhat.com/</a><br>
email: <a href="mailto:pemensik@redhat.com" target="_blank">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">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">https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss</a><br>
</blockquote></div>