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 protoco
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" fea
V Streda, 6. január 2010 o 16:43 -0600, Anthony Liguori napísal(a):
> Thanks for the patch, I assume this fixes -boot n when using -bootp and
> -tftp.
Not sure what was the original issue, but at least for me it fixed
booting pxegrub :)
> Can you add an appropriate Signed-off-by and resubmit
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 solut
On 01/06/2010 04: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
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.
Prop
