[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

SV: [lwip-users] TCP problem

From: Jan Wester
Subject: SV: [lwip-users] TCP problem
Date: Mon, 19 Oct 2009 10:52:47 +0200

Hi Kieran
I have added capture files for both version 1.3.0 and 1.3.1, it is the same 
application running for both with same lwipopts.h

I have also test it with TCP_WND_UPDATE_THRESHOLD = 0, and it will not help

My application poll every 500ms and get a response for each poll, with version 
It put many polls together after a delay, and the response is corrupted

Any solutions ?

Med vänliga hälsningar/Best Regards
Jan Wester

WHI Konsult AB
Scheelegatan 11, SE-112 28 Stockholm
+46 8 449 05 30
+46 705 36 77 22

-----Ursprungligt meddelande-----
Från: address@hidden [mailto:address@hidden För Kieran Mansley
Skickat: den 14 oktober 2009 16:54
Till: Mailing list for lwIP users
Ämne: Re: [lwip-users] TCP problem

On Wed, 2009-10-14 at 16:21 +0200, Jan Wester wrote:
> Hi
> I’m using lwip 1.3.0 and updated to 1.3.1 and found problem with
> window size
> I receive small blocks of data (30 bytes) every 500 ms and on each I
> call tcp_recved()
> On version 1.3.0 the window size on tcp ack is 512 (what is my
> maximum), 
> but for version 1.3.1 the window size Is decreased with the received
> 30 until the size is less and it wait short time,
> after that the window size is 512 again and it continue. This is
> repeated the hole time (I’m using the same application)

Could you illustrate this with a packet capture?

It sounds like you've got TCP_WND set to 512.  It would be interested to
know what your MTU and MSS is configured at, as having a window smaller
than the MSS is not optimal.  For example, this bug illustrates how a
window that is always smaller than the MSS can cause problems:


NB. I don't think that is your problem, but may be of interest.

The window advertisement code was re-worked in 1.3.1 to only send an
explicit update when the change in window is greater than 
TCP_WND_UPDATE_THRESHOLD.  This defaults to (TCP_WND / 4). You could
define this to be zero to get the old behaviour, but the new behaviour
should be much better.  I would be interested to know what the problem
you encounter as a result of the less-frequent window updates is.  Note
that any ACKs for data that get returned should have the up-to-date
window information in them - it is only the sending of explicit window
update ACKs that is restricted.


lwip-users mailing list

Attachment: version 1.3.0
Description: Binary data

Attachment: version 1.3.1
Description: Binary data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]