[lwip-devel] [bug #35435] No pcb state check before adding it to time-wait queue while closing

[Yosic]

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

                 Summary: No pcb state check before adding it to time-wait
queue while closing
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: yosic
            Submitted on: Thu 02 Feb 2012 12:24:58 PM GMT
                Category: TCP
                Severity: 3 - Normal
              Item Group: Faulty Behaviour
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: 
            lwIP version: CVS Head

    _______________________________________________________

Details:

tcp.c function tcp_close_shutdown.
There are lines after "/* move to TIME_WAIT since we close actively */"
A check against pcb being already in time-wait queue is required here since it
can lead to the behavior when an already added pcb is added second time and
later, in a timer, we have infinite looping. This behavior is reproducible
when one tries to close connection right after another part has requested
close as well. In particular I got this issue wile closing a connection of
http server after serving a request without keep-alives.
The browser requests connection termination just before I did and my system
hangs in infinite loop in a timer(don't remember exactly which one).
I have fixed the issue with the following code. But I'm not sure is my fixed
correct from the whole stack point of view since I'm not familiar with all
it's internals. Any way the issue should be fixed since it major problem. I
had it reproducible every request.
Instead of :
      TCP_RMV(&tcp_active_pcbs, pcb);
      pcb->state = TIME_WAIT;
      TCP_REG(&tcp_tw_pcbs, pcb);

I use :
      if(pcb->state != TIME_WAIT) // check state
      {
          TCP_RMV(&tcp_active_pcbs, pcb);
          pcb->state = TIME_WAIT;
          TCP_REG(&tcp_tw_pcbs, pcb);
      }





    _______________________________________________________

Reply to this item at:

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

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