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


Hi,
Today, I looked into the tftp download problem in a more detail. This is what I inferred from
the packed view that I captured between the tftp server and the client.
I use the following command to load a s record.
load c:\image.s19.
The target hardware which is running on motorola powerpc 860, sends the first packet over UDP
on the port 69. The server is listening on this port and it replies back saying that its port
is 1750 and sends the first 512 chunk.
After this the board sends the ack for this packet with destination port 1750.
This continues for few more 512 chunks of memory. And the transaction is fine with the server
sending the packet 'n' and the redboot sending the ack for packet 'n'.
Now the server transmits the (n+1) packet and suddenly the board sends the ack for nth packet
again with destination port 0.

I have used the latest tftp client code from the CVS server and tried. This happens
consistently and once this happens the tftp server sends an ICMP "destination unreachable'
reply. The board still tries sending the ack for nth packet ( with destination port 0 ofcourse
! ) and the server sends again the icmp packet . This happens till the redboot times out.

I am using this Walusoft tftp server. I have downloaded it recently for test purpose and I dont
know how efficient this server is  ;-)
I shall try with the linux tftp server tomorrow and get back to u with the latest.
Meantime if you have faced the problem where in the redboot sends the ack for nth packet twice,
please get back to me.

Best Regards,
Pushparaj



Gary Thomas wrote:

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