I didn't see any details on what driver/hardware/os you're using, so I'm making an educated guess...
The problem you describe could potentially be a problem within the driver. I could see a scenario where the driver fails to send/transmit any data because, say, there are no transmit buffers available. In this case the driver would fail to send, but be unable to notify that data was sent, depending on the implementation of the low level driver/stack interface. In this case, the stack could be caught in some undefined state. The receipt of the ping triggers a transmit, and an interrupt, and perhaps some other events, depending on the implementation, that could cause operation to resume, but you'd probably see that some packets were lost. I'd make sure that the driver send call never returns an error condition. As a simple test, try increasing the size of the transmit queue, or whatever you use, for the driver. You could also increase the size of the PBUF_POOL_BUFSIZE option, so that the depth of the buffer chain sent to the driver is shorter. This could result in fewer transmit buffers being used, depending on your implementation of course. -Thomas -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andre Puschmann Sent: Sunday, February 04, 2007 12:06 PM To: [email protected] Subject: [lwip-users] Re: curious large packets and transmit stuck hey guys, another thing that maybe brings a bit more light is the following. once the stack is as slow i can burst the things up for another ~300 packets with a single ping. after that burst transmission is slow again. but i can do this "trick" again and again. i already checked the timer function but they are called frequently. what can a single ping packet activate in the stack (or its helper functions)?? any hints?? best regards, andre Andre Puschmann wrote: > 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 _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
