[Dnsmasq-discuss] pxe-service entries in dnsmasq conf seem to fail non-proxy EFI boot
pemensik at redhat.com
Tue Oct 5 18:05:29 UTC 2021
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
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
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
> Additionally, also included is the qemu pcap wherein it does boot
> 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:
> 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?
Red Hat, http://www.redhat.com/
email: pemensik at redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Dnsmasq-discuss