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

[Petr Menšík]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Allow-fallback-to-normal-DHCP-for-PXE-enabled-client.patch
Type: text/x-patch
Size: 6961 bytes
Desc: not available
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20210927/b33a8010/attachment-0001.bin>