On 04.12.2024 18:13, Simon Glass wrote:

Hi Mikhail,

On Tue, 3 Dec 2024 at 16:27, Mikhail Kshevetskiy mikhail.kshevetskiy@iopsys.eu wrote:

...

timeout_count is never reset once a tftpboot transfer has started. If for whatever reason timeouts occur frequently, but the server keeps replying nonetheless, the transfer may be needlessly aborted.

Reset timer_count on every successful block to avoid this situation.

Signed-off-by: Mikhail Kshevetskiy mikhail.kshevetskiy@iopsys.eu

net/tftp.c | 2 ++ 1 file changed, 2 insertions(+)

What is the impact of this change?

If less than timeout_count_max issues appeared between arriving of two data blocks -- the transfer will be continued. This greatly increase chances to successfully download file if a lot of transfer timeout happens.

From the other side the transfer may becomes very slow (if timeouts will be

after each packet).

This may looks unrealistic, but we have a number of devices with Airoha chips (mips, mipsel, arm, aarch64) that sometimes acts like stated above (a timeout arises very often, but some packets flows normally). It's a rare issue, but sometimes happens :-( We don't know a reason yet.

...

diff --git a/net/tftp.c b/net/tftp.c index 704b20b4ff8..8f948204a6f 100644 --- a/net/tftp.c +++ b/net/tftp.c @@ -498,6 +498,7 @@ static void tftp_handler(uchar *pkt, unsigned dest, struct in_addr sip, tftp_state = STATE_DATA; tftp_remote_port = src; }

•                                   timeout_count = 0;
                                    tftp_send(); /* Send next data block */
                            }
                    }
  

@@ -657,6 +658,7 @@ static void tftp_handler(uchar *pkt, unsigned dest, struct in_addr sip, net_set_state(NETLOOP_FAIL); break; }

•           timeout_count = 0;
  
            if (len < tftp_block_size) {
                    tftp_send();
  

-- 2.45.2

Regards, Simon