0

I’m setting up a PXE boot environment using a DHCP server and a Realtek RTL8168 NIC (bulit-in ethernet on my mainboard). I’ve configured DHCP Option 67 to send the boot file name (netboot.xyz.efi), but during the PXE boot process, the client is displaying the file name with a single weird character. This results in boot failure (file not found).

My PXE server is using tftpd-hpa/noble,now 5.2+20150808-1.4build1 amd64

I've verified that in the tftp root directory, netboot.xyz.efi existed (downloaded from netboot.xyz)

pxe error

dhcptest v0.7 - Created by Vladimir Panteleev https://github.com/CyberShadow/dhcptest Run with --help for a list of command-line options. Listening for DHCP replies on port 68. Sending packet: op=BOOTREQUEST chaddr=BD:2E:47:6A:89:7C hops=0 xid=8B6211E2 secs=0 flags=8000 ciaddr=0.0.0.0 yiaddr=0.0.0.0 siaddr=0.0.0.0 giaddr=0.0.0.0 sname= file= 1 options: 53 (DHCP Message Type): discover Received packet from 10.0.1.1:67: op=BOOTREPLY chaddr=BD:2E:47:6A:89:7C hops=0 xid=8B6211E2 secs=0 flags=8000 ciaddr=0.0.0.0 yiaddr=10.0.1.68 siaddr=0.0.0.0 giaddr=0.0.0.0 sname= file= 8 options: 53 (DHCP Message Type): offer 54 (Server Identifier): 10.0.1.1 51 (IP Address Lease Time): 60 (1 minute) 1 (Subnet Mask): 255.255.255.0 3 (Router Option): 10.0.1.1 6 (Domain Name Server Option): 1.1.1.1, 1.0.0.1 66 (TFTP server name): 10.0.1.5 67 (Bootfile name): netboot.xyz.efi

dhcp packet capture

Here is my router configuration, it is a Huawei HG8145V5-20 (modified firmware by ISP).

router dhcp config

Edit: This looks like a firmware bug. I give up.

Improve this question
7
  • I can't see an example of this single weird character in the question. If it's there somewhere (in the screenshot?), maybe you could make it easier to spot? Commented Apr 6 at 6:20
  • You're showing the contents of the DHCP Offer packet, which just proves your DHCP server sent the boot filename correctly. You should capture the TFTP request packet (UDP, destination port 69): that will contain the filename the PXE firmware actually asks for - that should show the "weird character". Commented Apr 6 at 9:56
  • @Kusalananda I added the screenshot showing that weird char. Commented Apr 7 at 12:17
  • @telcoM I can't really capture the TFTP request packet, my network only has this PC and a server, and I'm not that good with wireshark too. Commented Apr 7 at 12:17
  • @Choomai That base64-encoded value looks correct to me: echo 'bmV0Ym9vdC54eXouZWZp' | base64 -d | hexdump -C (it is the filename). Likewise, MTAuMC4xLjU= is the encoded IP address. Is it the fact that the values are base64-encoded that is the issue? Are those the weird characters that you mention? EDIT: sorry, I totally missed the photo that you added further up in the question. I can now see the character after the end of the filename. Commented Apr 7 at 12:37

1 Answer 1

Reset to default
0

I've seen a PXE firmware bug just like that.

Fortunately, specifying the boot file using legacy BOOTP-style "boot file name" option was enough to work around the bug in my case. You might want to try that too.

So, if you are using the ISC dhcpd, try using

filename "netboot.xyz.efi"

instead of

option bootfile-name "netboot.xyz.efi"

and see if it helps. In the dhcptest output, it should cause the filename to appear after file= instead as DHCP option 67.

Unfortunately it looks like your router's DHCP server does not allow you to configure it to send the boot filename in classic BOOTP-like format. And since the PXE firmware adds the extra character to whatever the DHCP option 67 contains, the problem is not fixable at the DHCP server end.

Fortunately you seem to be using the tftpd-hpa TFTP server: it could perhaps be configured to use a map file to discard the erroneous character.

If the output of /usr/sbin/in.tftpd -V (or whatever the actual pathname of your tftpd-hpa binary is) includes the words with remap, then you can proceed as follows:

Create a file e.g. /etc/tftpd.map with the following contents:

# Erase last character if non-printable (Realtek PXE firmware bug workaround) r (.*)[^0-9A-Za-z._-]$ \1

Note that this restricts the last character of legitimate TFTP-downloadable files: the last character must be a number, letter (lower-or uppercase A-Z), full stop, underscore or minus sign. If you need some other characters, add them to within the brackets, keeping the minus sign as the last character within brackets.

Then, add the option -m /etc/tftpd.map to the command line that starts the tftpd-hpa TFTP server. In Debian-like distributions, that can usually be achieved by editing the TFTP_OPTIONS= line in /etc/default/tftpd-hpa so that it becomes e.g.:

TFTP_OPTIONS="-vv -m /etc/tftpd.map --secure"

Then restart your TFTP service.

Now if the client's TFTP request has an extra unprintable character in the last position in the filename, the tftpd-hpa should automatically disregard the unprintable character and the deliver the expected file.

Improve this answer
7
  • I'm still trying to figure out what the "single weird character" is. Commented Apr 6 at 8:40
  • In my case, it was either ASCII 0x00 or ASCII 0xff appended to the filename, if I recall correctly. Basically the firmware made an off-by-one error in copying the filename from the DHCP offer into the TFTP request - and I think my old system that had the bug had a RTL8168 NIC too, so the OP's PXE firmware may be exactly the same as mine was. Commented Apr 6 at 9:56
  • @telcoM - what Kusalananda means is that there's no weird character in either the textual representation or the screenshot. No one is doubting that you've seen them in the past. Commented Apr 6 at 17:34
  • Do I need to host a DHCP server or I need to adjust something in my router DHCP ? Commented Apr 7 at 12:12
  • Neither; since you are using tftpd-hpa, you can configure it to ignore the weird character. See my edit above. Commented Apr 7 at 18:14

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.