[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: Thu, 20 Apr 2017 15:30:56 -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 #1, bug #50837 (project lwip):

Hi preet, couple of questions about your scenario:

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

Are you seeing mbox errors on the server?  I don't believe mboxes are used in
the transmit path.  The recvmbox used in the receive path should only contain
data, so things like an empty ACK or RST shouldn't end up in the mbox

> So, we end up with a zombie socket, which is trying to send the data in
blocking mode, and is never successful.

Once the client exited, I would expect each following zero-window probe to be
received by the client and have an RST generated in response.  Is this not the
case?  Or does the server not process the RST in this case (could be a bug)?


Reply to this item at:


  Message sent via/by Savannah

reply via email to

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