dnsmasq responds to pxe client's discover message, but does not send boot file
-
I am setting up a FOG 1.5.10 server on a fresh installation of Debian 13.5. There is an existing DHCP server which I am not allowed to mess with, so I am trying to use DNSmasq to handle the PXEBoot requests.
I have sysprepped a machine for capturing an image, and when I watch what I think is the relevant traffic withtcpdump -i eno1 -v port 67 or 68on the server, and try to PXE boot the client, I can see the client’s request, which does ask for a boot file (parameter 67), and the server’s response, which does not include a boot file, just four handshake-y paramaters (DHCP-Message, Server-ID, Vendor-Class, and GUID).
I have included my dnsmasq config file below. (Based on the guides in the documentation, although I have tried with several iterations.)
I cannot figure out why the server will not send a boot file. Is there something obvious I’m missing? Is it possibly something to do with the existing DHCP server? The server and the client are on the same subnet, and can, e.g. ping each other successfully, independent of dnsmasq.Thank you for any help you can provide.
dhcp-range=<my server's static ip>,proxy # Don't function as a DNS server: port=0 # Log lots of extra information about DHCP transactions. log-dhcp # Set the root directory for files available via FTP. tftp-root=/tftpboot # The default boot filename (BIOS / legacy), Server name, Server Ip Address dhcp-boot=ipxe.efi,,<my server's static ip> # Disable re-use of the DHCP servername and filename fields as extra # option space. That's to avoid confusing some old or broken DHCP clients. dhcp-no-override # inspect the vendor class string and match the text to set the tag dhcp-vendorclass=BIOS,PXEClient:Arch:00000 dhcp-vendorclass=UEFI32,PXEClient:Arch:00006 dhcp-vendorclass=UEFI,PXEClient:Arch:00007 dhcp-vendorclass=UEFI64,PXEClient:Arch:00009 # PXE menu. The first part is the text displayed to the user. # The second is the timeout, in seconds. pxe-prompt="Booting FOG Client", 3 # The known types are x86PC, PC98, IA64_EFI, Alpha, Arc_x86, # Intel_Lean_Client, IA32_EFI, BC_EFI, Xscale_EFI and X86-64_EFI # This option is first and will be the default if there is no input from the user. pxe-service=X86PC, "Boot to FOG", undionly.kkpxe pxe-service=X86-64_EFI, "Boot to FOG UEFI", ipxe.efi pxe-service=BC_EFI, "Boot to FOG UEFI PXE-BC", snponly.efi``` -
Hi @efbCREED — a couple of things are going on here, and the good news is the behavior you’re seeing may not be broken at all.
First, your capture is filtering out where the boot filename actually lives.
Because you’re using pxe-service= menu entries in proxy mode, dnsmasq does the handoff in two steps:
- The initial ProxyDHCP offer on port 67 carries the PXE menu (in the vendor-encapsulated options) and a boot-server list — it deliberately does not include the boot filename (option 67). That’s exactly the “four handshake-y parameters” you’re seeing.
- The client then sends a Boot Server Discover and the actual filename comes back on UDP port 4011.
Your filter was port 67 or 68, so it never captured 4011 — which is very likely where the file is (or should be) going. Re-run with:
tcpdump -i eno1 -v port 67 or port 68 or port 4011
That will tell us whether the filename is being served on 4011 and the client just isn’t completing the exchange, or whether it never gets there.
Second, I’d simplify the config. Your file mixes two different handoff mechanisms (dhcp-boot and pxe-service), and the four dhcp-vendorclass lines you defined are never actually referenced — the pxe-service lines use dnsmasq’s built-in arch keywords instead, so those vendorclass lines aren’t doing anything.
The config we recommend for proxyDHCP drops the menu approach and matches on architecture directly. This puts the correct filename right in the port-67 offer (so it’s trivial to verify with the tcpdump you’re already running) and chains iPXE → FOG’s boot.php once iPXE is loaded:
# /etc/dnsmasq.d/ltsp.conf (adjust <server-ip> throughout) port=0 log-dhcp tftp-root=/tftpboot dhcp-range=<server-ip>,proxy dhcp-no-override # Detect the client's PXE architecture (DHCP option 93) dhcp-match=set:bios,option:client-arch,0 dhcp-match=set:efi32,option:client-arch,6 dhcp-match=set:efibc,option:client-arch,7 dhcp-match=set:efi64,option:client-arch,9 # Detect when iPXE itself is asking (DHCP option 175) dhcp-match=set:ipxe,175 # Serve the right network boot program per architecture dhcp-boot=tag:bios,undionly.kpxe,,<server-ip> dhcp-boot=tag:efi32,ipxe.efi,,<server-ip> dhcp-boot=tag:efibc,ipxe.efi,,<server-ip> dhcp-boot=tag:efi64,ipxe.efi,,<server-ip> # Once iPXE is running, hand off to FOG dhcp-boot=tag:ipxe,http://<server-ip>/fog/service/ipxe/boot.phpA few notes:
- Use undionly.kpxe for BIOS, not .kkpxe. The kk variant is only needed on the handful of older NICs that need the UNDI stack kept resident — undionly.kpxe is the right default.
- The tag:ipxe line must come after the per-arch lines. dnsmasq applies the later match, so this ensures a machine that’s already running iPXE gets sent to boot.php instead of being handed the .efi again (which would loop).
- Make sure those files actually exist under /tftpboot (undionly.kpxe, ipxe.efi) — they ship with FOG, but worth confirming.
After you drop this in, restart dnsmasq and PXE-boot a client with the tcpdump above running. You should now see the filename land in the port-67 offer for the client’s architecture. If you still get nothing, paste that full capture (67/68/4011) here and we’ll take it from there.
Which firmware is the client — legacy BIOS or UEFI? That narrows down which line above should be firing.
-
Hi @Tom-Elliott – thank you for your help! The client is UEFI.
I probably should have mentioned that the main symptom I’m trying to figure out is the client giving up with PXE-E16: No valid offer received after a few minutes of trying PXE boot.
Interestingly, when I tried also listening to port 4011 with my initial config file, there was no additional traffic being picked up.
When I used the version you suggested (with the server’s IP switched in of course), the tcpdump actually no longer shows any responses to the client’s requests, and the PXE boot errors out faster with PXE-E18: Server response timeout.
tcpdump: listening on eno1, link-type EN10MB (Ethernet), snapshot length 262144 bytes 16:08:07.096920 IP (tos 0x0, ttl 64, id 29391, offset 0, flags [none], proto UDP (17), length 375) 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from <client’s mac address>(oui Unknown), length 347, xid 0x92c2c13c, Flags [Broadcast] Client-Ethernet-Address <client’s mac address>(oui Unknown) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message (53), length 1: Discover MSZ (57), length 2: 1472 Parameter-Request (55), length 35: Subnet-Mask (1), Time-Zone (2), Default-Gateway (3), Time-Server (4) IEN-Name-Server (5), Domain-Name-Server (6), Hostname (12), BS (13) Domain-Name (15), RP (17), EP (18), RSZ (22) TTL (23), BR (28), YD (40), YS (41) NTP (42), Vendor-Option (43), Requested-IP (50), Lease-Time (51) Server-ID (54), RN (58), RB (59), Vendor-Class (60) TFTP (66), BF (67), GUID (97), Unknown (128) Unknown (129), Unknown (130), Unknown (131), Unknown (132) Unknown (133), Unknown (134), Unknown (135) GUID (97), length 17: 0.128.226.9.231.152.246.237.17.132.7.227.255.61.233.42.0 NDI (94), length 3: 1.3.16 ARCH (93), length 2: 7 Vendor-Class (60), length 32: "PXEClient:Arch:00007:UNDI:003016" 16:08:10.881261 IP (tos 0x0, ttl 64, id 29392, offset 0, flags [none], proto UDP (17), length 375) 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from <client’s mac address>(oui Unknown), length 347, xid 0x92c2c13c, secs 4, Flags [Broadcast] Client-Ethernet-Address <client’s mac address>(oui Unknown) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message (53), length 1: Discover MSZ (57), length 2: 1472 Parameter-Request (55), length 35: Subnet-Mask (1), Time-Zone (2), Default-Gateway (3), Time-Server (4) IEN-Name-Server (5), Domain-Name-Server (6), Hostname (12), BS (13) Domain-Name (15), RP (17), EP (18), RSZ (22) TTL (23), BR (28), YD (40), YS (41) NTP (42), Vendor-Option (43), Requested-IP (50), Lease-Time (51) Server-ID (54), RN (58), RB (59), Vendor-Class (60) TFTP (66), BF (67), GUID (97), Unknown (128) Unknown (129), Unknown (130), Unknown (131), Unknown (132) Unknown (133), Unknown (134), Unknown (135) GUID (97), length 17: 0.128.226.9.231.152.246.237.17.132.7.227.255.61.233.42.0 NDI (94), length 3: 1.3.16 ARCH (93), length 2: 7 Vendor-Class (60), length 32: "PXEClient:Arch:00007:UNDI:003016" 16:08:18.968033 IP (tos 0x0, ttl 64, id 29393, offset 0, flags [none], proto UDP (17), length 375) 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from <client’s mac address>(oui Unknown), length 347, xid 0x92c2c13c, secs 12, Flags [Broadcast] Client-Ethernet-Address <client’s mac address>(oui Unknown) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message (53), length 1: Discover MSZ (57), length 2: 1472 Parameter-Request (55), length 35: Subnet-Mask (1), Time-Zone (2), Default-Gateway (3), Time-Server (4) IEN-Name-Server (5), Domain-Name-Server (6), Hostname (12), BS (13) Domain-Name (15), RP (17), EP (18), RSZ (22) TTL (23), BR (28), YD (40), YS (41) NTP (42), Vendor-Option (43), Requested-IP (50), Lease-Time (51) Server-ID (54), RN (58), RB (59), Vendor-Class (60) TFTP (66), BF (67), GUID (97), Unknown (128) Unknown (129), Unknown (130), Unknown (131), Unknown (132) Unknown (133), Unknown (134), Unknown (135) GUID (97), length 17: 0.128.226.9.231.152.246.237.17.132.7.227.255.61.233.42.0 NDI (94), length 3: 1.3.16 ARCH (93), length 2: 7 Vendor-Class (60), length 32: "PXEClient:Arch:00007:UNDI:003016" 16:08:35.140038 IP (tos 0x0, ttl 64, id 29394, offset 0, flags [none], proto UDP (17), length 375) 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from <client’s mac address>(oui Unknown), length 347, xid 0x92c2c13c, secs 28, Flags [Broadcast] Client-Ethernet-Address <client’s mac address>(oui Unknown) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message (53), length 1: Discover MSZ (57), length 2: 1472 Parameter-Request (55), length 35: Subnet-Mask (1), Time-Zone (2), Default-Gateway (3), Time-Server (4) IEN-Name-Server (5), Domain-Name-Server (6), Hostname (12), BS (13) Domain-Name (15), RP (17), EP (18), RSZ (22) TTL (23), BR (28), YD (40), YS (41) NTP (42), Vendor-Option (43), Requested-IP (50), Lease-Time (51) Server-ID (54), RN (58), RB (59), Vendor-Class (60) TFTP (66), BF (67), GUID (97), Unknown (128) Unknown (129), Unknown (130), Unknown (131), Unknown (132) Unknown (133), Unknown (134), Unknown (135) GUID (97), length 17: 0.128.226.9.231.152.246.237.17.132.7.227.255.61.233.42.0 NDI (94), length 3: 1.3.16 ARCH (93), length 2: 7 Vendor-Class (60), length 32: "PXEClient:Arch:00007:UNDI:003016" ^C 4 packets captured 4 packets received by filter 0 packets dropped by kernelIn case it is informative, my initial config file yields a few cycles of
cpdump: listening on eno1, link-type EN10MB (Ethernet), snapshot length 262144 bytes 16:25:14.333731 IP (tos 0x0, ttl 64, id 3165, offset 0, flags [none], proto UDP (17), length 375) 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from <client’s mac address>(oui Unknown), length 347, xid 0xf2335aca, Flags [Broadcast] Client-Ethernet-Address <client’s mac address>(oui Unknown) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message (53), length 1: Discover MSZ (57), length 2: 1472 Parameter-Request (55), length 35: Subnet-Mask (1), Time-Zone (2), Default-Gateway (3), Time-Server (4) IEN-Name-Server (5), Domain-Name-Server (6), Hostname (12), BS (13) Domain-Name (15), RP (17), EP (18), RSZ (22) TTL (23), BR (28), YD (40), YS (41) NTP (42), Vendor-Option (43), Requested-IP (50), Lease-Time (51) Server-ID (54), RN (58), RB (59), Vendor-Class (60) TFTP (66), BF (67), GUID (97), Unknown (128) Unknown (129), Unknown (130), Unknown (131), Unknown (132) Unknown (133), Unknown (134), Unknown (135) GUID (97), length 17: 0.128.226.9.231.152.246.237.17.132.7.227.255.61.233.42.0 NDI (94), length 3: 1.3.16 ARCH (93), length 2: 7 Vendor-Class (60), length 32: "PXEClient:Arch:00007:UNDI:003016" 16:25:14.334222 IP (tos 0xc0, ttl 64, id 43055, offset 0, flags [none], proto UDP (17), length 328) CREEDfog.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 300, xid 0xf2335aca, Flags [Broadcast] Server-IP CREEDfog Client-Ethernet-Address <client’s mac address>(oui Unknown) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message (53), length 1: Offer Server-ID (54), length 4: CREEDfog Vendor-Class (60), length 9: "PXEClient" GUID (97), length 17: 0.128.226.9.231.152.246.237.17.132.7.227.255.61.233.42.0
