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

Petr Menšík pemensik at redhat.com
Wed Oct 6 23:42:44 UTC 2021

Hi guys,

I configured something on my laptop and tried few requests with my
raspberry. I think I have found weird state. It checks only matching
dhcp-range context, not pxe-service, when adding PXE stuff to requests.
So I made it require also pxe-service. It seems it might do what you
have requested, at least on the first glance.

Patch #2 is just small tuning, unifying dhcp-boot and pxe-service way of
setting boot files. There is slight chance it might break something. In
that case, either dhcp-boot or pxe-service needs fixing.

Could you please try success with patched version? I made new COPR
builds [1] for Fedora, including these changes. But I think that is not
your distribution. Can you try local build? Pushed also to our fork [2].

1. https://copr.fedorainfracloud.org/coprs/pemensik/dnsmasq/

2. https://github.com/InfrastructureServices/dnsmasq/tree/pxe-services

On 10/6/21 07:37, Alkis Georgopoulos wrote:
> Hi all,
> I haven't been able to reproduce this issue with the hardware I have
> access to.
> I think the key question that Shrenik is asking is:
> 1) dnsmasq works fine with his NUC when he has no pxe-service lines in
> his config
> 2) When he adds pxe-service lines with tags that DO NOT match this
> client, it fails to boot
> ==> Is it possible for dnsmasq to behave like (1) when (2) happens?
> I.e. if pxe-service is not matched due to tags, to behave in the same
> way like if it wasn't there at all?
> Thank you,
> Alkis Georgopoulos
> On 10/5/21 9:05 PM, Petr Menšík wrote:
> I could not find any relevant difference between nuc-efi.pcapng and
> qemu-efi.pcapng responses. They seem very similar. Yet qemu continues
> with TFTP download and next step. Nuc does not react anyhow to boot
> offer. It seems to not download or start snponly.efi. It seems to me the
> answer lies only on its boot rom firmware. I just expect both used
> matching configuration and dnsmasq version.
>  From dnsmasq side, answer to DHCP discover and request contains
> expected value in expected format. Critical is any output of NUC when it
> receives the offer. Does it fail with any error code? Does it print any
> error? At least screenshot would be useful. It seems to me the problem
> is somewhere in its PXE implementation, which we cannot solve in
> dnsmasq. Because it even does not try to download and execute
> snponly.efi, even iPXE build with debug logs (which I am not sure how to
> enable btw) would not help.
> What kind machine it is? Does it have the latest bios firmware
> available? Would this machine boot at least snponly.efi if pxe-service
> were commented out? It seems similar to previous
> intel_nuc_efi_with_ltsp-pxeservice.pcapng file requests, but it does use
> proxyDHCP requests like the old one. How changed dnsmasq configuration
> to make this change? How does dnsmasq.conf look like for it?
> Option 43 suboption PXE discovery control (6) is different now. It seems
> not well received by PXE firmware this time. Used config file of dnsmasq
> is not attached this time, I can only guess. HW address is different,
> not sure how different is used machine.
> Was it this machine, which returned PXE-E21: Remote boot cancelled.?
> Returned control to LoadFile control seems suspicious. May it require
> non-efi image instead? If you can reach support for this machine, I
> think it might be reported to them. Especially about how PXE menu can
> specify Local Boot?
> I am afraid I don't know how to help now. If one machine can boot with
> the same setup that another cannot, it is up to you to find commonly
> working configuration.
> On 9/30/21 12:47, Shrenik Bhura wrote:
> > > 1. seems to have wrong pcap file or it does not use configuration
> attached in linked archive. It seems it offers
> > menu items from 2. archive with custom pxe-services.
> >>
> > Apologies, there was definitely some mistake.
> >>
> > We have applied the patch and tried with and without dhcp-no-override
> > but it still fails to boot. Herein are the pcap and the logs for this
> > case.
> >
> https://drive.google.com/file/d/1-GvsId99FC8f8B2I0YaTVuje5385u4LC/view?usp=sharing
> >>
> > Additionally, also included is the qemu pcap wherein it does boot
> > successfully.
> >>
> > On Wed, 29 Sept 2021 at 20:29, Petr Menšík <pemensik at redhat.com> wrote:
> >>
> >     It is somehow hard to guess described results for each
> >     configuration (1. 2. 3.). It is unclear to me, what you saw for
> >     each variant printed by the computer.
> >>
> >     1. seems to have wrong pcap file or it does not use configuration
> >     attached in linked archive. It seems it offers menu items from 2.
> >     archive with custom pxe-services.
> >>
> >     Option 43 Suboption: (9) PXE boot menu
> >         Length: 41
> >         boot menu:
> >
> 8000155058454c494e555820285838362d36345f4546492980010e5058454c494e555820…
> >             Type: Unknown (32768)
> >             Length: 21
> >             Description: PXELINUX (X86-64_EFI)
> >             Type: Unknown (32769)
> >             Length: 14
> >             Description: PXELINUX (EFI)
> >>
> >     Above is not present in config file presented for it, but in 2.
> >     Are you sure you have killed dnsmasq and started it again?
> >>
> >     I think it might be difference between pxe-service served file
> >     chosen via menuboot. I have noticed there are two way to specify
> >     file to boot in DHCP for IPv4. One is in fixed header and first
> >     try chosen from menu is in that. pxe-service options makes it to
> >     request direct query to DHCP server, marked proxyDHCP in
> >     wireshark. This proxy ACK is followed by TFTP.
> >>
> >     I used filter in wireshark: "dhcp or (!tftp.destination_file &&
> tftp)"
> >>
> >     However following DHCP offers boot file path ONLY in option 67
> >     value. Fixed header boot file is all zeroed. It seems to me this
> >     is the part the snponly.efi firmware does not understand. It does
> >     not try to use path in option, but may insist only on file. Since
> >     option #52 overload is not in packet, I guess dnsmasq should have
> >     used mess->file for path and not option 67. But rules of
> >     rfc2131.c:2476 are simple. If client have requested option 67, it
> >     should handle it as option 67. I guess it is bug in snponly.efi.
> >     Either it should not include option 67 between requested options
> >     or it should actually handle the option. Dnsmasq would offer boot
> >     path in both cases.
> >>
> >     Interesting enough, dnsmasq is inconsistent with itself. It
> >     behaves a bit different way in PXE proxy mode, where file header
> >     part is always used. In normal mode unless --dhcp-no-override is
> >     used, option is used if requested.
> >>
> >     Can you please try if dhcp-no-override option would fix your
> >     issues? I think it should behave the same way in both situations.
> >>
> >     I attached patch, which would set boot file on pxe-service the
> >     same way as dhcp-boot. It may require dhcp-no-override where it
> >     did not before. Could you please try it?
> >>

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: 0002-Send-boot-file-the-same-way-on-pxe-service-and-dhcp-.patch
Type: text/x-patch
Size: 3736 bytes
Desc: not available
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20211007/d846fe43/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Offer-PXE-services-to-if-tags-match.patch
Type: text/x-patch
Size: 11122 bytes
Desc: not available
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20211007/d846fe43/attachment-0003.bin>

More information about the Dnsmasq-discuss mailing list