[ECOS] Re: timeout in tftp_client_test.c

[ECOS] Re: timeout in tftp_client_test.c

[HG]

update

the test tftp_get test seems to work ok for small files , smaller than about
3k
(the ecos reference manual refers to 32k as the limit)

I could not get the tftp_put test to work on an NT server , I suspect
the server has to be linux with all the correct permissions  . Anyone got it
working on an NT???

Sorry for the double post of yesterday, the mail server seemed to hang , I
cancelled the send , the mail client sent items shows only 1 send.


thanks,

HG
----- Original Message ----- >
> I am getting timeouts in this test in the following test case for the
> tftp_get call :
>




-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] Re: timeout in tftp_client_test.c

[Andrew Lunn]

On Fri, Apr 18, 2003 at 03:28:20PM -0400, HG wrote:
> update
> 
> the test tftp_get test seems to work ok for small files , smaller than about
> 3k
> (the ecos reference manual refers to 32k as the limit)

32K? Thats wrong. Its more likely to be a few megebytes.

> I could not get the tftp_put test to work on an NT server , I suspect
> the server has to be linux with all the correct permissions  . Anyone got it
> working on an NT???

Permissions will not be your problem. If you can get 3K, the
permissions are correct. The client should work with any
server. Admittedly Linux is probably the most tested, but if it does
not work with NT, it should and needs fixing. 

That does tcpdump (or Windump on M$) show? That should give you an
idea where the problem lies, server or client.

     Andrew

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] Re: timeout in tftp_client_test.c

[HG]

> > the test tftp_get test seems to work ok for small files , smaller than
about
> > 3k
> > (the ecos reference manual refers to 32k as the limit)
>
> 32K? Thats wrong. Its more likely to be a few megebytes.

the 32k limit refered in the manual is probably  from this particular
test program that has a 32k buffer defined


> > I could not get the tftp_put test to work on an NT server , I suspect
> > the server has to be linux with all the correct permissions  . Anyone
got it
> > working on an NT???
>
> Permissions will not be your problem. If you can get 3K, the
> permissions are correct. The client should work with any
> server. Admittedly Linux is probably the most tested, but if it does
> not work with NT, it should and needs fixing.

the ecos configuration is for an application running out of ram (the test
prog)
that uses the Redboot vectors that are for a rom startup
Any possibility that a romram startup is required instead to run this test
program???? The timeout seems to indicate that something is not fast
enough?


>
> That does tcpdump (or Windump on M$) show? That should give you an
> idea where the problem lies, server or client.

I will try this today


thanks

regards ,

Henri


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] Re: timeout in tftp_client_test.c

[Andrew Lunn]

On Tue, Apr 22, 2003 at 07:06:23AM -0400, HG wrote:
> > > the test tftp_get test seems to work ok for small files , smaller than
> about
> > > 3k
> > > (the ecos reference manual refers to 32k as the limit)
> >
> > 32K? Thats wrong. Its more likely to be a few megebytes.
> 
> the 32k limit refered in the manual is probably  from this particular
> test program that has a 32k buffer defined

OK

> the ecos configuration is for an application running out of ram (the test
> prog)
> that uses the Redboot vectors that are for a rom startup
> Any possibility that a romram startup is required instead to run this test
> program???? The timeout seems to indicate that something is not fast
> enough?

Unlikely. The timeouts are generous. 5 seconds between retries. After
5 retries for the same block, or 50 retries it total, it gives up.

It seems more likely you are loosing packets somewhere. Try some
simple ping tests to make sure your Ethernet device driver does not
have a problem.

     Andrew


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] Re: timeout in tftp_client_test.c

[HG]

>
> It seems more likely you are loosing packets somewhere. Try some
> simple ping tests to make sure your Ethernet device driver does not
> have a problem.
>
the ping test with redboot is ok : no packet lost

 the ping_test.c  test program output is also ok : no packet lost (see
below)

what I dont understand is that the tftp with redboot works ok on the same
server : I use the redboot : load -m tftp filename  to get the
ping_test.srec file
tftp_client_test.srec (files are about 1 Meg)  from the server but  when an
application
tries it times out after about 3k
from the source code Redboot does not appear do the call tftp_get like the
application
does .
Is there anything special to configure to build the lib that has the freebsd
stack or some other networking
item ????? I will remove kernel instrumentation and asserts & tracing to see
if it improves things.

The redboot build seems to work as it is for networking , can something be
misconfigured to affect the performance of the application ?????

thanks

Henri




