lwIP - 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: |
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.
|
Simon Goldschmidt <goldsimon> |
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 ?
|
Sylvain Rochet <gradator> |
Thu 18 Apr 2019 12:01:15 PM UTC, original submission:
A TCP connection always stays in FIN_WAIT_1/CLOSING while network
|
yuanxin <yuanx> |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
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 | Status | Need Info | Invalid | |
Assigned to | None | goldsimon | |||
Open/Closed | Open | Closed | |||
2019-04-18 | gradator | Status | None | Need Info |
Powered by Savane 3.13-f8d8.
Corresponding source code
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.