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

[Joel Cunningham]

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

Simon,

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
ACK.

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
(https://savannah.nongnu.org/bugs/?49533).

Preet,

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

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?50837>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/