Re: [lwip-users] zero window probe causes duplicated byte to be received

2017-04-01 Thread Yao Lin
Thanks Joel. In case you find that bug, could you inform me.



--
View this message in context: 
http://lwip.100.n7.nabble.com/zero-window-probe-causes-duplicated-byte-to-be-received-tp29221p29223.html
Sent from the lwip-users mailing list archive at Nabble.com.

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


Re: [lwip-users] zero window probe causes duplicated byte to be received

2017-04-01 Thread Joel Cunningham
There was a bug where send_nxt was not advanced during the zero window probe 
and thus the zero window probe ACK caused LwIP to send back another ACK, 
creating an ACK storm. This has been fixed on master. I can dig up the bug 
report if you need it (away from git history at the moment)

Even with this fixed, you'll still see some of the behavior you described about 
repeating the same probe byte even if the remote side ACKs it. This is because 
LwIP can't send or ACK a partial segment, only the full segment. Once the 
window opens back up, the probe byte will be sent again as part of the full 
segment. Wireshark typically marks it as a retransmission 

Joel 

> On Apr 1, 2017, at 17:33, Yao Lin  wrote:
> 
> Hi,
> 
> I am using Stable 1.4.1 in my device. This device sends 4MB of TCP data to a
> Windows laptop. I am using netcomm API.
> 
> 1. When Windows is about to use up its TCP buffer, it sends a packet (P1)
> with rwnd = 0 and ACK to, say, 2M.
> 2. Within 0.12s after receiving P1, lwip sends a packet (P2) with seq = 2M
> and len = 1.
> 3. Windows sends P3 with ACK = 2M + 1 and rwnd = 0.
> 4. Now we go through many iterations of 4.1 and 4.2:
>4.1. lwip sends P4 with seq = 2M and len = 0.
>4.2. Windows sends P5 with ACK = 2M + 1 and rwnd = 0.
> 5. Eventually, Windows opens up its rwnd. So it sends P6 with ACK = 2M + 1
> and rwnd = 4096 (or something similar).
> 6. Lwip sends P7 with seq = 2M and len = 1460.
> 
> Now you can see Windows receives the duplicated byte 2M.
> 
> So my question is, why does lwip send P4 and P7 with seq = 2M instead of 2M
> + 1? Note that Windows ACK = 2M + 1 in P3, P5, and P6.
> 
> Thanks.
> 
> 
> 
> 
> --
> View this message in context: 
> http://lwip.100.n7.nabble.com/zero-window-probe-causes-duplicated-byte-to-be-received-tp29221.html
> Sent from the lwip-users mailing list archive at Nabble.com.
> 
> ___
> lwip-users mailing list
> lwip-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users

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


[lwip-users] zero window probe causes duplicated byte to be received

2017-04-01 Thread Yao Lin
Hi,

I am using Stable 1.4.1 in my device. This device sends 4MB of TCP data to a
Windows laptop. I am using netcomm API.

1. When Windows is about to use up its TCP buffer, it sends a packet (P1)
with rwnd = 0 and ACK to, say, 2M.
2. Within 0.12s after receiving P1, lwip sends a packet (P2) with seq = 2M
and len = 1.
3. Windows sends P3 with ACK = 2M + 1 and rwnd = 0.
4. Now we go through many iterations of 4.1 and 4.2:
4.1. lwip sends P4 with seq = 2M and len = 0.
4.2. Windows sends P5 with ACK = 2M + 1 and rwnd = 0.
5. Eventually, Windows opens up its rwnd. So it sends P6 with ACK = 2M + 1
and rwnd = 4096 (or something similar).
6. Lwip sends P7 with seq = 2M and len = 1460.

Now you can see Windows receives the duplicated byte 2M.

So my question is, why does lwip send P4 and P7 with seq = 2M instead of 2M
+ 1? Note that Windows ACK = 2M + 1 in P3, P5, and P6.

Thanks.




--
View this message in context: 
http://lwip.100.n7.nabble.com/zero-window-probe-causes-duplicated-byte-to-be-received-tp29221.html
Sent from the lwip-users mailing list archive at Nabble.com.

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


Re: [lwip-users] lwip FreeRTOS tcp window

2017-04-01 Thread Joel Cunningham

> On Apr 1, 2017, at 7:25 AM, Mohamed Hnezli  wrote:
> 
> Thank you for support,  
> Are there any way to change this, such as 1 ack for 5 TCP segments sent from 
> client (lwip)

What you referring to is a stretch ACK (where the ACK covers more than 1 full 
sized segment).  This is not configurable and stretching more than the 2 
maximum sized segments allowed by delayed ACKs algorithm is a violation of RFC 
1122  (see 4.2.3.2 When to Send an ACK 
Segment).

If you’re trying to tune the TCP performance from the sender’s side, stretching 
ACKs (on the receiver) will not improve performance.  Have you looked into 
tuning your send buffer (TCP_SND_BUF) given your bandwidth product delay?

Joel

> 
> On 31 March 2017 at 19:10, goldsi...@gmx.de  
> > wrote:
> Mohamed Hnezli wrote:
> 
> I am using lwip ontop of FreeRTOS to send data to a server. I am trying to 
> maximize the data flow. I've tuned several paramerters in "lwipopts.h" but I 
> am always receiving an ACK after emitting only two packets.
> 
> 
> That's just TCP. The window size does not have any influence about the number 
> of ACKs and normally, an ACK for every 2nd data segment is the default.
> 
> Simon
> 
> ___
> lwip-users mailing list
> lwip-users@nongnu.org 
> https://lists.nongnu.org/mailman/listinfo/lwip-users 
> 
> 
> 
> 
> -- 
> Mohamed HNEZLI
> Computer Science Engineer Student
>   NSCS_Tunisia
> ___
> lwip-users mailing list
> lwip-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users

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

Re: [lwip-users] lwip FreeRTOS tcp window

2017-04-01 Thread Mohamed Hnezli
Thank you for support,
Are there any way to change this, such as 1 ack for 5 TCP segments sent
from client (lwip)

On 31 March 2017 at 19:10, goldsi...@gmx.de  wrote:

> Mohamed Hnezli wrote:
>
>>
>> I am using lwip ontop of FreeRTOS to send data to a server. I am trying
>> to maximize the data flow. I've tuned several paramerters in "lwipopts.h"
>> but I am always receiving an ACK after emitting only two packets.
>>
>>
> That's just TCP. The window size does not have any influence about the
> number of ACKs and normally, an ACK for every 2nd data segment is the
> default.
>
> Simon
>
> ___
> lwip-users mailing list
> lwip-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users
>



-- 
Mohamed HNEZLI
Computer Science Engineer Student
  NSCS_Tunisia
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Connect two machines running LWIP applications via WLAN

2017-04-01 Thread Dirk Ziegelmeier
http://serverfault.com/questions/152363/bridging-wlan0-to-eth0


Ciao
Dirk
>
> https://lists.nongnu.org/mailman/listinfo/lwip-users
>
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users