This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: TFTP bug


On Sun, 2001-09-30 at 07:23, Jonathan Larmour wrote:
> Pushparaj wrote:
> > 
> > Hi Jonathan,
> > I am working on motorola powerpc 860 platform and trying to download a 890,338 size
> > s19 file.
> > It is a s-record. It is built at 2MB in RAM. I am using the load command and I give it
> > in this format.
> > load c:\image.s19.
> 
> You said before you were loading it in "raw" format using -r. Make your
> mind up!
> 
> > The server ip address is set and the redboot is also able to understand that the
> > image.s19 file is built at 2MB. Redboot is not using this address in RAM.
> > Now when I try to download I print the server port numbers in functions,
> > tftp_stream_read and udp_sendto and udp_recvfrom. I find that the server udp port
> > number ie., sin_port is changing to zero sometimes. Why does this happen ?
> 
> Curiously, looking at the code in redboot's tftp_client.c, I can't see how
> tftp_stream.from_addr gets set at all. I can only assume it has worked
> before because all the data has already been sent from the server fast
> enough.
> 

It gets set on line 308:
     if ((data_len = __udp_recvfrom(&tftp_stream.data[0], recv_len, &tftp_stream.from_addr, 
                                    &tftp_stream.local_addr,  &timeout)) < 0) {
One result of this call will be to set 'from_addr' to the information
about the host (sender).

That address will only be used to send back the ACK.  I don't see how 
it's possible for it to ever get a port of zero, since that's filled in 
when a data packet arrives and had to match to be accepted.

> I think you'll find it works if near the end of tftp_stream_open (after the
> assignment to total_timeouts) you add a:
> 
> memcpy(&tftp_stream.local_addr, server, sizeof(*server));
> 

This is not necessary and will be overwritten by the first packet 
received.

> Let us know if that's sufficient to fix the problem for you and I'll apply
> it in the main sources.

There is obviously something else wrong with Pushparaha's system.  I'd 
suggest adding some diag_printf() calls with the body of 
tftp_stream_read() to try and get a feel for what's up.

This code works on other platforms.  We routinely use it to load images
of many megabytes (JFFS2 images on the iPAQ are 14MB, for example).



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]