output of ping_test.c
PING server 192.168.0.4
64 bytes from 192.168.0.4: icmp_seq=0, time=570ms
310 bytes from 192.168.0.4: icmp_seq=1, time=400ms
556 bytes from 192.168.0.4: icmp_seq=2, time=400ms
802 bytes from 192.168.0.4: icmp_seq=3, time=400ms
1048 bytes from 192.168.0.4: icmp_seq=4, time=400ms
1294 bytes from 192.168.0.4: icmp_seq=5, time=390ms
64 bytes from 192.168.0.4: icmp_seq=0, time=3570ms
310 bytes from 192.168.0.4: icmp_seq=1, time=3010ms
556 bytes from 192.168.0.4: icmp_seq=2, time=2630ms
802 bytes from 192.168.0.4: icmp_seq=3, time=2240ms
1048 bytes from 192.168.0.4: icmp_seq=4, time=1860ms
1294 bytes from 192.168.0.4: icmp_seq=5, time=1460ms
64 bytes from 192.168.0.4: icmp_seq=0, time=4260ms
310 bytes from 192.168.0.4: icmp_seq=1, time=3710ms
556 bytes from 192.168.0.4: icmp_seq=2, time=3330ms
802 bytes from 192.168.0.4: icmp_seq=3, time=2950ms
Sent 16 packets, received 16 OK, 0 bad
....  includes test for a wrong address : all packets are lost
PASS:<Ping test OK>
EXIT:<done>



-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] Re: timeout in tftp_client_test.c

[HG]

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

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

Re: [ECOS] Re: timeout in tftp_client_test.c

[Andrew Lunn]

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

Re: [ECOS] Re: timeout in tftp_client_test.c

[Laurent GONZALEZ]

On Wed, 23 Apr 2003 09:55:47 +0200
Andrew Lunn <andrew.lunn@ascom.ch> wrote:

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

Andrew, you rings me a bell.
I had a similar problem. My guess is that the ethernet driver handles some ring buffer to transmit packets. The size of the ring is 8, thus every 8 packet are the same !

Is Windump able to output the content of the packets ?

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


-- 
GONZALEZ Laurent
Silicomp Research Institute
Tel: 04 76 41 66 98

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] Re: timeout in tftp_client_test.c

[HG]

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

I tried a much larger stack for that thread as an experiment (0x30000
instead of 0x1000):
// Note: the TFTP client calls need at least (SEGSIZE==512)+4
// additional bytes of workspace, thus the padding.
#define STACK_SIZE (CYGNUM_HAL_STACK_SIZE_TYPICAL+0x30000)
still the same problem

>Where is your buf located?
the buf variable in that program are probably located in bss ???  static
char buf[32*1024]; it should be initialised by vectors.s
the pci buffer for the 82559 are located in a pci window at the top of the
16 M workspace declared
to the ecos system , the ldi & h files where hand edited based on an older
version produced with the 1.3 tool version
from ldi file :
......
// space for ethernet buffers = 8
    CYG_LABEL_DEFN(__pci_window) = 0x80ff0000; . =
CYG_LABEL_DEFN(__pci_window) + 0x10000;
    SECTIONS_END
from the h file :
.....
#define CYGMEM_SECTION_heap1 (CYG_LABEL_NAME (__heap1))
#define CYGMEM_SECTION_heap1_SIZE (0x80ff0000 - (size_t) CYG_LABEL_NAME
(__heap1))
#ifndef __ASSEMBLER__
extern char CYG_LABEL_NAME (__pci_window) [];
#endif
#define CYGMEM_SECTION_pci_window (CYG_LABEL_NAME (__pci_window))
#define CYGMEM_SECTION_pci_window_SIZE (0x10000)

from the .inl file in devs/eth/mips/.../include
#define CYGHWR_INTEL_I82559_PCI_MEM_MAP_BASE
(CYGARC_UNCACHED_ADDRESS(0x80ff0000))
#define CYGHWR_INTEL_I82559_PCI_MEM_MAP_SIZE 0x10000

in the config tool :
the 82559 driver tx & rx descriptor are set to 8
in the ecos hal : use separate stack for interrupt , interrupt stack size :
32k , save min context on interrupt
> >

many thanks for the help ,

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

Re: [ECOS] Re: timeout in tftp_client_test.c

[Andrew Lunn]

On Wed, Apr 23, 2003 at 08:11:14AM -0400, HG wrote:
> 
> >
> > 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
> 
> I tried a much larger stack for that thread as an experiment (0x30000
> instead of 0x1000):
> // Note: the TFTP client calls need at least (SEGSIZE==512)+4
> // additional bytes of workspace, thus the padding.
> #define STACK_SIZE (CYGNUM_HAL_STACK_SIZE_TYPICAL+0x30000)
> still the same problem

OK. So the stack is not overflowing...

> 
> >Where is your buf located?
> the buf variable in that program are probably located in bss ???  static
> char buf[32*1024]; 

OK. Good. I just wanted to make sure you had not put it onto the stack!

Im out of ideas. I suggest you scatter a few diag_printf's into the
tftp client code and see if anything obvious is going wrong. 

     Andrew

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

[ECOS] Re: timeout in tftp_client_test.c : case closed

[HG]

I got the test case going by increasing the 82559 tx & rx 'descriptors' to
128 , redoing the memory layout files .ldi .h to use one meg of ram ,
changing the dimensioning of the CYGHWR_INTEL_I82559_PCI_MEM_MAP_BASE
CYGHWR_INTEL_I82559_PCI_MEM_MAP_SIZE  to match the settings of the .ldi & .h
files.

