lwIP - A Lightweight TCP/IP stack - Bugs: bug #36494, tcp_recved is not called when a...
You are not allowed to post comments on this tracker with your current authentication level.
bug #36494: tcp_recved is not called when a remote TCP connection is closed
Submitter: | Bill Auerbach <billauerbach> | ||
Submitted: | Fri 18 May 2012 08:58:50 PM UTC | ||
Category: | TCP | Severity: | 3 - Normal |
Item Group: | Faulty Behaviour | Status: | Invalid |
Privacy: | Public | Assigned to: | None |
Open/Closed: | Closed | Planned Release: | None |
lwIP version: | CVS Head |
Fri 01 Jun 2012 06:24:55 PM UTC, comment #3: |
Kieran Mansley <kieranm> |
Mon 21 May 2012 02:42:49 PM UTC, comment #2: The problem with not getting a tcp_err callback is traced to the test of the return code from TCP_EVENT_ACCEPT. I was returning ERR_ABRT to indicate to abort the connection.
|
Bill Auerbach <billauerbach> |
Fri 18 May 2012 10:22:37 PM UTC, comment #1: Turns out this can be (is on WinXP) caused by setting SOCKOPT SO_LINGER. I didn't know this causes a Reset.
|
Bill Auerbach <billauerbach> |
Fri 18 May 2012 08:58:50 PM UTC, original submission:
Using NO_SYS=1 and the RAW callback API, I just discovered that when a remote TCP connection is closed (a normal close) tcp_recved is not called with struct pbuf *p == NULL but instead tcp_err is called. That conflicts with how I think it used to be and definitely with how the Wiki describes closing a socket should be handled.
|
Bill Auerbach <billauerbach> |
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 2 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2012-06-01 | kieranm | Status | None | Invalid | |
Open/Closed | Open | Closed |
Powered by Savane 3.13-d3ae.
Corresponding source code
Yes, more documentation would undoubtedly help - it needed you could trace through the git history to work out the reason for this change, but as you seem to have what you need I'll close this as requested