Patchwork Qemu's internal TFTP server breaks lock-step-iness of TFTP

login
register
mail settings
Submitter Milan Plzik
Date Jan. 7, 2010, 12:39 p.m.
Message ID <1262867983.18404.659.camel@localhost>
Download mbox | patch
Permalink /patch/42429/
State New
Headers show

Comments

Milan Plzik - Jan. 7, 2010, 12:39 p.m.
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>
Anthony Liguori - Jan. 13, 2010, 11:26 p.m.
On 01/07/2010 06:39 AM, Milan Plzik wrote:
>    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>
>
>    

Applied.  Thanks.

Regards,

Anthony Liguori

Patch

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;
       }
   }