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

Alkis Georgopoulos alkisg at gmail.com
Wed Oct 6 14:46:32 UTC 2021

 > 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?

What would that involve?
Not answering in port 4011 for that client?
`ss -nap | grep 4011` shows that when "pxe-service" lines exist,
dnsmasq listens in that port, otherwise it doesn't.

Shrenik, I wonder, if you use iptables or a firewall to completely 
ignore packets to 4011, does the NUC client work then even if 
pxe-service lines exist?

(I may be complete off-base there, it's just an idea...)


On 10/6/21 8:37 AM, 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.

  > 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:
  >             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 &&
  >     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?

More information about the Dnsmasq-discuss mailing list