[lwip-devel] [bug #46701] Non-standard close behavior can result in socket/netconn leaks

[Joel Cunningham]

Follow-up Comment #5, bug #46701 (project lwip):

Simon,

Here's the appropriate text.  It's located under the section on SO_LINGER (7.5
Generic Socket Options):

"This option specifies how the close function operates for a
connection-oriented protocol (e.g., for TCP and SCTP, but not for UDP). By
default, close returns immediately, but if there is any data still remaining
in the socket send buffer, the system will try to deliver the data to the
peer.

The SO_LINGER socket option lets use change this default..."

I agree with you that the ideal behavior would be for LwIP to initiate an
asynchronous closure and return caller immediately, even when we can't send a
FIN because the send buffer is full.

In my patch, I removed the non-blocking case because my applications are
expecting the default close behavior as described by Stevens and won't call
close again if it receives EWOULDBLOCK.  It was better to block the caller for
a couple of milliseconds for an ACK to come in and the send buffer to open up,
allowing LwIP to send a FIN and successfully initiate the closure, rather than
leak the socket.

My comment #2 describes a case where during the caller being blocked, trying
to initiate a closure (current LwIP behavior), a RST comes in and generates an
error.  This causes the blocking close to return, but with an error, so it
leaks the netconn and socket.

I don't think my change to free the socket/netconn is too early because once
the non-blocking behavior has been disabled, the call to close either
completes successfully or times out.  Either case the PCB should be freed by
the time we are returning the caller.  This is just a work-around and if the
final solution we want to leave those intact during the asynchronous closure,
that's fine as long as the responsibility has been removed from the
application.

These issues are seen with the default close behavior.  I have not enabled
SO_LINGER support in my port, but care should be taken to make sure we
continue adhering to standard SO_LINGER behavior.  The winsock documentation
has a nice little table describe the closure behaviors (default and
SO_LINGER):
https://msdn.microsoft.com/en-us/library/windows/desktop/ms737582%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396

    _______________________________________________________

Reply to this item at:

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

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