Option 66 - Null Character Provided by dnsmasq

[Lux4rd0]

Running Pi-hole Version v5.0 Web Interface Version v5.0 FTL Version v5.0 on CentOS 7.

Expected Behaviour:

Expecting options for:

Bootfile Name and TFTP Server Name to only return the expected values.

I've created a new file that contains these options:

dhcp-option=66,"10.10.3.2"
dhcp-boot=pxelinux.0,10.10.3.2

under /etc/dnsmasq.d and it loads correctly. I've verified that there are no additional characters at the end of the lines or file.

Actual Behaviour:

However - what is being returned has an extra null character \x00 being returned to the DHCP clients, which is causing PXE booting not to happen:

| broadcast-dhcp-discover: 
|   Response 1 of 1: 
|     IP Offered: 10.10.30.30
|     DHCP Message Type: DHCPOFFER
|     Server Identifier: 10.10.3.80
|     IP Address Lease Time: 2m00s
|     Bootfile Name: pxelinux.0\x00
|     Renewal Time Value: 1m00s
|     Rebinding Time Value: 1m45s
|     Subnet Mask: 255.255.192.0
|     Broadcast Address: 10.10.63.255
|     Domain Name: tylephony.com
|     TFTP Server Name: 10.10.3.2\x00
|     Domain Name Server: 10.10.3.80, 10.10.3.81
|_    Router: 10.10.0.1

The Bootfile Name and TFTP Server name should not have the \x00 at the end of the line.

I'm using the nmap command to test:

nmap -n -sU -p67 --script broadcast-dhcp-discover

Debug Token:

https://tricorder.pi-hole.net/23xr1kxlo6

Thanks!

[Bucking_Horn]

If this would be a bug (which I suggest it isn't), you would have to address this with dnsmasq development, as Pi-hole is embedding dnsmasq as DHCP server.

RFC 951 section 3 (Packet Format) requires the boot file name (as provided by option dhcp-boot) to be a null terminated string.

RFC 2132 section 9.4 ff.(TFTP server name and Bootfile name) define the respective parameters as a string of characters.
RFC 2132 section 2 (BOOTP Extension/DHCP Option Field Format) allows usage of null terminated strings and further obligates clients to be able to deal with strings regardless if they are null terminated or not.

As far as RFCs are concerned, your observation doesn't constitue a bug.

It may indicate a failure of your client to conform to RFC 2132's requirement to corrrectly handle null terminated strings.
But since these are proven and well-known protocols, I suspect a configuration error to be behind this.

As you seem to use a separate DHCP/BOOTP server at 10.10.3.2 to enable PXE booting, you want to make sure that is reachable at boot time and that a proper pxelinux.0 file is indeed located in that machine's root directory.

[Lux4rd0]

Appreciate the insights and thoroughness of your response. After spending hours trying to get validation that the new configs were being sent out via dnsmasq - my PXE boot still isn't happening successful. I'll continue with the premise that null characters for those two options should be handled appropriately by the clients and chase other configurations to resolve my issues.

regardless if they are null terminated or not

Thanks again!!