From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NSref-0001JB-In
	for qemu-devel@nongnu.org; Thu, 07 Jan 2010 07:39:57 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1NSreb-0001FC-MN
	for qemu-devel@nongnu.org; Thu, 07 Jan 2010 07:39:57 -0500
Received: from [199.232.76.173] (port=57132 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NSreb-0001F1-HI
	for qemu-devel@nongnu.org; Thu, 07 Jan 2010 07:39:53 -0500
Received: from fg-out-1718.google.com ([72.14.220.157]:22727)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <milan.plzik@gmail.com>) id 1NSreb-0001HX-2J
	for qemu-devel@nongnu.org; Thu, 07 Jan 2010 07:39:53 -0500
Received: by fg-out-1718.google.com with SMTP id 19so2477740fgg.10
	for <qemu-devel@nongnu.org>; Thu, 07 Jan 2010 04:39:52 -0800 (PST)
From: Milan Plzik <milan.plzik@gmail.com>
Content-Type: multipart/mixed; boundary="=-IOQwGos25Lt1+UIptIRl"
Date: Thu, 07 Jan 2010 13:39:43 +0100
Message-ID: <1262867983.18404.659.camel@localhost>
Mime-Version: 1.0
Subject: [Qemu-devel] Qemu's internal TFTP server breaks lock-step-iness of
	TFTP
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: qemu-devel@nongnu.org


--=-IOQwGos25Lt1+UIptIRl
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit

  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.

Signed-off-by: Thomas Horsten <thomas@horsten.com>
Signed-off-by: Milan Plzik <milan.plzik@gmail.com>


--=-IOQwGos25Lt1+UIptIRl
Content-Disposition: attachment; filename="qemu_tftp_handle_oack_correctly.patch"
Content-Type: text/x-patch; name="qemu_tftp_handle_oack_correctly.patch"; charset="UTF-8"
Content-Transfer-Encoding: 7bit

diff --git a/slirp/tftp.c b/slirp/tftp.c
index 082f5d0..db869fc 100644
--- a/slirp/tftp.c
+++ b/slirp/tftp.c
@@ -362,6 +362,7 @@ static void tftp_handle_rrq(Slirp *slirp, struct tftp_t *tp, int pktlen)
 	  }
 
 	  tftp_send_oack(spt, "tsize", tsize, tp);
+	  return;
       }
   }
 

--=-IOQwGos25Lt1+UIptIRl--