buglwIP - A Lightweight TCP/IP stack - Bugs: bug #9455, The sockets API does not correctly...

 
 

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

bug #9455: The sockets API does not correctly inform a process that a RST has been received

Submitter:  Kieran Mansley <kieranm>
Submitted:  Fri 25 Jun 2004 02:28:22 PM UTC
   
 
Category:  sockets/netconn Severity:  3 - Normal
Item Group:  Faulty Behaviour Status:  Invalid
Privacy:  Public Assigned to:  None
Open/Closed:  Closed Planned Release:  None
lwIP version:  None

Jump to the original submission

Fri 20 Apr 2007 07:57:06 AM UTC, comment #7: 

OK.

To summarise, we think the error code returned is currently correct, and we're not going to bother with sending signals.


Kieran Mansley <kieranm>
Group Member
Thu 19 Apr 2007 04:56:06 PM UTC, comment #6: 

Ok for me to close it as invalid...

Frédéric Bernon <fbernon>
Group Member
Thu 19 Apr 2007 11:29:54 AM UTC, comment #5: 


>BTW, I believe EPIPE is when the local end has been closed.


As far as I know, that's correct. So this bug could be closed?

Note that at the time of the bug report, sockets.c already returned ECONNRESET, so maybe the bug was invalid at that time already?

Simon Goldschmidt <goldsimon>
Group administrator
Tue 17 Apr 2007 02:35:37 PM UTC, comment #4: 

Frederic's point was that sockets.c already returns ECONNRESET for ERR_RST. As far as I know, this is what all other systems do in the same situation, and so is a better error code than EPIPE.

As far as I can tell, send/write use netconn_write, which will return conn->err if it isn't ERR_OK. So ERR_RST should be returned, causing ECONNRESET to in turn be returned. I admit I haven't tried experimenting.

BTW, I believe EPIPE is when the local end has been closed.

Jonathan Larmour <jifl>
Group Member
Tue 17 Apr 2007 01:26:54 PM UTC, comment #3: 

(I'm referring to the explanation given in http://www.opengroup.org/onlinepubs/000095399/functions/send.html)

Since we can't close a connection for writing only (can we?), I think both error codes (ECONNRESET and EPIPE) are correct. So it's up to us to decide which one we want to use. Since ERR_RST is only used with tcp, defining ERR_RST to EPIPE should do the trick. (Or is EPIPE also returned to UDP sockets when an icmp-packet 'dest unreachable' was received for that udp port? I don't think we support that).

Simon Goldschmidt <goldsimon>
Group administrator
Tue 17 Apr 2007 01:09:59 PM UTC, comment #2: 

Is something done on that? Actually, if we got a ERR_RST, even with only send, sockets api will returns ECONNRESET:

from sockets.c
ECONNRESET,    /* ERR_RST     -4      Connection reset.        */

Is EPIPE is really a better error code?


Frédéric Bernon <fbernon>
Group Member
Mon 26 Feb 2007 03:09:41 PM UTC, comment #1: 

It's going to be tricky to fix this in a portable way as signals aren't terribly portable.

We could certainly do the "returns EPIPE" part though.

Any thoughts?

Kieran Mansley <kieranm>
Group Member
Fri 25 Jun 2004 02:28:22 PM UTC, original submission:  

If a process is only using send()/write() etc rather than any recv()/read() calls, it will not learn that a connection has been closed and a FIN/RST received.

The receipt of a RST by the sending process indicates that
the remote process has terminated.

When a process writes to a socket that has received a RST, the SIGPIPE
signal should be sent to the process.  The default action of this signal
is to terminate the process.  If the process either catches the signal
and returns from the signal handler, or ignores the signal, the write
operation returns EPIPE.

Kieran Mansley <kieranm>
Group Member

 

(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 jifl (Posted a comment)
  • -email is unavailable- added by goldsimon (Posted a comment)
  • -email is unavailable- added by fbernon (Posted a comment)
  • -email is unavailable- added by kieranm (Posted a comment)
  •  

    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
    2007-04-20 kieranm StatusNone Invalid
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code