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

Petr Menšík pemensik at redhat.com
Mon Sep 27 17:26:10 UTC 2021


Hello,

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.

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.

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.

Cheers,
Petr

1.
https://www.ibm.com/docs/en/aix/7.2?topic=daemon-pxe-vendor-container-suboptions
2. https://ipxe.org/buildcfg/log_level

On 9/27/21 16:04, Shrenik Bhura wrote:
> 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
>
-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemensik at redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20210927/b3054e65/attachment.htm>


More information about the Dnsmasq-discuss mailing list