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

[preet]

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

                 Summary: LWIP TCP/IP race condition
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: preetpal
            Submitted on: Thu 20 Apr 2017 07:12:52 PM UTC
                Category: TCP
                Severity: 3 - Normal
              Item Group: Faulty Behaviour
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None
            lwIP version: 2.0.0

    _______________________________________________________

Details:

LWIP race condition:

Consider a TCP/IP CLIENT connected to LWIP TCP/IP server:
    while True:
        send(data_128)
        time.sleep(.1)
                
Meanwhile, the LWIP TCP/IP server, after accepting the connection is doing:

while(1)
{
    // Socket is in blocking mode
    send(client_sock, foo_string, 128, no_flags);
    recv(all);
}

In this situation, the CLIENT's OS is shrinking its TCP/IP WINDOW size because
its application is not pulling any data out of the socket (it is only
transmitting).  Meanwhile, the LWIP SERVER is continuing to send data to the
CLIENT until its window doesn't allow it any longer.

The Wireshark trace shows that the LWIP SERVER starts to send zero byte
packets and the CLIENT responds with an ACK with the PSH flag set.  There are
about 10 of these packets until the CLIENT just gives up and it's application
terminates.

While this was occuring, the "Mbox" error counts are going up to indicate that
the LWIP SERVER is trying to send the data.  But while these errors have
occurred, the CLIENT's RST/ACK packet with the FYN was dropped and could not
be queued onto the socket's mailbox.

So, we end up with a zombie socket, which is trying to send the data in
blocking mode, and is never successful.  In this state, the rest of the LWIP
stack is working fine, however, the "Mbox" error count continues to go up
(forever), particularly related to this socket.

I believe there is a race condition in the stack when using the blocking mode.
 As a workaround, we enabled 5 second timeout on every socket, and after 5
seconds, it times out and the zombie socket is able to closed and re-open
later.




    _______________________________________________________

Reply to this item at:

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

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