lwIP - A Lightweight TCP/IP stack - Bugs: bug #19157, lwip_close problems
You are not allowed to post comments on this tracker with your current authentication level.
bug #19157: lwip_close problems
Submitter: | Frédéric Bernon <fbernon> | ||
Submitted: | Mon 26 Feb 2007 08:40:01 PM UTC | ||
Category: | sockets/netconn | Severity: | 3 - Normal |
Item Group: | Faulty Behaviour | Status: | In Progress |
Privacy: | Public | Assigned to: | fbernon |
Open/Closed: | Closed | Planned Release: | None |
lwIP version: | None |
Jump to the original submission
Sat 09 Jun 2007 10:17:20 AM UTC, comment #31: |
Frédéric Bernon <fbernon> |
Wed 23 May 2007 11:16:22 AM UTC, comment #30: Well, we have determined that waiting in close is wrong,that's for sure.
|
Jonathan Larmour <jifl> |
Wed 23 May 2007 10:41:55 AM UTC, comment #29: Not a patch file, but look first comment and comment #5... I do something a little bit different now, but it's the idea. I just don't like to use sys_sleep...
|
Frédéric Bernon <fbernon> |
Wed 23 May 2007 10:39:30 AM UTC, comment #28: Your patch? Sorry, must have missed that. |
Simon Goldschmidt <goldsimon> |
Wed 23 May 2007 10:01:02 AM UTC, comment #27: Not yet, but it's true I don't take time to show with traces and others that the problem is real. I will try to find time for that, because, even if my patch works for me, there were several users who seem to have the same.
|
Frédéric Bernon <fbernon> |
Wed 23 May 2007 09:52:34 AM UTC, comment #26: I've opened a task (#6930) for implementing SO_LINGER. Can we close this now? |
Simon Goldschmidt <goldsimon> |
Tue 27 Mar 2007 03:02:40 PM UTC, comment #25: If one day, we integrate SO_LINGER, so I think that adding SO_DONTLINGER could be done in the same time. First, because it is already defined in sockets.h (for source code compatibility I think), second, because there will no lot of job to do. I could be useful to someone who activate SO_LINGER on a sockets, and, due to his application or protocol, need to come back to SO_DONTLINGER.
|
Frédéric Bernon <fbernon> |
Tue 27 Mar 2007 02:33:13 PM UTC, comment #24: SO_DONTLINGER is a non-standard option. I would be against its provision in lwIP on that basis (why support a non-standard bell and whistle when we don't support all standard ones!).
|
Jonathan Larmour <jifl> |
Tue 27 Mar 2007 01:13:01 PM UTC, comment #23: Ok, I will try to provide a trace + a network capture to show the problem...
|
Frédéric Bernon <fbernon> |
Tue 27 Mar 2007 10:33:14 AM UTC, comment #22: A detailed description of an error situation (maybe including a packet log) would be helpful deciding if this is a real problem or not. |
Simon Goldschmidt <goldsimon> |
Tue 27 Mar 2007 07:53:51 AM UTC, comment #21: We seem to be tracking two issues on this bug report:
|
Kieran Mansley <kieranm> |
Mon 26 Mar 2007 02:53:17 PM UTC, comment #20: Hi,
|
Per Strandh <strandh> |
Mon 26 Mar 2007 02:27:12 PM UTC, comment #19: Okay, I think we need to be clear here... my understanding of the current state is that do_delconn() will call tcp_close(). tcp_close() will send a FIN and move the connection to FIN_WAIT_1. That FIN is also added to the unacked queue, and will be retransmitted as needed in tcp_slowtmr().
|
Jonathan Larmour <jifl> |
Mon 26 Mar 2007 02:26:28 PM UTC, comment #18: Adding SO_LINGER (with default off) is ok for me. In that way, unsent data is purged on close by default, which seems to be what opengroup.org wants to say. I would stick to this standard instead of Microsoft, if only to be portable... |
Simon Goldschmidt <goldsimon> |
Mon 26 Mar 2007 02:04:36 PM UTC, comment #17: Ok, implement SO_LINGER will give us the possibility to choose. I suppose the default value is disabled ("non blocking on close").
|
Frédéric Bernon <fbernon> |
Mon 26 Mar 2007 01:49:22 PM UTC, comment #16: Just an information point to confirm what was said earlier, according to http://www.opengroup.org/onlinepubs/000095399/functions/close.html
|
Jonathan Larmour <jifl> |
Mon 26 Mar 2007 01:22:21 PM UTC, comment #15: Yes, you're right, netconn_delete do a part of netconn_close (except that netconn_close retry to sent if there is a ERR_MEM error, but netconn_close is not call in socket layer).
|
Frédéric Bernon <fbernon> |
Mon 26 Mar 2007 01:14:01 PM UTC, comment #14: Hold on a minute, from looking at the code, isn't that what happens already? So why is there a problem? do_delconn() among other things simply calls tcp_close() which should do an orderly close and send pending packet, and will only abort the connection if that returns an error. The only case I can see for this happening is if we're out of memory or the send queue is full as then we fail to add the FIN, return an error, and abort the connection. Is this the problem Frederic is seeing? |
Kieran Mansley <kieranm> |
Mon 26 Mar 2007 12:55:57 PM UTC, comment #13: Hmm (as you say), ok, the idea is good, but I'm not sure to be able to get something like that. Kieran or Simon, do you take this item to propose a patch based on your idea?
|
Frédéric Bernon <fbernon> |
Mon 26 Mar 2007 12:43:35 PM UTC, comment #12: Hmm, yes, I suppose so. It should already get recycled once it gets to CLOSED, meaning we'd need no extra mechanism to do that, and so the only modification would be to not delete the pcb at lwip_close() time if there is outstanding packets.
|
Kieran Mansley <kieranm> |
Mon 26 Mar 2007 12:38:27 PM UTC, comment #11: Can't the netconn be deleted while the tcp_pcb lives on (e.g. in a closing-list which is handled by timers)? |
Simon Goldschmidt <goldsimon> |
Mon 26 Mar 2007 12:33:06 PM UTC, comment #10: OK, thanks. I understand it better now.
|
Kieran Mansley <kieranm> |
Mon 26 Mar 2007 12:23:11 PM UTC, comment #9: Ok, the "classic" example is a - simple - web server, which only return one document per connection.
|
Frédéric Bernon <fbernon> |
Mon 26 Mar 2007 11:43:32 AM UTC, comment #8: I agree that this doesn't seem like a good solution. Can you briefly describe what the remaining problem is? I've rather lost track of this one. I don't think you normally get (on linux for example) blocked on close() until all packets are sent. Can you remind me why this is necessary for lwIP? |
Kieran Mansley <kieranm> |
Mon 26 Mar 2007 10:33:51 AM UTC, comment #7: I just can tell that closesocket on winsock give you insurance that all pending segments are sent, even it you call the close directly just after the write. if the peer crash at the close time, you should get an error after MAXRTX sent (I suppose)? |
Frédéric Bernon <fbernon> |
Mon 26 Mar 2007 10:29:11 AM UTC, comment #6: This does not look like a good solution to me. What I don't like is that the stack keeps the application waiting without doing anything and the time it needs depends on the peer. I don't think any other OS lets you wait when closing a socket...
|
Simon Goldschmidt <goldsimon> |
Mon 26 Mar 2007 07:31:41 AM UTC, comment #5: Can I get some comments about that (I have to test, but it's about the polling feature) :
|
Frédéric Bernon <fbernon> |
Fri 23 Mar 2007 08:03:03 AM UTC, comment #4: I can confirm that Christiaan's change doesn't solve this problem. When he commit that, I have try to disable my patch (which is not commited) and I always got problem.
|
Frédéric Bernon <fbernon> |
Fri 23 Mar 2007 05:38:13 AM UTC, comment #3: I thought the second part is fixed with Christian's change in comment number 3 of bug #15926. Are you sure there's still a problem here?
|
Jonathan Larmour <jifl> |
Sun 11 Mar 2007 05:00:01 PM UTC, comment #2: First part commit with fix bug #19225.
|
Frédéric Bernon <fbernon> |
Mon 26 Feb 2007 08:54:48 PM UTC, comment #1: The second part is one of the solutions from :
|
Frédéric Bernon <fbernon> |
Mon 26 Feb 2007 08:40:01 PM UTC, original submission:
First, in lwip_close, I think that last sock_set_errno have to be set BEFORE sys_sem_signal like this :
|
Frédéric Bernon <fbernon> |
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 |
---|---|---|---|---|---|
2007-06-09 | fbernon | Open/Closed | Open | Closed | |
2007-03-11 | fbernon | Status | None | In Progress | |
2007-03-04 | fbernon | Assigned to | None | fbernon |
Powered by Savane 3.13-cf05.
Corresponding source code
Because I don't have reproduce the problem during my last tests (perhaps fix by another modification?), I close that (if I reproduce it in next tests, I could reopen i)...