Re: RedBoot's TFTP client and dumb TFTP servers

[Gary Thomas <gary@mlbassoc.com>]

On 01/10/2011 07:13 AM, Sergei Gavrikov wrote:
> 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.

I've never run across another TFTP server that can't handle
OCTET in upper case.

By your reference, the QEMU server is what's broken - why not fix it instead?

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------