[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Qemu's internal TFTP server breaks lock-step-iness of T
From: |
H. Peter Anvin |
Subject: |
Re: [Qemu-devel] Qemu's internal TFTP server breaks lock-step-iness of TFTP |
Date: |
Thu, 07 Jan 2010 07:42:39 -0800 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-3.fc11 Thunderbird/3.0 |
On 01/06/2010 02:11 PM, Milan Plzik wrote:
> Hello,
>
> 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.
>
> I would like to thank to mbc and th1 (who is the rightful author of
> the patch) from #gpxe for their time, effort and patience with me :)
>
> Milan Plzik
The built-in TFTP server has at least two *serious* other problems:
a) It has the Sorcerer's Apprentice bug (See RFC 1123 and 1350).
b) It doesn't do time-based retransmits.
Note that (a) can't be fixed without fixing (b).
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.