hi kieran, here are my lwip opts.h and one trace using the netconn-api and another one using the raw api .. if you have a look at the first trace (netconn) you can see that the packets slowly dropping out/in .. it seems that lwip "forgets" acks the other end send. you can't see the large packets directly, i mean there is one large and another small one, but before the stuck all packets were 1000bytes long. so it seems that it has something to do with that. if i use the raw api there are no "large" packets .. since as long as lwip has something to send it sends packet with max size (1456byte). but nevertheless, after a while the whole system shows the same behavior.
do you think it has something to do with my timer/semaphore/mbox implementation? many thanks andre 1: http://www.puschmann.net/public/dropping_packets_rawapi.cap 2: http://www.puschmann.net/public/large_and_small_packet.cap 3: http://www.puschmann.net/public/opt.h Kieran Mansley wrote: > On Tue, 2007-01-30 at 21:56 +0100, Andre Puschmann wrote: >> i am aware of this fact. the curious thing IMO is the correlation >> between the occurrences of this "larger packets" and the stuck of the >> whole stack. > > Sounds like you may either have a locking problem (the usual cause of > deadlock) or possibly a resource allocation issue. Is lwIP sending or > receiving the large packet? Could you get a packet trace using > something like ethereal? Your lwipopts.h configuration might throw some > light on the problem too. > > Kieran _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
