This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: Re: timeout in tftp_client_test.c
On Tue, Apr 22, 2003 at 05:33:03PM -0400, HG wrote:
> >
> > That does tcpdump (or Windump on M$) show? That should give you an
> > idea where the problem lies, server or client.
>
> by looking at the windump of the exchange happening on the wire with
> the application tftp_client_test.c edited to include only the get .
>
> it appears after 7 packets of 512 bytes + 2 opcode + 2 block = 516 bytes
> the tftp_get function has had enough , it returns to the screen saying that
> it
> transfered 512 * 7 = 3584 bytes and there where no errors. The file size
> of hello.s is 29112 bytes
>
> there is an other request coming from the application ????? that confuses
> the tftp server (it thinks it still has well over 20k to send) . eventually
> the
> application does not seem to answer , the server issues a message that it
> timed out on the transfer and is ready for an other request.
>
> to me this looks like a bug in the tftp_get function??????
>
> anyone know of a good approach to troubleshoot this problem ???
> should i look for a configuration problem, find a magic priority number,
> look for a bug in the tftp_get code ?????
My feeling is its not the tftp_get code. The tcpdump trace is just too
strange. The transfer seems to be going fine and then suddenly it
sends the RRQ again. Why?
How big is your stack for the thread doing the tftp_get? Where is your
buf located? To me, this looks like stack corruption.
Andrew
>
> thanks
>
> Henri
>
>
>
> viewed on the diagnostic serial output:
> Start TFTP test
> BOOTP[eth0] op: REPLY
> htype: Ethernet
> hlen: 6
> hops: 0
> xid: 0x0
> secs: 0
> flags: 0x0
> hw_addr: 08:88:12:34:56:78
> client IP: 192.168.0.21
> my IP: 192.168.0.21
> server IP: 192.168.0.4
> gateway IP: 192.168.0.4
> options:
> subnet mask: 255.255.255.0
> IP broadcast: 192.168.0.255
> gateway: 192.168.0.4
> Trying tftp_get hello.s 192.168.0.4...
> res = 3584, err = 0
>
>
> here is the windump command running on a cygwin window :
> $ ./windump -n udp > tftp_client_test_timeout.txt
> d:\download_pour_nt\windump\windump.exe: listening on \Device\NPF_RTL80291
>
> content of tftp_client_test_timeout.txt
> 16:15:33.720814 IP 192.168.0.21.7700 > 192.168.0.4.69: 16 RRQ "hello.s"
> 16:15:33.741326 IP 192.168.0.4.1077 > 192.168.0.21.7700: udp 516
> 16:15:33.972907 IP 192.168.0.21.7700 > 192.168.0.4.1077: udp 4
> 16:15:33.976868 IP 192.168.0.4.1077 > 192.168.0.21.7700: udp 516
> 16:15:34.223731 IP 192.168.0.21.7700 > 192.168.0.4.1077: udp 4
> 16:15:34.227658 IP 192.168.0.4.1077 > 192.168.0.21.7700: udp 516
> 16:15:34.474590 IP 192.168.0.21.7700 > 192.168.0.4.1077: udp 4
> 16:15:34.478536 IP 192.168.0.4.1077 > 192.168.0.21.7700: udp 516
> 16:15:34.725576 IP 192.168.0.21.7700 > 192.168.0.4.1077: udp 4
> 16:15:34.729551 IP 192.168.0.4.1077 > 192.168.0.21.7700: udp 516
> 16:15:34.976489 IP 192.168.0.21.7700 > 192.168.0.4.1077: udp 4
> 16:15:34.980418 IP 192.168.0.4.1077 > 192.168.0.21.7700: udp 516
> 16:15:35.227418 IP 192.168.0.21.7700 > 192.168.0.4.1077: udp 4
> 16:15:35.231460 IP 192.168.0.4.1077 > 192.168.0.21.7700: udp 516
> 16:15:35.476783 IP 192.168.0.21.7700 > 192.168.0.4.69: 16 RRQ "hello.s"
> 16:15:35.478337 IP 192.168.0.21.7700 > 192.168.0.4.1077: udp 4
> 16:15:35.583451 IP 192.168.0.4.1079 > 192.168.0.21.7700: udp 516
> 16:15:35.727715 IP 192.168.0.21.7700 > 192.168.0.4.1077: udp 4
> 16:15:35.729181 IP 192.168.0.21.7700 > 192.168.0.4.1077: udp 4
> 16:15:41.986711 IP 192.168.0.4.1079 > 192.168.0.21.7700: udp 516
> 16:15:48.496087 IP 192.168.0.4.1079 > 192.168.0.21.7700: udp 516
> 16:15:51.087107 IP 192.168.0.4.137 > 192.168.0.21.137: udp 50
> 16:15:52.588931 IP 192.168.0.4.137 > 192.168.0.21.137: udp 50
> 16:15:54.091066 IP 192.168.0.4.137 > 192.168.0.21.137: udp 50
> 16:15:55.005422 IP 192.168.0.4.1079 > 192.168.0.21.7700: udp 516
> 16:16:01.512078 IP 192.168.0.4.1079 > 192.168.0.21.7700: udp 82
>
> extract from the application code tftp_client_test.c:
> the thread is created with priority 5 instead of 10 as in the example
> an other type of error message was observed with the different priority
> the server would keep writing that it timed out for several minutes .
> ......
>
> #define GETFILE "hello.s"
>
>
> static void
> tftp_test(struct bootp *bp)
> {
> int res, err, len;
> struct sockaddr_in host;
>
> memset((char *)&host, 0, sizeof(host));
> host.sin_len = sizeof(host);
> host.sin_family = AF_INET;
> host.sin_addr = bp->bp_siaddr;
> host.sin_port = 0;
> diag_printf("Trying tftp_get %s %16s...\n", GETFILE,
> inet_ntoa(host.sin_addr));
> res = tftp_get( GETFILE, &host, buf, sizeof(buf), TFTP_OCTET, &err);
> diag_printf("res = %d, err = %d\n", res, err);
> ......
>
>
>
> --
> Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
> and search the list archive: http://sources.redhat.com/ml/ecos-discuss
>
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss