From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NSuWg-0005yl-IO
	for qemu-devel@nongnu.org; Thu, 07 Jan 2010 10:43:54 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1NSuWb-0005rl-9q
	for qemu-devel@nongnu.org; Thu, 07 Jan 2010 10:43:53 -0500
Received: from [199.232.76.173] (port=57108 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NSuWb-0005ra-0H
	for qemu-devel@nongnu.org; Thu, 07 Jan 2010 10:43:49 -0500
Received: from terminus.zytor.com ([198.137.202.10]:47338)
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60)
	(envelope-from <hpa@zytor.com>) id 1NSuWa-0004BV-G0
	for qemu-devel@nongnu.org; Thu, 07 Jan 2010 10:43:48 -0500
Message-ID: <4B4600EF.2040406@zytor.com>
Date: Thu, 07 Jan 2010 07:42:39 -0800
From: "H. Peter Anvin" <hpa@zytor.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] Qemu's internal TFTP server breaks lock-step-iness
	of	TFTP
References: <1262815902.18404.341.camel@localhost>
In-Reply-To: <1262815902.18404.341.camel@localhost>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Milan Plzik <milan.plzik@gmail.com>
Cc: qemu-devel@nongnu.org

On 01/06/2010 02:11 PM, Milan Plzik wrote:
>   Hello,
> 
>   according to RFC 1350 and RFC 2347, TFTP server should answer RRQ by
> either OACK or DATA packet. Qemu's internal TFTP server answers RRQ with
> additional options by sending both OACK and DATA packet, thus breaking
> the "lock-step" feature of the protocol, and also confuses client.
> 
>   Proposed solution would be to, in case of OACK packet, wait for ACK
> from client and just then start sending data. Attached patch implements
> this.
> 
>   I would like to thank to mbc and th1 (who is the rightful author of
> the patch) from #gpxe for their time, effort and patience with me :)
> 
> 	Milan Plzik

The built-in TFTP server has at least two *serious* other problems:

a) It has the Sorcerer's Apprentice bug (See RFC 1123 and 1350).
b) It doesn't do time-based retransmits.

Note that (a) can't be fixed without fixing (b).

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.