Date: Mon, 5 Feb 2007 20:11:15 -0600
From: "Taranowski, Thomas \(SWCOE\)" <[hidden email]>
Subject: RE: [lwip-users] Re: curious large packets and transmit stuck
To: "Mailing list for lwIP users" <[hidden email]>
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.
From: lwip-users-bounces+thomas.taranowski=[hidden email] [mailto:lwip-users-bounces+thomas.taranowski=[hidden email]]
On Behalf Of Andre Puschmann
Sent: Sunday, February 04, 2007 12:06 PM
To: [hidden email] Subject: [lwip-users] Re: curious large packets and transmit stuck
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
Andre Puschmann wrote:
> hi kieran,
> here are my lwip opts.h and one trace using the netconn-api and
> 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
> 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
> 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).
>>> 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
>> receiving the large packet? Could you get a packet trace using
>> something like ethereal? Your lwipopts.h configuration might throw
>> light on the problem too.
End of lwip-users Digest, Vol 42, Issue 5
This email (including any attachments) is intended for the sole use of the intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or distribution or forwarding of any or all of the contents in this message is STRICTLY PROHIBITED. If you are not the intended recipient, please contact the sender by email and delete all copies; your cooperation in this regard is appreciated.