iPXE was stuck in a loop: boot iPXE -> DHCP -> get ipxe.0 again ->
boot iPXE -> repeat. Add tag:!ipxe to pxe-service directives so
iPXE clients get the HTTP script URL via dhcp-boot instead of being
served the bootloader again.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
dhcp-boot alone does not send PXE vendor extensions (option 43) that
PXE clients need in proxy DHCP mode. Switch to pxe-service directives
for initial PXE boot, keep dhcp-boot only for iPXE chainloading.
Create .0 symlinks for pxe-service filename convention. Restore
dhcp-ignore=tag:!known filtering.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
dnsmasq sees PXE requests but never responds. Remove the known-host
filter to determine if tag matching is the issue or if the problem
is elsewhere in the proxy DHCP flow.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Bare MACs in dhcp-hostsfile were not auto-setting the known tag in
proxy DHCP mode, causing dhcp-ignore=tag:!known to drop all requests.
Explicitly write set:known per host entry.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Remove tag:known filter from dhcp-range — in proxy DHCP mode the tag
filter prevents responses. dhcp-ignore=tag:!known still filters
unknown hosts. Also copy ipxe.efi and undionly.kpxe from the system
ipxe package into the TFTP root at startup so clients can actually
download the bootloader.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
dnsmasq exited with status 3 because the tftp-root directory didn't
exist at startup. Also replaced hardcoded 192.168.1.0 in dhcp-range
with the configured subnet value.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
josh