[lwip-users] TCP windows Full

[brak brak2]

Hi,

I hava a problem with delays caused by TCP windows Full. I attached a
wireshark pcap file. At the end of file you can see that there is 5
second delay, because computer (IP 192.168.0.58) is waiting for the
unit with lwip 1.4.0 (IP 192.168.0.211) for a windows update packet.
But lwip doesn't send one. Some packets earlier you can see that unit
has send windows update packets.

What can by cause that lwip doesn't send windows update packets? I
think I call tcp_recved for whole received data. I've also protected
my program from multithreating.

Best regards
Tomasz

[Kieran Mansley]

On Mon, 2011-07-11 at 13:43 +0200, brak brak2 wrote:
> What can by cause that lwip doesn't send windows update packets?

Lack of pbufs to send a packet? An error called tcp_recved() (although
you say this is not the problem)? The fact that even after a long idle
period the advertised window is not getting back to 4096 (its starting
value) suggests to me that there could well be a problem with your use
of tcp_recved().

For full details of when lwIP will send an explicit window update, take
a look at the source (start in tcp_recved()), but to summarise: if we
can increase the advertised window by a significant amount (e.g. 1 MSS)
then we do.

Kieran

_______________________________________________
lwip-users mailing list
lwip-...@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

[brak brak2]

> Lack of pbufs to send a packet?

How can I check pbuf availability?

I release pbuf of received package until I process whole received data.
Then I call pbuf_free:
SYS_ARCH_PROTECT(lev);
pbuf_free(gpBufsToRelease[i]); //pointer to received data pbuf
SYS_ARCH_UNPROTECT(lev);

>  An error called tcp_recved() (although
> you say this is not the problem)?
> The fact that even after a long idle
> period the advertised window is not getting back to 4096 (its starting
> value) suggests to me that there could well be a problem with your use
> of tcp_recved().

I call tcp_recved for every processed pbuf in the received data chain.
It looks like this in log:
Package received: 1460 //total among of received data in tcp_recv
Package received: 1460
tcp_recved called: 202 //among of data in tcp_recved call
tcp_recved called: 256
tcp_recved called: 256
tcp_recved called: 256
Package received: 951
tcp_recved called: 256
tcp_recved called: 234
tcp_recved called: 202
tcp_recved called: 256
tcp_recved called: 256
tcp_recved called: 256
tcp_recved called: 256
tcp_recved called: 234
tcp_recved called: 202
tcp_recved called: 256
tcp_recved called: 256
tcp_recved called: 237

The call of recved is surrounded with protecting code:

SYS_ARCH_PROTECT(lev);
tcp_recved(gTcpRecAck[i].pcb, gTcpRecAck[i].length);
SYS_ARCH_UNPROTECT(lev);

So no lwip core code could interrupt execution of tcp_recved.

> For full details of when lwIP will send an explicit window update, take
> a look at the source (start in tcp_recved()), but to summarise: if we
> can increase the advertised window by a significant amount (e.g. 1 MSS)
> then we do.

But it is done only in recved or is it check in one of the timer also?

Best regards
Tomasz

[Kieran Mansley]

On Tue, 2011-07-12 at 08:55 +0200, brak brak2 wrote:
> > Lack of pbufs to send a packet?
>
> How can I check pbuf availability?

The LWIP_STATS code is the easiest way to discover if you're running out
of some resource.

As long as you call tcp_recved() with the correct total number of bytes,
it should behave properly. You don't need to call it separately for
each pbuf. You could try putting some debug print statements in
tcp_recved() to see how much data it thinks is still being used by the
application and receive queue, and compare that to what you think should
be the case.

> > For full details of when lwIP will send an explicit window update, take
> > a look at the source (start in tcp_recved()), but to summarise: if we
> > can increase the advertised window by a significant amount (e.g. 1 MSS)
> > then we do.
>
> But it is done only in recved or is it check in one of the timer also?

Only in tcp_recved() as this is the only place where the advertised
window is increased. If we called it from a timer later on it would
just give the same answer, as without another call to tcp_recved() there
would be no more window available.

Kieran

[brak brak2]

> As long as you call tcp_recved() with the correct total number of bytes,
> it should behave properly.  You don't need to call it separately for
> each pbuf.  You could try putting some debug print statements in
> tcp_recved() to see how much data it thinks is still being used by the
> application and receive queue, and compare that to what you think should
> be the case.

It's not a problem of lwIP. I had an error in my code. Function that
should process the data stalled for too long and another module raised
timeout.
Sorry for premature question.

Thanks for help.
Best regards
Tomasz