lwIP - A Lightweight TCP/IP stack - Bugs: bug #44092, tcp_pcb hangs in FIN_WAIT_1 after...
You are not allowed to post comments on this tracker with your current authentication level.
bug #44092: tcp_pcb hangs in FIN_WAIT_1 after lwip_close call
Submitter: | Torbjørn Tvermosegaard <tbt> | ||
Submitted: | Mon 26 Jan 2015 01:56:10 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: | 1.4.0 |
Jump to the original submission
Thu 31 Aug 2017 01:42:54 PM UTC, comment #9: |
Navaneeth Y V <navaneethyv> |
Thu 31 Aug 2017 05:11:04 AM UTC, comment #8:
|
Simon Goldschmidt <goldsimon> |
Thu 31 Aug 2017 05:09:04 AM UTC, comment #7: Hi Simon,
|
Navaneeth Y V <navaneethyv> |
Wed 30 Aug 2017 05:52:56 AM UTC, comment #6: Or alternatively, search google. This is a common TCP problem, not lwIP related. |
Simon Goldschmidt <goldsimon> |
Wed 30 Aug 2017 05:48:04 AM UTC, comment #5: Actually, this is an exact duplicate to bug #31487 from 2010. Read Kieran's answer there why FIN_WAIT_1 is different to FIN_WAIT_2. |
Simon Goldschmidt <goldsimon> |
Wed 30 Aug 2017 05:32:03 AM UTC, comment #4: Sorry to Revive this old bug, I could hit a similar issue today. Essentially the application of lwip initiates a close connection because of which TCP gets into FIN_WAIT_1. Now because of a policy if we are dropping the packets from the other peer ( That is no accept ACK / FIN ) We will be stuck in this state.
|
Navaneeth Y V <navaneethyv> |
Fri 01 Jul 2016 01:33:33 AM UTC, comment #3: Sorry to post to an old bug, however I also ran into this today. I waited 5 minutes for the PCB to be cleaned up by timeouts to no avail. I noticed that once the PCB is in the FIN_WAIT_1 state and has had tcp_close called on it, there is no transition out of this state in the tcp_slowtmr task. However there is a transition for FIN_WAIT_2. Is it possible this was mistaken as the timeout? |
Ben Kneale <benkneale> |
Sat 21 Mar 2015 09:11:45 PM UTC, comment #2: There is a timeout, it's just much longer than you expect. TCP is very conservative in timeouts and this is the standard TCP timeout, so if you need a faster timeout, you're correct in implementing your own timeout mechanism in the application layer. |
Simon Goldschmidt <goldsimon> |
Tue 27 Jan 2015 07:33:22 PM UTC, comment #1: Yes, there should be a timeout on close in this case, I guess. |
Simon Goldschmidt <goldsimon> |
Mon 26 Jan 2015 01:56:10 PM UTC, original submission:
On a socket connection to a PC through a switch it seems that the lwip does not properly handle the situation, that the cable between switch and PC is disconnected (this means that interface in lwip is still up). I have an application that discovers the lack of communication and calls lwip_close, but it seems that the tcp_pcb is stuck in FIN_WAIT_1 because it never receives any further data on the connection. |
Torbjørn Tvermosegaard <tbt> |
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 3 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2015-03-21 | goldsimon | Status | None | Invalid | |
Assigned to | None | goldsimon | |||
Open/Closed | Open | Closed |
Powered by Savane 3.13-02a9.
Corresponding source code
Sure. Thank you for the pointer.