Feature Request: Option to suppress 'tsize' in OACK (workaround for buggy UEFI PXE clients)

[aktive]

Hi Dmitri,

First off, thanks for pin/tftp - it's been great for building a PXE boot server. We're using it to serve iPXE binaries (~1.1MB) to UEFI clients during network boot.

We've hit a specific issue with UEFI firmware TFTP implementations (Aptio V/AMI) that we're hoping you might have insight on.

Environment

• Library: pin/tftp v3.1.0
• Clients: Multiple UEFI clients (Gigabyte Aero 15XV8 Laptop/Aptio 2019, Lenovo m715q-1, brand new ASUS Prime B760M-A AX LGA 1700 w BIOS Ver / Date: 1812 x64 / 01/21/2025) - all exhibit identical behavior.

The Issue

UEFI TFTP clients send an RRQ with tsize=0 and blksize=1468.

1. If the server responds with an OACK containing tsize=<actual_size>, the client immediately sends ERROR code 8 ("User aborted") and disconnects.
2. The client then retries the request without the tsize option.
3. The server responds with an OACK (only blksize), and the transfer succeeds.

It appears these UEFI stacks request tsize but panic/crash if they actually receive it (perhaps due to buffer allocation logic in the firmware).

Workaround Attempts

1. Wrapped Reader: We wrapped our file in a struct that hides io.Seeker (exposing only io.Reader). We expected this to cause the library to omit tsize.
   • Result: The OACK correctly omitted tsize, but the client failed with "NBP filesize is 0 bytes" and did not retry. It seems these clients interpret "no tsize response to a tsize request" as "0 bytes".
2. Current Solution: We are currently accepting the "Fail-then-Retry" behavior. It works, but the initial failure creates noise in our error logs (WARN) and adds a ~1-2s delay to the boot process.

Investigation

I noticed in sender.go that tsize is automatically added to the options if the Reader implements Size() or Seek().

Feature Request

Would it be possible to add a hook or option to explicitly suppress tsize from the OACK, even if the Reader supports it?

Something like:

rf.(tftp.OutgoingTransfer).SuppressTSize()

This would allow servers to negotiate blksize (for speed) while hiding tsize (to prevent UEFI crashes) without breaking the Reader interface needed for efficient retransmits.

Packet Capture Evidence

Request 1 (Fail):

Client: RRQ "file.efi" tsize=0 blksize=1468
Server: OACK tsize=1125376 blksize=1468
Client: ERROR code=8 (User Aborted)

Request 2 (Success):

Client: RRQ "file.efi" blksize=1468
Server: OACK blksize=1468
Client: ACK (Transfer begins)

Happy to provide packet captures or test builds if needed. Thanks for your time!

[pin]

Apology for slow response and thank you for the kind words.

Please when you have a chance, could you help me to understand why SuppressTSize feature will work when no-io.Seeker workaround didn't?

Unless I'm missing something, the effect of SuppressTSize option should be exactly the same as no-io.Seeker? We do not set tsize and completely drop it from OACK.

One clue from https://forum.tranquil.it/en/viewtopic.php?t=2977 is:

after investigation we found an issue in the TFTP server response where the tsize variable in the TFTP response has an extra null character (\0), which can cause problems for some TFTP clients. We are currently fixing and validating the fix. We found an internal laptop exhibiting the same behavior as yours, so we can reproduce the issue and validate the fix.

The TFTP library itself should not add any null characters or garbage to tsize, but the sender sets the tsize option only if RRQ comes with 0 (or anything that yelds 0 from parseInt).

I'm just trying to find the explanation why no-io.Seeker workaround caused NBP filesize is 0 bytes. I'm worrying that adding SuppressTSize will just yeld the same result.

I understand that SuppressTSize might be more efficient and convenient rather than wrap io.Reader but I don't understand how it will solve the fail-retry-success issue.

[aktive]

Hi Dmitri, thanks for the response and sorry for the late follow-up. Took the time to verify this on the wire properly and it turns out this isn't a bug at all.

Setup: TFTP server (pin/tftp v3.1.0) serving UEFI bootloaders to PXE and iPXE clients on the same devices mentioned above.

tcpdump:

1. Client -> Server:69     RRQ "shimx64.efi" octet tsize=0 blksize=1468
2. Server:50692 -> Client  OACK tsize=966768 blksize=1468
3. Client -> Server:50692  ERROR code=8 "User aborted the transfer"
4. Client -> Server:69     RRQ "shimx64.efi" octet blksize=1468  (no tsize)
5. Server:52466 -> Client  OACK blksize=1468
6. Client -> Server:52466  ACK block=0
7. Server -> Client        DATA block=1 ...

This is the UEFI PXE boot sequence working as designed. The UEFI spec defines two separate, sequential TFTP operations: EFI_PXE_BASE_CODE_TFTP_GET_FILE_SIZE (size probe) and EFI_PXE_BASE_CODE_TFTP_READ_FILE (payload download).

In the EDK II reference implementation (NetworkPkg/UefiPxeBcDxe/PxeBcMtftp.c), PxeBcTftpGetFileSize() sends the RRQ with tsize=0, and its GetInfo callback always returns EFI_ABORTED after extracting the size from OACK. This triggers error code 8 (EFI_MTFTP4_ERRORCODE_REQUEST_DENIED). Then PxeBcLoadBootFile() allocates a buffer of the correct size and calls the real download.

RFC 2349 defines this behavior: tsize=0 in a Read Request is a size query, and the client may abort after receiving the OACK.

I verified suppressing tsize too: hid io.Seeker and skipped SetSize() so the OACK only contained blksize. You predicted this correctly: firmware shows "NBP filesize is 0 Bytes" and fails (PXE-E53). So the size probe is required and the ~17ms round-trip is negligible.

So a good outcome! your library is behaving correctly, and I learned way more about the spec than I originally wanted to :) I'll document it clearly for others: The "error" is actually a normal size probe that every EDK II-based firmware performs (which is nearly all UEFI implementations).

One thought, your library could treat error code 8 on OACK as non-fatal (since it's part of the UEFI TFTP handshake), but that's purely cosmetic.

Thanks again Dmitri, your library has been rock solid across thousands of PXE boots.