tree a279471075a9598bf03e1ab901788a2756171d7a
parent bb0300dc57c10b3721451b0ff566a03f9276cc77
author Milan Plzik <milan.plzik@gmail.com> 1262867983 +0100
committer Anthony Liguori <aliguori@us.ibm.com> 1263424456 -0600

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>