[lwip-users] Re: curious large packets and transmit stuck

[Andre Puschmann]

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