1

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 configuration

bind-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
(...)
2

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 the filename 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.

1
  • AFAIU in this case, the DNSMASQ intercepts the request before delegating the TFTP server to provide the bootloader.
    – djuarez
    Oct 7 '19 at 8:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.