[bug #24830] Socket never closed sometimes.

[Tony Abou-Assaleh-4]

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

                 Summary: Socket never closed sometimes.
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: onlyslon
            Submitted on: Чтв 13 Ноя 2008 16:55:54
                Category: TCP
                Severity: 3 - Normal
              Item Group: None
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release:
            lwIP version: CVS Head

    _______________________________________________________

Details:

Hello, I use lWip from Linux.

Sometimes there is the strange behavior of the socket.

Following the closure of the socket, he turns state FIN_WAIT_2 but never
switch to TIME_WAIT or CLOSE_WAIT.

Stack infinitely (Observed 15-20 minutes) sends tcp data.

21:23:41.801474 IP 66.249.89.10.80 > 82.18.19.2.3793: . ack 1 win 11957
21:23:41.802483 IP 82.18.19.2.3793 > 66.249.89.190.80: . ack 1 win 0
21:23:43.250143 IP 66.249.89.190.80 > 82.18.19.2.3793: . ack 1 win 11957
21:23:43.250395 IP 82.18.19.2.3793 > 66.249.89.190.80: . ack 1 win 0

       
Unfortunately, I failed to record the entire session. This behavior occurs
infrequently.

Perhaps a bug occurs because I use self-tuned lwipopts.h.





    _______________________________________________________

File Attachments:


-------------------------------------------------------
Date: Чтв 13 Ноя 2008 16:55:55  Name: lwip.pcap  Size: 2kB   By:
onlyslon

<http://savannah.nongnu.org/bugs/download.php?file_id=16841>

    _______________________________________________________

Reply to this item at:

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

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



_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

[Tony Abou-Assaleh-4]

Follow-up Comment #1, bug #24830 (project lwip):

Looks like one end (not sure which, you don't say which is lwIP) has
advertised a zero window and is refusing to open it.  This is probably
preventing the other end from sending a FIN, and so the connection never gets
closed.  If you can get a packet capture for the whole duration that would be
useful.

You say you're using lwIP from CVS head.  Does that mean it is your own port,
or you're using one of the existing ports?

My guess would be that lwIP is running out of memory due to a bug that is
resulting in packet buffers getting leaked.  You could confirm this by turning
on the lwIP stats and seeing what happens to the available memory when they
are reported.

    _______________________________________________________

Reply to this item at:

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

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



_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

[Tony Abou-Assaleh-4]

Follow-up Comment #2, bug #24830 (project lwip):

I am sorry that did not specify some details.

I use existing  linux port.

lwIP - works as HTTP client and has address 82.18.19.2

For memory management I use libc (MEM_LIBC_MALLOC option).
As I understand limitations of memory with this option does not work.

This behavior occurs most often with only one socket, the remainder continued
to work without visible problems.

I will try to fully record the session ASAP.

    _______________________________________________________

Reply to this item at:

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

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



_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

[Tony Abou-Assaleh-4]

Follow-up Comment #3, bug #24830 (project lwip):

A full session is in Attacements.

(file #16846)
    _______________________________________________________

Additional Item Attachment:

File name: gmaps.raw                      Size:25 KB


    _______________________________________________________

Reply to this item at:

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

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



_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

[Tony Abou-Assaleh-4]

Update of bug #24830 (project lwip):

         Planned Release:                         => 1.3.1                  

    _______________________________________________________

Follow-up Comment #4:

Sorry for the delay in responding to this.

There is no IP address 82.18.19.2 in the trace, but I'm assuming you meant
192.66.66.3 (the HTTP client)

The client makes an HTTP request, but then sends a FIN before the server has
finished sending it.  This means the client has nothing more to send to the
server, but the server is still allowed to send to the client.  The server
continues to send the requested file, but the client does not provide any more
window.  This is not all that surprising: the application thinks it has closed
this socket, and so won't be reading from it, and so the window does not get
replenished.

It is right that the stack has gone into FIN_WAIT_2, and is waiting for the
other side to send FIN before continuing to TIME_WAIT and CLOSED.

The traffic you see at the end is the server using the TCP keep alive
protocol to probe the connection to see if the other end is still there.  This
is also fine.

What is wrong is that lwIP should have sent a RST to close the connection
rather than a FIN if there were any data queued for the client when it called
close, and/or it should have sent a RST when it received data after the
connection had been closed.  This tells the other end that no further data
will reach the client application.

The fix for this should be relatively straightforward.  It would be good to
retain the current behaviour as that is what is needed for shutdown() rather
than close(), and although we provide shutdown() in the API it's not
separately implemented.

Thanks for spotting this.

    _______________________________________________________

Reply to this item at:

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

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



_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

[Tony Abou-Assaleh-4]

Update of bug #24830 (project lwip):

             Assigned to:                    None => kieranm                


    _______________________________________________________

Reply to this item at:

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

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



_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

[Tony Abou-Assaleh-4]

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

Now I come to think about how to fix this, there is a minor problem: data can
be buffered on RX at lots of levels in the stack (within the TCP layer,
netconn layer, and sockets layer).  Therefore tcp_close() needs to know if
there are any bytes buffered in the higher layers, but it would be hard for it
to work this out.  I therefore think adding a parameter that gets filtered
down through the layers that says "there is buffered data in the layer(s)
above", and then passed to netconn_delete() and tcp_close() would be a good
idea.  However, this changes the API and so causes problems that way.

It would be fairly simple to alias the existing API functions to the new
ones, eg:
#define tcp_close(pcb) tcp_close_new(pcb, 0)
#define netconn_delete(conn) -> netconn_delete_new(conn, 0)
(I would choose better names than *_new() - any suggestions?)

This would result in minimal extra code, and keeps the API backwardly
compatible, but is a bit ugly in the long term.  

    _______________________________________________________

Reply to this item at:

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

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



_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

[JamminJimP]

 
Couldn't the netconn just call tcp_abort in this case?
 
__
 
James M. Pettinato, Jr.
Software Engineer
E: jim.pettinato@... | P: 814 898 5250

FMC Technologies Measurement Solutions Inc.
1602 Wagner Avenue | Erie PA | 16510 USA
Phone: [phone] | Fax: [phone]
www.fmctechnologies.com

 

-----Original Message-----
From: lwip-devel-bounces+jim.pettinato=fmcti.com@...
[mailto:lwip-devel-bounces+jim.pettinato=fmcti.com@...] On Behalf
Of Kieran Mansley
Sent: Tuesday, March 31, 2009 11:03 AM
To: Kieran Mansley; Homyak; lwip-devel@...
Subject: [lwip-devel] [bug #24830] Socket never closed sometimes.


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

Now I come to think about how to fix this, there is a minor problem:
data can be buffered on RX at lots of levels in the stack (within the
TCP layer, netconn layer, and sockets layer).  Therefore tcp_close()
needs to know if there are any bytes buffered in the higher layers, but
it would be hard for it to work this out.  I therefore think adding a
parameter that gets filtered down through the layers that says "there is
buffered data in the layer(s) above", and then passed to
netconn_delete() and tcp_close() would be a good idea.  However, this
changes the API and so causes problems that way.

It would be fairly simple to alias the existing API functions to the new
ones, eg:
#define tcp_close(pcb) tcp_close_new(pcb, 0) #define
netconn_delete(conn) -> netconn_delete_new(conn, 0) (I would choose
better names than *_new() - any suggestions?)

This would result in minimal extra code, and keeps the API backwardly
compatible, but is a bit ugly in the long term.  

    _______________________________________________________

Reply to this item at:

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

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



_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel


_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

[Tony Abou-Assaleh-4]

Update of bug #24830 (project lwip):

         Planned Release:                   1.3.1 => 1.4.0                  

    _______________________________________________________

Follow-up Comment #6:

I think that as this potentially involves changes to the lwIP API we'd be
better postponing the fix till 1.4.0

    _______________________________________________________

Reply to this item at:

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

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



_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

[Tony Abou-Assaleh-4]

Follow-up Comment #7, bug #24830 (project lwip):

I think I have accidentally fixed part of the problem here: TCP_EVENT_RECV()
did not call tcp_recved() if pcb->recv was NULL (which it is after closing a
socket), which means the window closes eventually and doesn't reopen.

Another part of the problem (data being buffered in recvmbox but tcp_recved()
isn't called when this data is freed) is covered by the patch for bug #26672
(close connection when receive window = 0).

However, the real flaw here is that we haven't implemented close vs. shutdown
correctly. I agree that, with a complete close, lwIP should send RST when more
data arrives.

However, I regard this bug as a duplicate to bug #26672, which has a better
description of the problem.

    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Nachricht geschickt von/durch Savannah
  http://savannah.nongnu.org/



_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel