aboutsummaryrefslogtreecommitdiff
path: root/slirp
diff options
context:
space:
mode:
authorMilan Plzik <milan.plzik@gmail.com>2010-01-07 13:39:43 +0100
committerAnthony Liguori <aliguori@us.ibm.com>2010-01-13 17:14:16 -0600
commit1cb1a66aed921060fa34d161b52e95d05de18ec1 (patch)
treea279471075a9598bf03e1ab901788a2756171d7a /slirp
parentbb0300dc57c10b3721451b0ff566a03f9276cc77 (diff)
downloadqemu-1cb1a66aed921060fa34d161b52e95d05de18ec1.zip
qemu-1cb1a66aed921060fa34d161b52e95d05de18ec1.tar.gz
qemu-1cb1a66aed921060fa34d161b52e95d05de18ec1.tar.bz2
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 <thomas@horsten.com> Signed-off-by: Milan Plzik <milan.plzik@gmail.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Diffstat (limited to 'slirp')
-rw-r--r--slirp/tftp.c1
1 files changed, 1 insertions, 0 deletions
diff --git a/slirp/tftp.c b/slirp/tftp.c
index 12dd344..96c0e0c 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;
}
}