Force client to send DHCP options to next-server
You seem to be using ISC dhcpd
. From its dhcpd.conf(5)
man page:
next-server server-name;
The
next-server
statement is used to specify the host address of the server from which the initial boot file (specified in thefilename
statement) is to be loaded.Server-name
should be a numeric IP address or a domain name.
Note that the server name indicated by the next-server
statement is not another DHCP server. Classically it might be a TFTP server.
If your client first sends a DHCP request to one DHCP server, then to another, it means the client rejected the offer of the first server for some reason. According to DHCP protocol specifications, there is no way for a DHCP client to accept only parts of a DHCP offer; it's all or nothing.
Related videos on Youtube
![djuarez](https://i.stack.imgur.com/BlMRi.png?s=256&g=1)
Comments
-
djuarez almost 2 years
We currently have clients connecting to a DHCP server when asking for an IP. We then redirect to
next-server
with some additional options.The next server has a DNSMASQ running that should be able to get all sent options by the DHCP server.
With this current configuration for a specific machine (it does actually go through this condition):
if substring (option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00007" { # UEFI-64-1 # user-class has code 77 option user-class "test"; next-server nextserver.example; # We even tried forcing sending this option, as the client might not be asking for it: # 4d is 77 in hex option dhcp-parameter-request-list = concat(option dhcp-parameter-request-list,4d); }
When checking all traffic on the next server side we do not see this option at all. The same happens with other options such as
option vendor-class-identifier "PXEClient";
Is there anything I might be missing? It seems that the client just sends the starting options to DHCP server, then to
next-server
, without taking any of the specified options on the DHCP server configuration.EDIT:
dnsmasq
configurationbind-interfaces dhcp-option=vendor:PXEClient,6,2b dhcp-match=x86PC, option:client-arch, 0 dhcp-option-force=x86PC,211, 30 dhcp-match=BC_EFI, option:client-arch, 7 dhcp-match=X86-64_EFI, option:client-arch, 9 dhcp-match=AARCH64_EFI, option:client-arch, 11 # path refers to server address, this case it is local, as there is a separate tftp server serving these files from /tftpboot/ # Use the tag to differentiate loader pxe-service=tag:x86PClgcy,x86PC, "netboot x86PClgcy", /test/loader/lgcy/pxelinux pxe-service=tag:x86PC,x86PC, "netboot x86PC", /test/loader/bios/lpxelinux pxe-service=tag:BC_EFI,BC_EFI, "netboot BC-EFI", /test/loader/uefi/bootx64.efi pxe-service=tag:X86-64_EFI,X86-64_EFI, "netboot X86-64_EFI", /test/loader/uefi/bootx64.efi pxe-service=tag:AARCH64_EFI, 11, "netboot AARCH64_EFI", /test/loader/arm64/bootx64.efi # ONE pxe-service per tag:architecture only # for defined pxe-skip-menu=<CSA> # this requires patched version of dnsmasq pxe-skip-menu=x86PC pxe-skip-menu=BC_EFI pxe-skip-menu=X86-64_EFI pxe-skip-menu=11 # i.e. it delegates the main DHCP server to allocate the IP dhcp-range=10.0.0.0,proxy,255.0.0.0 dhcp-range=100.64.0.0,proxy,255.192.0.0 (...)
-
djuarez over 4 yearsAFAIU in this case, the DNSMASQ intercepts the request before delegating the TFTP server to provide the bootloader.