[lwip-devel] [bug #36167] tcp server crash when client closes

[christian]

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

                 Summary: tcp server crash when client closes
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: xtian
            Submitted on: vie 13 abr 2012 14:45:41 GMT
                Category: TCP
                Severity: 3 - Normal
              Item Group: Crash Error
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: 
            lwIP version: 1.4.0

    _______________________________________________________

Details:

Hi all:

We have a ftp server implementation that uses lwip as stack. When the server
has the connection stablished and the client (on a different linux host)
closes the socket, the lwip stack receives the FIN flag and the state machine
goes to close-wait. However, the stack fails in an assert in the tcp_recved
function:

LWIP_ASSERT("tcp_recved: len would wrap rcv_wnd\n", len <= 0xffff -
pcb->rcv_wnd );

In the call to tcp_recved len is 1 and pcb->rcv_wnd is 0xffff.

We have TCP_WND set to 0xffffU.

Tracing the program we found the following:

The call to tcp_recved is performed because netconn_recv_data calls
TCPIP_APIMSG with msg.r.len = 1 (buffer is NULL). If this length is set to 0,
the problem is solved. However, we do not know if this is correct.

On the other hand, the rcv_wnd is at its maximum size (0xffff) because it is
increased in tcp_input (tcp_in.c), by the following code:

        if (recv_flags & TF_GOT_FIN) {
            /* correct rcv_wnd as the application won't call tcp_recved() for
the FIN's seqno */
            if (pcb->rcv_wnd != TCP_WND) {
              pcb->rcv_wnd++;
            }
            TCP_EVENT_CLOSED(pcb, err);
            if (err == ERR_ABRT) {
              goto aborted;
            }
        }

If we do not increment the rcv_wnd in this case, the problem would also be
potentially solved, but our concern is that this could lead to different
problems.

Can anybody reproduce this behavior and/or suggest a better solution.

Thanks in advance.









    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Mensaje enviado vía/por Savannah
  http://savannah.nongnu.org/