part of output of tftp_client_test.c  when tested on an nt4 server running
the solarwinds.net tftp server :
Trying tftp_get hello.s      192.168.0.4...
res = 29112, err = 0
Trying tftp_put tftp_put      192.168.0.4, length 29112
put - res: 29112 , err = 0

thanks

Henri



-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] Re: timeout in tftp_client_test.c

[HG]

Hi all,


I include a packet capture which better documents the timeout problem
reported previously.
 in sequence we see:

ack of packet 7b to server port 1111 (all is well)

packet 7c sent by server

tftp_get requests an other transfer (broken here)

ack of packet 01 by tftp_get to server port 1111  (really broken this is the
same packet as was sent a long time ago)

server thinks he has an other request :uses port 1113 to send block 1

ack of packet 02 by tftp_get to server port 1111  (really broken this is the
same packet as was sent a long time ago)

ack of packet 03 by tftp_get to server port 1111  (really broken this is the
same packet as was sent a long time ago)
....


anyone has a patch to fix this problem ?????

thanks for any help,

Henri


packet capture (unfortunately the formating by windump was lost in the
cut&paste)  :


08:50:02.282363 IP 192.168.0.4.1111 > 192.168.0.21.7700: udp 516
0x0000  4500 0220 f424 0000 8011 c33e c0a8 0004 E....$.....>....
0x0010  c0a8 0015 0457 1e14 020c 61d5 0003 007b .....W....a....{
0x0020  3030 3030 3331 0d0a 5333 3135 3830 3330 000031..S3158030
0x0030  4431 3443 3846 4246 3030 3043 3846 4232 D14C8FBF000C8FB2
0x0040  3030 3038 3846 4231 3030 3034 3846 4230 00088FB100048FB0
0x0050  3030                                    00
08:50:02.529777 IP 192.168.0.21.7700 > 192.168.0.4.1111: udp 4
0x0000  4500 0020 007f 0000 4011 f8e4 c0a8 0015 E.......@.......
0x0010  c0a8 0004 1e14 0457 000c 5b82 0004 007b .......W..[....{
0x0020  0000 0000 0000 0000 0000 0000 0000      ..............
08:50:02.533421 IP 192.168.0.4.1111 > 192.168.0.21.7700: udp 516
0x0000  4500 0220 f524 0000 8011 c23e c0a8 0004 E....$.....>....
0x0010  c0a8 0015 0457 1e14 020c 0cf6 0003 007c .....W.........|
0x0020  3030 3038 3237 4244 3030 3130 3237 4244 000827BD001027BD
0x0030  4646 4630 3744 0d0a 5333 3135 3830 3330 FFF07D..S3158030
0x0040  4431 4643 4146 4230 3030 3030 4146 4246 D1FCAFB00000AFBF
0x0050  3030                                    00
08:50:02.779266 IP 192.168.0.21.7700 > 192.168.0.4.69:  17 RRQ "hello1.s"
0x0000  4500 002d 0001 0000 4011 f955 c0a8 0015 E..-....@..U....
0x0010  c0a8 0004 1e14 0045 0019 648a 0001 6865 .......E..d...he
0x0020  6c6c 6f31 2e73 004f 4354 4554 0000      llo1.s.OCTET..
08:50:02.780917 IP 192.168.0.21.7700 > 192.168.0.4.1111: udp 4
0x0000  4500 0020 0002 0000 4011 f961 c0a8 0015 E.......@..a....
0x0010  c0a8 0004 1e14 0457 000c 5bfc 0004 0001 .......W..[.....
0x0020  0000 0000 0000 0000 0000 0000 0000      ..............
08:50:02.801852 IP 192.168.0.4.1113 > 192.168.0.21.7700: udp 516
0x0000  4500 0220 f724 0000 8011 c03e c0a8 0004 E....$.....>....
0x0010  c0a8 0015 0459 1e14 020c fa5e 0003 0001 .....Y.....^....
0x0020  5330 3044 3030 3030 3638 3635 3643 3643 S00D000068656C6C
0x0030  3646 3245 3733 3732 3635 3633 3033 0d0a 6F2E7372656303..
0x0040  5333 3135 3830 3330 3830 3030 3430 3141 S31580308000401A
0x0050  3638                                    68
08:50:03.030256 IP 192.168.0.21.7700 > 192.168.0.4.1111: udp 4
0x0000  4500 0020 0003 0000 4011 f960 c0a8 0015 E.......@..`....
0x0010  c0a8 0004 1e14 0457 000c 5bfb 0004 0002 .......W..[.....
0x0020  0000 0000 0000 0000 0000 0000 0000      ..............
08:50:03.031929 IP 192.168.0.21.7700 > 192.168.0.4.1111: udp 4
0x0000  4500 0020 0004 0000 4011 f95f c0a8 0015 E.......@.._....
0x0010  c0a8 0004 1e14 0457 000c 5bfa 0004 0003 .......W..[.....
0x0020  0000 0000 0000 0000 0000 0000 0000      ..............


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss