RedBoot's TFTP client and dumb TFTP servers

[Sergei Gavrikov <sergei.gavrikov@gmail.com>]

Hi

I tried to get working the QEMU's embedded TFTP server with RedBoot's
FTP client and the RedBoot's 'load' command always wept, -- "illegal
TFTP operation".

I did dig that QEMU's TFTP server has the very simple check for a
transfer mode:

slirp/tftp.c:314

    if (memcmp(&tp->x.tp_buf[k], "octet\0", 6) != 0) {
        tftp_send_error(spt, 4, "Unsupported transfer mode", tp);
        return;
    }

in a contrast, RedBoot sets a binary transfer as 

net/tftp_client.c:95

    fp = "OCTET";
    while (*fp) *cp++ = *fp++;
    *cp++ = '\0';


According the RFC 1350 'THE TFTP PROTOCOL (REVISION 2)'
http://www.ietf.org/rfc/rfc1350.txt

(look at the page 5, please)

the RedBoot's code does not anything wrong (even obsolete RFC 783
allows any combination of upper and lower case, such as "NETASCII").
However, the first words are mentioned there are all lower-cased.

Well, a substitution 's/OCTET/octet/' in tftp_client.c solved the issue
with the QEMU TFTP server. However, perhaps, there are a few such TFTP
servers like the QEMU's one. It seemed for me that same symptom was
reported here:
http://sourceware.org/ml/ecos-discuss/2005-06/msg00158.html

Q: Whether can we simplify our life patching RedBoot? Is it safe?

Well, if I did not miss something, I can generate new report via
Bugzilla.


Sergei