iPXE/tftp error - Extra chars in the RRQ

  • I have a number of machines that when I attempt to boot them via iPXE i get a weird error.

    I am seeing the error by doing a tcpdump on ports 67/68/69

    it is basically the following

    13:39:59.552719 IP <MACHINE IP>.<ephemeral port> > <TFTP SERVER IP>.tftp:  39 RRQ "ipxe.efiM-^?" octet tsize 0 blksize 1468

    I have seen a few other strings show up, but always similar to this.
    One machine was “fixed” by flashing the BIOS/Firmware to latest, but others no.
    I have also seen this on undionly.kpxe requests.

    Any help would be great.


  • Senior Developer

    @InfoOverload said in iPXE/tftp error - Extra chars in the RRQ:

    working through some of the troubleshooting/ I decided to look at the dhcpd.conf a little closer
    This is what I had - “broken”

    Great you figured this out! Not something I’d know from the top of my head and believe me I have done very extensive debugging and use of the Linux DHCP server.

    The difference between option bootfile-name and filename as far as I understand it, is that the later actually puts the filename into the answer body vs. the other one adds it as a option later in the DHCP packet. Take a look at the DHCP packets in wireshark and you’ll understand what I mean.

    Why some NICs handle the DHCP option properly while other do not - I don’t know. It would be interesting to see if the DHCP server actually sends those malformed names or if it’s the NICs miss-reading it. I suppose it’s some kind of missing “end of string” character that makes some NICs read beyond the actual filename in the DHCP option… just guessing here.

    Upload a PCAP and we can figure this out. 🙂

  • Moderator

    @InfoOverload Interesting because FOG’s wiki uses the file name keyword: https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence#Example_1

    When you select yes to have FOG install the ISC dhcp server the config file is very similar to example #1. I wanted to double check to make sure the keywords on the wiki page were correct.

    Also the pcap should have shown the extra characters too. It would be in the dhcp server OFFER packet. That would have told us to focus on the dhcp server vs the target computer. I have seen certain dhcp servers send out a field byte count without a proper end text character which causes the PXE roms fits before.

    Its great you have it worked out though.

  • As I stated, I have seen it on both uefi AND BIOS (legacy) machines, but not ALL of either type.
    It seemed more prevalent with Realtek chipsets, but also seen on Intel and nVidia.

    I found another post in here that listed something similar for the extra chars

    working through some of the troubleshooting/ I decided to look at the dhcpd.conf a little closer
    This is what I had - “broken”

    if option arch = 00:06 {
        option bootfile-name "i386-efi/ipxe.efi";
    } else if option arch = 00:07 {
        option bootfile-name "ipxe.efi";
    } else {
        option bootfile-name "undionly.kpxe";

    I changed it to this

    if option arch = 00:06 {
        filename "i386-efi/ipxe.efi";
    } else if option arch = 00:07 {
        filename "ipxe.efi";
    } else {
        filename "undionly.kpxe";

    And the errors seem to have gone away

    so it seems to be VERY important as to which key word is in your dhcpd.conf

  • Moderator

    @InfoOverload Is it only specific machines or all uefi machines?

    If you could grab a pcap using this process: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

    Then upload the pcap to a file share site and post the link here, I’d like to take a look at it. We can get the most detailed information when the FOG server and pxe booting client are on the same subnet.