[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-users] TCP: ACK problem?
Re: [lwip-users] TCP: ACK problem?
Tue, 27 Aug 2013 12:48:31 +1200
Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
Andre replied to me directly. I've explained to him how to join the
mailing list and do this properly, but in the meantime, I've attached a
copy of his lwipopts.h and my subsequent reply follows, in the hope that
others can add their comments on the problem.
A second opinion from someone more familiar with the LWIP memory
allocator (we use a custom one so I haven't looked at LWIP's one in
detail) and your particular target's network driver would be helpful,
but from a quick look I think my theory about running out of pbufs is on
the right track.
Your PBUF_POOL_SIZE is only 6. Depending on the implementation of your
network driver and application, this pool may be used to store both
received packets and packets which are copied for transmission by
With only 6 pbufs available for allocation and 3 of them occupied by
unacknowledged outgoing packets, you would only need 3 more allocated
anywhere else in the system to have none left for processing receive
packets, resulting in your network driver discarding all incoming
packets rather than being able to deliver them to ip_input().
As I alluded to in my first message, you should be able to confirm this
by looking at the data generated by LWIP_STATS and see if you are
getting memory allocation errors for the MEMP_PBUF_POOL type of memory
pool, which go up each time another packet is received if I'm right. To
see the error counting logic, follow the code through from
pbuf.c:pbuf_alloc() to memp.c:memp_malloc(), with reference to stats.h.
If that error is confirmed, you will need to identify where the other
three pbufs have got to and/or limit the number of consecutive calls you
make to tcp_write() whiledata has been acknowledged and/or increase
PBUF_POOL_SIZE (which would result in lwip being allocated more memory
overall), or come up with some other strategy to limit the conflicting
On 2013-08-21 20:54, André P. wrote:
> Hi David,
> Thank you for your fast response. I have attached my lwipopts.h file.
On 2013-08-21 14:46, David Empson wrote:
On 2013-08-21 03:45, André P. wrote:
I have an application where I stream data regularly from an LPC board to
a laptop. This works fine, until after some time the transmitter sends
two packets without waiting for an ACK, and the receiver almost
immediately acknowledges both using one packet. Somehow, the LWIP stack
does not accept this ACK, and keeps resending a package. I have attached
the Flow Graph. Why does LWIP not accept the ACK message 166213? It
keeps resending Seq 162622.
I am using LWIP 1.4.0. Thank you for your support.
The pattern looks like LWIP stopped processing the received ACK packets
after the one with Ack=162622. LWIP subsequently sent three packets with
new data (162622, 163648 and 165108), then timed out waiting for the ack
for the oldest unacknowledged packet (162622), resending it with slowing
retries: 1 second delay, then 3, 6, 12, 24, 48; all the subsequent ACKs
were not processed.
You'll probably need to look at LWIP's internal error counts to confirm
this, but my guess is that you ran out of pbufs, due to having three
outgoing packets occupying all remaining pbufs, and none are left to
store the received ACKs. If so, you need to allocate more pbufs and/or
limit the amount of transmit data you can have outstanding to ensure
there will always be free buffers for received packets.
A copy of your lwipopts.h might help to analyse the problem.
lwip-users mailing list
Description: Text document