[Top][All Lists]

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

[lwip-devel] [bug #50837] LWIP TCP/IP race condition

From: Joel Cunningham
Subject: [lwip-devel] [bug #50837] LWIP TCP/IP race condition
Date: Sun, 23 Apr 2017 10:42:11 -0400 (EDT)
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/603.1.30 (KHTML, like Gecko) Version/10.1 Safari/603.1.30

Follow-up Comment #11, bug #50837 (project lwip):


I reviewed RFC 5961, section 3.2 and our implementation follows the
specification so I'm not sure why Windows did not respond to the challenge

There was one remaining piece of this that didn't make sense.  With sockets
and TCP you always have the chance of ending up with a half-open connection if
you aren't sending on the socket.  In this case, the server ends up with the
connection half open, but is constantly sending.  Even if Windows responded to
the ACK containing an RST with SEQ = RCV.NXT, it could be dropped in transit
and again we'd have a half open connection (but still sending).

I reviewed the wireshark log again and this time I think the server
encountered an effective zero window, but not the client.  If you see packet
#324, the reported window from the client drops to 320, which is below 464
(the server's segment size).  LwIP won't segment the next 464 byte segment and
we effectively have a zero window.  After this the server never sends another
data segment.

LwIP 2.0.0 didn't have the fix to start the persistent timer in this case


Can you pull up to 2.0.1 at least and try to reproduce this?


Reply to this item at:


  Message sent via/by Savannah

reply via email to

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