TFTP hangs with fragmented IP packets

[Laurent Pinchart]

Hello,

I've banged my head a few days ago trying to debug an issue with a TFTP
transfer hanging in the middle.

I'm testing U-Boot 2022-rc5 on a Toradex Verdin i.MX8MP module (using
the verdin-imx8mp defconfig). My local network MTU is 1500 bytes, and
the board uses the EQoS ethernet controller.

The problem started occurring after rebuilding a kernel image. U-Boot
started transferring the image, and stopped in the middle, eventually
timing out. Capture network traffic showed that U-Boot was continuously
asking for retransmit of the same block, and eventually timed out.

U-Boot is configured with a default TFTP block size of 4096 bytes, which
results in the TFTP blocks being sent in one UDP packet split in three
IP packets. U-Boot is configured with IP fragmentation supprot enabled.
This works fine for all TFTP blocks until a paticular one in the middle
of the kernel image.

I've narrowed it down to a file of 1472 that can't be transferred at
all (I have attached the binary to this e-mail). Changing the value of
any of the last two bytes of the file allows transferring it correctly,
so I suspect a CRC issue, likely related to IP fragmentation. Lowering
the TFTP block size to avoid fragmentation works around the problem.

Arguably a TFTP block size of 4096 bytes should probably not be used
with a 1500 bytes MTU network, but I thought it would be useful to fix
the issue nonetheless.

I can test patches.

-- 
Regards,

Laurent Pinchart
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.bin
Type: application/octet-stream
Size: 1472 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20220329/736ee26c/attachment.bin>