Re: [lwip-users] Deciphering WireShark

[Kieran Mansley]

On Fri, 2011-01-07 at 09:30 +1100, address@hidden wrote:
> The attached WireShark capture shows some oddity at the first HTTP
> GET 
> request and while a page is eventually delivered there are a number
> of 
> stumbles which lengthens the delivery time. I am hoping for a few 
> pointers to at least understand what is happening.

Something is dropping some of the packets that are being sent by lwIP.
I have a hunch that this might be happening when lwIP has more than one
packet to send, as the cases where packets are dropped and retransmitted
after a delay seem only to happen where after the retransmission lwIP
can immediately send more data.

Could it be that something isn't correctly dealing with pbuf chains?
For example, if a send was too large for a single pbuf, and so spanned
multiple ones, what would your driver do with it?  Would it correctly
use tot_len and next fields to traverse the chain and send each section?

Perhaps this isn't the problem in your case though, as I would expect it
to send the first pbuf and drop the rest, whereas it seems to be sending
the later pbuf, and dropping the contents of the first.

In that case could something be overwriting a buffer that is already in
use?  e.g. if two packets are sent in quick succession (before the first
completes) does your driver re-use a DMA buffer for the second, and so
overwrite the data of the first?  Or the application re-use a pbuf where
it shouldn't.  Again this doesn't quite fit as we might then expect to
see two copies of the second packet, and there is only one in the trace.

I would suggest turning on LWIP_STATS code and seeing if there is a
resource shortage that could explain it.  Make sure your application
code is rigorously checking error codes from the lwIP calls it makes to
send data in case one of the calls is returning an error that would
explain the problem but it is being ignored.

Let us know what you find out.  With more information we might be able
to get closer to the problem.

Kieran