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 82D1EC433EF for ; Tue, 29 Mar 2022 20:28:33 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 7769C83B1A; Tue, 29 Mar 2022 22:28:31 +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="nBoxV9dZ"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id EC2478394F; Tue, 29 Mar 2022 22:28:29 +0200 (CEST) Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [IPv6:2001:4b98:dc2:55:216:3eff:fef7:d647]) (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 67A0B84039 for ; Tue, 29 Mar 2022 22:28:27 +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 (62-78-145-57.bb.dnainternet.fi [62.78.145.57]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id 7A4812F7; Tue, 29 Mar 2022 22:28:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1648585706; bh=Rog6IWx/OY4isf2q74TZYduM+5D82eUks95EEqOSF1M=; h=Date:From:To:Cc:Subject:From; b=nBoxV9dZfuv3+o98liMbHxKoyGLSoarFJKFKvkB1GgxcXRZMpESVlm6P84U7YMBgn kOJXBpFwr4jGp/UK5EotADYTWXC16UKoaU3N60mLhd+nmvuGe59kVp0Se5fjKH8xOO DBoqBTaHGLsRsPJuCI7VTZ3RvcTl0+pwy+2yp1FA= Date: Tue, 29 Mar 2022 23:28:23 +0300 From: Laurent Pinchart To: u-boot@lists.denx.de Cc: Ramon Fried , Marcel Ziswiler Subject: TFTP hangs with fragmented IP packets Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="5hjuYTO+/TrjQbLc" Content-Disposition: inline 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 --5hjuYTO+/TrjQbLc Content-Type: text/plain; charset=utf-8 Content-Disposition: inline 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. -- Regards, Laurent Pinchart --5hjuYTO+/TrjQbLc Content-Type: application/octet-stream Content-Disposition: attachment; filename="test.bin" Content-Transfer-Encoding: base64 sAv0APAL9AAwDPQAcAz0ALAM9ADwDPQAMA30AHAN9ACwDfQA8A30ADAO9ABwDvQAsA70APAO 9AAwD/QAcA/0ALAP9ADwD/QAMBD0AHAQ9ACwEPQA8BD0ADAR9ABwEfQAsBH0APAR9AAwEvQA cBL0ALAS9ADAEvQAUBT0AJAU9ADQFPQAEBX0AFAV9ACQFfQAoBX0AOAV9AAgFvQAYBb0AKAW 9ADgFvQAIBf0AGAX9ACgF/QA4Bf0ACAY9ABgGPQAoBj0AOAY9AAgGfQAMBn0AHAZ9ACwGfQA 8Bn0ADAa9ABwGvQAsBr0APAa9AAoG/QAaBv0AKgb9ADoG/QAKBz0AGgc9ACoHPQA6Bz0ACgd 9ABoHfQAqB30AOgd9AAoHvQAaB70AKAe9ADgHvQAIB/0AGAf9ACgH/QA4B/0ACAg9ABgIPQA oCD0AOAg9AAgIfQAYCH0AKAh9ADgIfQAICL0AGAi9ACgIvQA4CL0ACAj9ABgI/QAoCP0AOAj 9AAYJPQAWCT0AJgk9ADYJPQAGCX0AFgl9ACYJfQA2CX0ABgm9ABYJvQAmCb0ANgm9AAYJ/QA WCf0AJgn9ADYJ/QAGCj0AFgo9ACYKPQA2Cj0APgo9AAIKfQAGCn0ACgp9AA4KfQASCn0AFgp 9ABgKfQAaCn0AHAp9ADwKfQAgCv0AEgs9AAQLfQA2C30AKAu9ABoL/QAMDD0AEgw9ABgMPQA eDD0ADAx9ABYMfQAgDH0AJAx9ACgMfQAyDH0APAx9AAYMvQAQDL0AGgy9ACINfQAmDX0ALg2 9ADINvQAUDj0ABg59AA4OfQAUDn0AAg69AAgOvQACD70ABg+9ACQQ/QAoEP0AJhG9ACoRvQA yEn0ANhJ9AAASvQAAEv0AChL9ABAS/QAgEv0AJBL9ACoS/QAwEv0ANBL9ADoS/QACEz0ADBM 9ABITPQAWEz0AHBM9ACITPQAqEz0AMhM9ADYTPQA6Ez0AABN9AAYTfQAKE30AEhN9ABgTfQA gE30AJBN9ACwTfQAwE30AOBN9ADwTfQACE70ACBO9AAwTvQASE70AGBO9ABwTvQAiE70AKBO 9ACwTvQAyE70AOBO9AAAT/QAEE/0ACBP9AA4T/QAUE/0AHBS9AAoU/QASFP0AGBT9AB4U/QA mFP0ALBT9ABAVfQAWFX0AEBZ9ABQWfQAYFn0AHBZ9ACAWfQAkFn0AKBZ9AC4WfQAyFn0AOBZ 9AD4WfQAEFr0ACBa9ABAWvQAWFr0AGha9AB4WvQAkFr0AKBa9ACwWvQAyFr0AOBa9AD4WvQA CFv0ACBb9AAgXPQAQFz0APhc9ACQZfQAqGX0AMBl9ADYZfQA8GX0ACBm9AAAZ/QAiHr0ADh/ 9AB4f/QAMID0AFCA9ABwgPQAoID0ADCq9ABQqvQAWKr0AHiq9AAoq/QAGEn1ADhJ9QBYSfUA yEn1AIit9QCorfUAyK31ACiu9QCYCfYAuAn2AMAJ9gDgCfYAAAr2APAi9gDYJvYA6Cb2APgm 9gAIJ/YAGCf2AEAn9gAoK/YASCv2ACgt9gBILfYACC72ACgu9gDoLvYACC/2AJgv9gBQMPYA aDH2AOAx9gBwM/YAKDT2AFA09gBgNPYAgDT2AKA09gC4NPYA2DT2APA09gAQNfYAWDX2AJg1 9gCYNvYAqDb2AKg39gCoOPYAyDj2AOA49gAAOfYAIDn2AEg59gBgOfYAeDn2AJg59gCoOfYA wDn2ANA59gDoOfYAADr2ALg69gDgOvYA8Dr2APg79gAoPfYASD72AGA+9gCAPvYAmD72AMA+ 9gDgPvYAAED2ACBB9gBAQvYAWEL2AHhF9gCARfYAiEX2AJBF9gC4RfYA2EX2AABG9gAYRvYA MEb2AEBG9gCgRvYAsEb2AMBG9gDgR/YAAEn2ACBK9gBAS/YAYEz2AIBN9gCgTvYAwE/2AOBQ 9gAAUvYAIFP2AEBU9gA= --5hjuYTO+/TrjQbLc--