[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: preet
Subject: [lwip-devel] [bug #50837] LWIP TCP/IP race condition
Date: Thu, 20 Apr 2017 15:12:53 -0400 (EDT)
User-agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36


                 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



LWIP race condition:

Consider a TCP/IP CLIENT connected to LWIP TCP/IP server:
    while True:
Meanwhile, the LWIP TCP/IP server, after accepting the connection is doing:

    // Socket is in blocking mode
    send(client_sock, foo_string, 128, no_flags);

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

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


Reply to this item at:


  Message sent via/by Savannah

reply via email to

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