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

[Shrenik Bhura]

Hello Petr,

Thanks for your guidance.

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 (
https://bbs.archlinux.org/viewtopic.php?id=237655), we tried this custom
configuration -

pxe-prompt="Press any key for boot menu",2
pxe-service=X86-64_EFI,"PXELINUX (X86-64_EFI)",ltsp/snponly.efi
pxe-service=7,"PXELINUX (EFI)",ltsp/snponly.efi
dhcp-boot=tag:!iPXE,tag:X86PC,ltsp/undionly.kpxe
dhcp-boot=tag:!iPXE,tag:X86-64_EFI,ltsp/snponly.efi
dhcp-boot=tag:iPXE,ltsp/ltsp.ipxe

(full file attached below)

Server does proceed to offering ltsp.ipxe to the client via dhcp but is
eventually not being transferred via tftp.

Have attached logs, pcap and dnsmasq configuration of three scenarios -
1. Default dnsmasq config with default ltsp's pxe-service entries
2. Custom pxe-service entries
3. Without pxe-service entries

We have tested these with two systems - Intel NUC and Dell Optiplex 3040
with their updated firmware and have found the same results.

I hope this helps to zoom further into the problem area.

Best regards,
Shrenik




On Mon, 27 Sept 2021 at 17:00, Petr Menšík <pemensik at redhat.com> wrote:

> Hi Alkis,
>
> It would be helpful, if you could record pcap with those lines commented
> out and enabled. It seems suspicious dhcp-boot option is present at the
> same time with pxe-service. From what I undestood, pxe-service should
> offer boot options only to PXEClient vendor string. I think it saves you
> the need to dhcp-match=set:X86PC,option:client-arch,0
>
> then matched in
> dhcp-boot=tag:!iPXE,tag:X86PC,ltsp/undionly.kpxe
> dhcp-boot=tag:iPXE,tag:X86PC,ltsp/ltsp.ipxe
>
> I just checked my Raspberry 3. I guess architecture of RPi in DHCP
> request is clearly wrong. Unfortunately it reports it wrong also in
> vendorclass ARCH:0000.
>
> Anyway, it might not handle tags correctly. Around src/rfc2131.c:891, it
> searches for pxe service without using tags. It is not used to find
> correct service, just to find correct context.
>
> Also it seems if any pxe-service is defined and incoming DHCP packet
> contains PXEClient in VendorClass option, it MUST be handled by
> pxe-service. If no correct service & context is found, reply is not
> handled for it. It cannot fall back to normal DHCP reply in that case,
> which can be fixed. But current situation seems to me clear. If any
> pxe-service is present, all PXEClient packets has to be handled by it.
> It seems to me you define tags per arch anyway, so I guess you can avoid
> pxe-service just fine.
>
> I made an attempt to respond to PXE request only when correct service
> matches. But I have no setup prepared for it, I tested just it compiles.
> Could you try it would help?
>
> Cheers,
> Petr
>
> On 3/19/21 10:05, Alkis Georgopoulos wrote:
> > Hi all,
> >
> > I'm one of the LTSP developers; I asked Shrenik to contact the dnsmasq
> > mailing list because I feel this might be a dnsmasq issue.
> >
> > Specifically, success or failure depends on whether these five lines
> > are commented out or not:
> >
> > #pxe-service=tag:proxy,tag:!iPXE,X86PC,"undionly.kpxe",ltsp/undionly.kpxe
> >
> #pxe-service=tag:proxy,tag:!iPXE,X86-64_EFI,"snponly.efi",ltsp/snponly.efi
> >
> > #pxe-service=tag:proxy,tag:iPXE,X86PC,"ltsp.ipxe",ltsp/ltsp.ipxe
> > #pxe-service=tag:proxy,tag:iPXE,X86-64_EFI,"ltsp.ipxe",ltsp/ltsp.ipxe
> > #pxe-service=tag:rpi,X86PC,"Raspberry Pi Boot   ",unused
> >
> > You may find the full configuration files and logs at:
> > https://github.com/ltsp/ltsp/pull/417
> >
> > The reason I feel it might be a dnsmasq issue, is that these tags are
> > NOT matched in Shrenik's use case. He's not using proxy mode and he's
> > not booting a Raspberry Pi.
> >
> > So, "pxe-service" lines that are NOT matched, cause the problem,
> > yet if they're commented out, the problem is gone...
> >
> > Would that be an issue with dnsmasq, or with the UEFI PXE stack?
> >
> > Thanks,
> > Alkis Georgopoulos
> >
> > _______________________________________________
> > Dnsmasq-discuss mailing list
> > Dnsmasq-discuss at lists.thekelleys.org.uk
> > https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
> >
> --
> Petr Menšík
> Software Engineer
> Red Hat, http://www.redhat.com/
> email: pemensik at redhat.com
> PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20210927/7cd18248/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: without-pxe-service.tar.gz
Type: application/x-gzip
Size: 115888 bytes
Desc: not available
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20210927/7cd18248/attachment-0003.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: custom-pxeservice.tar.gz
Type: application/x-gzip
Size: 115479 bytes
Desc: not available
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20210927/7cd18248/attachment-0004.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: default-ltsp-with-pxeservice.tar.gz
Type: application/x-gzip
Size: 448442 bytes
Desc: not available
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20210927/7cd18248/attachment-0005.bin>