buglwIP - A Lightweight TCP/IP stack - Bugs: bug #56161, TCP state stays FIN_WAIT_1/CLOSING

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #56161: TCP state stays FIN_WAIT_1/CLOSING

Submitter:  yuanxin <yuanx>
Submitted:  Thu 18 Apr 2019 12:01:15 PM UTC
   
 
Category:  TCP Severity:  3 - Normal
Item Group:  Faulty Behaviour Status:  Invalid
Privacy:  Public Assigned to:  goldsimon
Open/Closed:  Closed Planned Release:  None
lwIP version:  2.0.3

Tue 07 May 2019 02:14:45 AM UTC, comment #3: 

Hi, I think the timeout value for FIN_WAIT_1 should be shorter than the normal timeout value for established state. In Linux, if the initial RTO was 200ms, then only 8 times was tried for FIN_WAIT_1 state before the tcp connection was destroyed, but it was 15 times for ESTABLISHED state. pls refer the sysctl parameter "tcp_retries2" and "tcp_orphan_retries" for more info.

Gao Qingshui <kevingao>
Tue 30 Apr 2019 11:38:08 AM UTC, comment #2: 

This is indeed invalid from a TCP state machine point of view. I can see a need for this for applications not using half-closed connections, though. But please, if we do someting here, it must be done in a way that doesn't violate the standards and doesn't break using half-open connections.

The suggested patch certainly does not work. The connection should eventually time out just as a full-open connection. If that's too slow, you can always set a linger timeout.

Simon Goldschmidt <goldsimon>
Group administrator
Thu 18 Apr 2019 12:19:01 PM UTC, comment #1: 

FIN_WAIT_1 (and I guess CLOSING too) is tied to the regular TX TCP timeout, so it should timeout sooner or later, what do you really mean by stay in FIN_WAIT_1/CLOSING ?

What you are doing is without doubt a violation of TCP RFCs.

Sylvain Rochet <gradator>
Group Member
Thu 18 Apr 2019 12:01:15 PM UTC, original submission:  

A TCP connection always stays in  FIN_WAIT_1/CLOSING while network
faults happening like net cable plugging out, which makes tcp pcb cannot be released. The following is my modification in function tcp_slowtmr:

The original code:

  if (pcb->state == LAST_ACK) {
      if ((u32_t)(tcp_ticks - pcb->tmr) > 2 * TCP_MSL / TCP_SLOW_INTERVAL) {
        ++pcb_remove;
        LWIP_DEBUGF(TCP_DEBUG, ("tcp_slowtmr: removing pcb stuck in LAST-ACK\n"));
      }
    }

My code:

if (pcb->state == LAST_ACK || pcb->state == FIN_WAIT_1 || pcb->state == CLOSING) {
      if ((u32_t)(tcp_ticks - pcb->tmr) > 2 * TCP_MSL / TCP_SLOW_INTERVAL) {
        ++pcb_remove;
        LWIP_DEBUGF(TCP_DEBUG, ("tcp_slowtmr: removing pcb stuck in LAST-ACK\n"));
      }
    }

yuanxin <yuanx>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by kevingao (Posted a comment)
  • -email is unavailable- added by goldsimon (Posted a comment)
  • -email is unavailable- added by gradator (Posted a comment)
  • -email is unavailable- added by yuanx (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-04-30 goldsimon StatusNeed Info Invalid
        Assigned toNone goldsimon
        Open/ClosedOpen Closed
    2019-04-18 gradator StatusNone Need Info

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code