From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18010 invoked by alias); 10 Jan 2011 14:31:24 -0000 Received: (qmail 18002 invoked by uid 22791); 10 Jan 2011 14:31:23 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from hermes.mlbassoc.com (HELO mail.chez-thomas.org) (64.234.241.98) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 10 Jan 2011 14:31:17 +0000 Received: by mail.chez-thomas.org (Postfix, from userid 999) id 2D9AE16602F3; Mon, 10 Jan 2011 07:31:12 -0700 (MST) Received: from hermes.chez-thomas.org (hermes_local [192.168.1.101]) by mail.chez-thomas.org (Postfix) with ESMTP id 71D5E16602D3; Mon, 10 Jan 2011 07:31:11 -0700 (MST) Message-ID: <4D2B182F.6030305@mlbassoc.com> Date: Mon, 10 Jan 2011 14:31:00 -0000 From: Gary Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc13 Thunderbird/3.1.7 MIME-Version: 1.0 To: Sergei Gavrikov CC: eCos Developers Subject: Re: RedBoot's TFTP client and dumb TFTP servers References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact ecos-devel-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org X-SW-Source: 2011-01/txt/msg00009.txt.bz2 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 ------------------------------------------------------------