From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59512) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c96IO-0003Dd-ES for qemu-devel@nongnu.org; Tue, 22 Nov 2016 03:19:22 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c96IJ-0007fD-H5 for qemu-devel@nongnu.org; Tue, 22 Nov 2016 03:19:16 -0500 Received: from mx1.redhat.com ([209.132.183.28]:42326) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c96IJ-0007e7-B6 for qemu-devel@nongnu.org; Tue, 22 Nov 2016 03:19:11 -0500 References: <1479757549-18672-1-git-send-email-hpoussin@reactos.org> <06704f59-9ae1-6fcd-df14-0ff8bd7413c6@zytor.com> From: Thomas Huth Message-ID: <0fa87764-975a-a919-f1f3-a5543d096b13@redhat.com> Date: Tue, 22 Nov 2016 09:19:05 +0100 MIME-Version: 1.0 In-Reply-To: <06704f59-9ae1-6fcd-df14-0ff8bd7413c6@zytor.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] slirp: support dynamic block size for TFTP transfers List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "H. Peter Anvin" , =?UTF-8?Q?Herv=c3=a9_Poussineau?= , qemu-devel@nongnu.org Cc: Samuel Thibault , Stefan Hajnoczi , Jan Kiszka On 21.11.2016 20:51, H. Peter Anvin wrote: > On 11/21/16 11:45, Herv=C3=A9 Poussineau wrote: >> The blocksize option is defined in RFC 1783. >> We now support block sizes between 1 and 1432 bytes, instead of 512 on= ly. >=20 > It ought to be 1476: Ethernet MTU =3D 1500, minus a minimum of 20 bytes > for an IPv4 header and 4 for a TFTP header. Don't forget the size of the UDP header - so the maximum value is 1468. However, if you want to play safe, you should also consider that somebody is putting additional options into the IPv4 header, so the IPv4 header can be up to 60 bytes instead of only 20 bytes. So a real safe value for the maximum TFTP block size is: 1500 - 60 - 8 - 4 =3D 1428 This is also what is mentioned in RFC2348 which obsoletes RFC1783 (that mentions 1432). Thomas