[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
Re: [Qemu-devel] Qemu's internal TFTP server breaks lock-step-iness of TFTP
Wed, 06 Jan 2010 16:43:57 -0600
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:18.104.22.168) Gecko/20091209 Fedora/3.0-4.fc12 Lightning/1.0pre Thunderbird/3.0
On 01/06/2010 04:11 PM, 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
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 :)
Thanks for the patch, I assume this fixes -boot n when using -bootp and
-tftp. Can you add an appropriate Signed-off-by and resubmit?