[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2] tftp: roll-over block counter to prevent data packets tim

From: Daniel Kiper
Subject: Re: [PATCH v2] tftp: roll-over block counter to prevent data packets timeouts
Date: Thu, 10 Sep 2020 17:31:08 +0200
User-agent: NeoMutt/20170113 (1.7.2)

On Thu, Sep 10, 2020 at 05:17:57PM +0200, Javier Martinez Canillas wrote:
> Commit 781b3e5efc3 (tftp: Do not use priority queue) caused a regression
> when fetching files over TFTP whose size is bigger than 65535 * block size.
>   grub> linux /images/pxeboot/vmlinuz
>   grub> echo $?
>   0
>   grub> initrd /images/pxeboot/initrd.img
>   error: timeout reading '/images/pxeboot/initrd.img'.
>   grub> echo $?
>   28
> It is caused by the block number counter being a 16-bit field, which leads
> to a maximum file size of ((1 << 16) - 1) * block size. Because GRUB sets
> the block size to 1024 octets (by using the TFTP Blocksize Option from RFC
> 2348 [0]), the maximum file size that can be transferred is 67107840 bytes.
> The TFTP PROTOCOL (REVISION 2) RFC 1350 [1] does not mention what a client
> should do when a file size is bigger than the maximum, but most TFTP hosts
> support the block number counter to be rolled over. That is, acking a data
> packet with a block number of 0 is taken as if the 65356th block was acked.
> It was working before because the block counter roll-over was happening due
> an overflow. But that got fixed by the mentioned commit, which led to the
> regression when attempting to fetch files larger than the maximum size.
> To allow TFTP file transfers of unlimited size again, re-introduce a block
> counter roll-over so the data packets are acked preventing the timeouts.
> [0]:
> [1]:
> Fixes: 781b3e5efc3 (tftp: Do not use priority queue)
> Suggested-by: Peter Jones <>
> Signed-off-by: Javier Martinez Canillas <>

Reviewed-by: Daniel Kiper <>


reply via email to

[Prev in Thread] Current Thread [Next in Thread]