Red Hat Bugzilla – Bug 59987
TFTP to MicroSoft TFTP server does not work
Last modified: 2007-04-18 12:40:27 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6) Gecko/20011120
Description of problem:
When attempting to TFTP load from a Microsoft TFTP server, it fails. This is
because the RFC for TFTP specifies that "OCTET" be uppercase but MicroSoft TFTP
The workaround is to try first the uppercase "OCTET" then, if that fails, the
lowercase "octet", in RedBoot.
As reported by Douglas Bush of Extreme Engineering in ecos-discuss on Feb 13, 2002.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Start MS TFTP server
2. In RedBoot "load -h 172.16.1.15 -m tftp redboot.srec"
3. Observe error "Can't load 'redboot.srec': operation timed out"
Actual Results: Can't load 'redboot.srec': operation timed out
Expected Results: Should have loaded
Tested against the TFTPD32 server running on Windows with no problems.
Is there a particular Windows server for which this fails? If so, which
and how does one obtain it for testing?
* From: Jonathan Larmour <jlarmour at redhat dot com>
* To: Douglas Bush <dbush at extremeeng dot com>
* Cc: 'eCos Discussion List' <ecos-discuss at sources dot redhat dot com>
* Date: Thu, 14 Feb 2002 18:51:44 +0000
* Subject: Re: [ECOS] Problem TFTPing from redboot
* Organization: Red Hat UK Ltd.
* References: <
Douglas Bush wrote:
> > I did a couple of captures (hex ascii at bottom of files) with a running
> TFTP server, one from an OpenBSD TFTP client, and one from Redboot.
> Both were accessing Windows TFTPD32 for download.
> > What I noticed was that the Redboot requests OCTET transfers, and adds
> another 500 bytes or so of 0's to the end of the transfer.
> > Perhaps that's why windows TFTP servers don't work well with redboot...
It looks like there was a fix for this problem around 11th June last year
in CVS. Do your redboot sources predate that? If so, update! (Of course
maybe that's what you are trying to do ;-), in which case as Jesper says
something like ymodem over serial is a good intermediate workaround).
Did you get a private response from firstname.lastname@example.org to this issue?
I assume we can close?
I didn't get any response. I'm closing it (it isn't a "real" customer).