From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 4429EC433EF for ; Tue, 5 Apr 2022 23:11:29 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 694E383C08; Wed, 6 Apr 2022 01:11:26 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=ideasonboard.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; unprotected) header.d=ideasonboard.com header.i=@ideasonboard.com header.b="i/MrPhNg"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 5A67B83C04; Wed, 6 Apr 2022 01:11:23 +0200 (CEST) Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [213.167.242.64]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 21D0F83B42 for ; Wed, 6 Apr 2022 01:11:19 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=ideasonboard.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=laurent.pinchart@ideasonboard.com Received: from pendragon.ideasonboard.com (117.145-247-81.adsl-dyn.isp.belgacom.be [81.247.145.117]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id 693B4482; Wed, 6 Apr 2022 01:11:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1649200278; bh=D34CrblMvIdacI9IKs/Xma+/21LtmPFaj0RNAfgusjA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=i/MrPhNgmQ2khcLfdLbbNVD4D9DfjV+9ULN5rsw4BpiXU0S+RB0f6NZHZWjYQ0CUI 0P7L1Yu3+k3hKDVp2sbcwFZuk41BajUMYGYIBUQjklFloJxD/U/NiymR3sw4cwVjvD IPe/KQTaBx6FptRqrOCsrM833gZxvzERRVGN3U7k= Date: Wed, 6 Apr 2022 02:11:15 +0300 From: Laurent Pinchart To: Ramon Fried Cc: U-Boot Mailing List , Marcel Ziswiler Subject: Re: TFTP hangs with fragmented IP packets Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.5 at phobos.denx.de X-Virus-Status: Clean Hi Ramon, On Sun, Apr 03, 2022 at 02:17:26AM +0300, Ramon Fried wrote: > On Thu, Mar 31, 2022 at 8:43 AM Ramon Fried wrote: > > On Tue, Mar 29, 2022 at 11:28 PM Laurent Pinchart wrote: > > > > > > 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. > > > > > Interesting. > > I will try to reproduce. > > Thanks for reporting. > > Hi. > I couldn't reproduce the issue with the file you provided. > I used sandbox64, and changed the TFTP BLOCK size to 4096. > I managed to TFTP the file successfully. > > => setenv autoload no > => setenv ethrotate no > => setenv ethact eth0 > => setenv ipaddr > => setenv serverip 172.23.1.137 > => env set ipaddr 172.23.1.100 > => tftpboot 0x100000 test.bin > Using host_eno1 device > TFTP from server 172.23.1.137; our IP address is 172.23.1.100 > Filename 'test.bin'. > Load address: 0x100000 > Loading: # > 718.8 KiB/s > done > Bytes transferred = 1472 (5c0 hex) > => Hmmmm... I wonder if it could be specific to the EQoS ethernet controller in the i.MX8, maybe caused by issues in hardware CRC calculation ? I don't have any other board I can use for testing this at the moment as I'm travelling. > Can you perhaps send me a network PCAP of your device failing to > digest the file ? I'll try to do that tomorrow. -- Regards, Laurent Pinchart