RedBoot's TFTP client and dumb TFTP servers

RedBoot's TFTP client and dumb TFTP servers

[Sergei Gavrikov]

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

Re: RedBoot's TFTP client and dumb TFTP servers

[Gary Thomas]

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
------------------------------------------------------------

Re: RedBoot's TFTP client and dumb TFTP servers

[Sergei Gavrikov]

On Mon, 10 Jan 2011, Gary Thomas wrote:

> 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;
> >      }
> > 

[snip]

> 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, thanks for your expertise, then I will disturb qemu-devel list.


Sergei

Re: RedBoot's TFTP client and dumb TFTP servers

[Sergei Gavrikov]

Hi,

On Mon, 10 Jan 2011, Sergei Gavrikov wrote:

> On Mon, 10 Jan 2011, Gary Thomas wrote:

> > On 01/10/2011 07:13 AM, Sergei Gavrikov wrote:
<...>
> > > 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've never run across another TFTP server that can't handle OCTET in
> > upper case.

Indeed, I've checked out 'netkit-tftp', 'atftp', and 'tftp-hpa' sources.
All TFTP servers use either strcasecmp() or tolower() then strcmp() on
checking the mode field. But all companion (TFP clients) send the mode
field in *lower* case.

> > By your reference, the QEMU server is what's broken - why not fix it
> > instead?
> 
> Gary, thanks for your expertise, then I will disturb qemu-devel list.

FYI: they applied my patch, but it is unlikely that everyone loves build
QEMU from sources :-) IMO, we could get the RedBoot's TFTP client be more
compliant/tolerant, but can be the RedBoot on QEMU is rarely the case.

Sergei