TFTP hangs with fragmented IP packets
rfried.dev at gmail.com
Thu Mar 31 07:43:13 CEST 2022
On Tue, Mar 29, 2022 at 11:28 PM Laurent Pinchart
<laurent.pinchart at ideasonboard.com> wrote:
> 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.
> Laurent Pinchart
I will try to reproduce.
Thanks for reporting.
More information about the U-Boot