From mboxrd@z Thu Jan 1 00:00:00 1970 From: Suneel Garapati Date: Sat, 30 Jan 2021 12:39:27 -0800 Subject: [PATCH v5] net: tftp: Add client support for RFC 7440 In-Reply-To: <20200805202724.GY6965@bill-the-cat> References: <20200718203146.317254-1-rfried.dev@gmail.com> <20200805202724.GY6965@bill-the-cat> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hello Ramon, With TFTP window size as default 1 and enabling TFTPPUT config option results in tftpboot command failure. Attached the pcap files for with and without TFTPPUT enabled. Both captures are the same except that the TFTPPUT option enables ICMP handler and for the response from the server triggers a restart of netloop operation and eventually fails as below. > tftpboot 0x30000000 192.168.1.1:Image Waiting for RPM0 LMAC0 link status... 10G_R [10G] Using rvu_pf#0 device TFTP from server 192.168.1.1; our IP address is 192.168.1.16 Filename 'Image'. Load address: 0x30000000 Loading: ################################################## 15.8 MiB 787.1 KiB/s done TFTP server died; starting again > I see the code issue as below on net/tftp.c [v2020.10] ? /* * Acknowledge the block just received, which will prompt * the remote for the next one. */ if (tftp_cur_block == tftp_next_ack) { tftp_send(); tftp_next_ack += tftp_windowsize; } if (len < tftp_block_size) { //if (tftp_windowsize > 1) [Hack in use for now to work around this issue] tftp_send(); [ This causes extra ACK packet send with same block number and causes server to respond with ICMP error] tftp_complete(); } I couldn?t try with tftp_windowsize > 1 as the test servers don?t support. I tried with all latest commits on net/tftp.c on top of v2020.10 and still see the issue. This change is introduced in commit cc6b87ecaa96325577a8fafabc0d5972b816bc6c Author: Ramon Fried Date: Sat Jul 18 23:31:46 2020 +0300 net: tftp: Add client support for RFC 7440 Add support for RFC 7440: "TFTP Windowsize Option". Reverting this commit on v2020.10 also fixes the issue. I would like to know if this extra tftp_send is needed at all or only for window size > 1 Regards, Suneel On Wed, Aug 5, 2020 at 1:28 PM Tom Rini wrote: > > On Sat, Jul 18, 2020 at 11:31:46PM +0300, Ramon Fried wrote: > > > Add support for RFC 7440: "TFTP Windowsize Option". > > > > This optional feature allows the client and server > > to negotiate a window size of consecutive blocks to send as an > > alternative for replacing the single-block lockstep schema. > > > > windowsize can be defined statically during compilation by > > setting CONFIG_TFTP_WINDOWSIZE, or defined in runtime by > > setting an environment variable: "tftpwindowsize" > > If not defined, the windowsize is set to 1, meaning that it > > behaves as it was never defined. > > > > Choosing the appropriate windowsize depends on the specific > > network topology, underlying NIC. > > You should test various windowsize scenarios and see which > > best work for you. > > > > Setting a windowsize too big can actually decreases performance. > > > > Signed-off-by: Ramon Fried > > Reviewed-by: Marek Vasut > > Applied to u-boot/master, thanks! > > -- > Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: tftp-1.pcapng Type: application/x-pcapng Size: 17324 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: tftp-tftpput-1.pcapng Type: application/x-pcapng Size: 17248 bytes Desc: not available URL: