From: Milan Plzik Date: Thu, 7 Jan 2010 12:39:43 +0000 (+0100) Subject: Qemu's internal TFTP server breaks lock-step-iness of TFTP X-Git-Tag: v0.13.0-rc0~1690 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=1cb1a66aed921060fa34d161b52e95d05de18ec1;p=thirdparty%2Fqemu.git Qemu's internal TFTP server breaks lock-step-iness of TFTP 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 Signed-off-by: Milan Plzik Signed-off-by: Anthony Liguori --- diff --git a/slirp/tftp.c b/slirp/tftp.c index 12dd3444f8a..96c0e0c6735 100644 --- a/slirp/tftp.c +++ b/slirp/tftp.c @@ -368,6 +368,7 @@ static void tftp_handle_rrq(Slirp *slirp, struct tftp_t *tp, int pktlen) } tftp_send_oack(spt, "tsize", tsize, tp); + return; } }