public inbox for ecos-devel@sourceware.org
 help / color / mirror / Atom feed
From: David Vrabel <dvrabel@arcom.com>
To: "Doyle, Patrick" <Patrick_Doyle@dtccom.com>
Cc: 'Andrew Lunn' <andrew@lunn.ch>,
	  "'ecos-devel@sources.redhat.com'"
	<ecos-devel@sources.redhat.com>,
	 'Andrew Dyer' <adyer@righthandtech.com>
Subject: Re: RedBoot patches regarding redboot_getc_terminate
Date: Thu, 18 May 2006 15:00:00 -0000	[thread overview]
Message-ID: <446C8BE9.10503@arcom.com> (raw)
In-Reply-To: <F7F756E5ED50F345959AE893AD2F15660A222D@dtcsrvr09.dtccom.com>

Doyle, Patrick wrote:
>> What happens to TFTP transfers with your change? Are they terminated
>> gracefully? Or do they hang around until the server times out and
>> kills them?
>>
>>       Andrew
>>
> Unfortunately, I don't have any means to check that.  Which is why I brought
> it up as a topic for discussion.  Then I realized that it would be easier to
> discuss if somebody who _did_ have a means to check that checked that, which
> led to me posting the patch :-)
> 
> IIRC, a TFTP server will keep spewing out packets until it has sent the
> whole file, and will retry and retransmit if the client stops responding.
> So, it guess it depends on what the TFTP transport stream (implemented in
> code somewhere in RedBoot) does when it gets a "terminate" call that isn't
> an abort...
> 
> Hmmm... looking at the code, I see something that looks like:
> 
> if (abort)
>   tftp_error_ack(...)
> else
>   tftp_ack(...)
> 
> which looks to me like TFTP folks would be getting some sort of similar
> error message for TFTP transfers.
> 
> I wonder why I'm the only one whose noticed this?  (he asks in a plaintive,
> "why do these things always happen to me" voice)

No.  I noticed (or rather a customer did) but didn't have time to really
look at it or implement a solution.  I guess I should have a least
mentioned it though. Sorry.

I don't think your patch does the correct thing wrt TFTP transfers since
we're back to the original situation of TFTP connections remaining open
for ages.

Here's a snippet from our internal bug tracker wrt lingering TFTP
connection issue:

"When loading ELF images using TFTP RedBoot fails to ACK the last
received data block. This causes the server to timeout and retransmit
the last data block several times. See attached packet captures for details.

This can cause problems with lame TFTP servers (like tftpd32 for
Windows) that can only handle one transfer at a time.

----

The ELF image used in testing had a trailing .comment section which
RedBoot isn't interested in so it stopped reading data from the TFTP
stream and hence didn't ack subsequent data blocks (I don't think it
even reads them from the network).

I'd suggest stripping unneeded sections from eCos/RedBoot ELF images. e.g.,
$ arm-elf-string --remove-section=.comment foo.elf

----

I'm not entirely happy with the fix. It terminates the download when all
the relevant bits of the ELF have been transferred. The causes the
sender to think that the file transfer has failed which causes some
customer confusion.

I think a better solution would be for the downloader to continue to
transfer the remaining portions of the ELF image and just throw them away."

Perhaps it's best to revert the fix for the lingering TFTP connections
and note instead that ELFs really need all unneccesary sections stripped
before transferring to the target?  At least until a complete solution
(e.g., my suggested solution in the paragraph above) has been implemented.

David Vrabel

ps. If possible, attach patches as text/plain so people can easily read
them in their mail readers.  Thanks.  Sticking a .txt extension at the
end of the file name may do the trick if you're using a lame mail client
that doesn't recognize patches as text/plain.
-- 
David Vrabel, Design Engineer

Arcom, Clifton Road           Tel: +44 (0)1223 411200 ext. 3233
Cambridge CB1 7EA, UK         Web: http://www.arcom.com/

  parent reply	other threads:[~2006-05-18 15:00 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-18 13:40 Doyle, Patrick
2006-05-18 13:54 ` Andrew Lunn
2006-05-18 15:00 ` David Vrabel [this message]
2006-05-18 15:14   ` Andrew Lunn
2006-05-18 15:59     ` David Vrabel
  -- strict thread matches above, loose matches on Subject: below --
2006-05-20  0:08 Andrew Dyer
2006-05-18 16:59 Doyle, Patrick
2006-05-18 13:32 Doyle, Patrick
2006-05-18 13:18 Doyle, Patrick
2006-05-18 13:26 ` Andrew Lunn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=446C8BE9.10503@arcom.com \
    --to=dvrabel@arcom.com \
    --cc=Patrick_Doyle@dtccom.com \
    --cc=adyer@righthandtech.com \
    --cc=andrew@lunn.ch \
    --cc=ecos-devel@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).