What RFC specifies what errors should be returned for TCP operations - Unix

This is a discussion on What RFC specifies what errors should be returned for TCP operations - Unix ; Hi, What RFC contains the standards for what error is returned when a particular operation is attempted? Specifically, I'd like to know the RFC that specifies how IPv4 clients are supposed to error out when they attempt to connect to ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: What RFC specifies what errors should be returned for TCP operations

  1. What RFC specifies what errors should be returned for TCP operations

    Hi,

    What RFC contains the standards for what error is returned when a
    particular operation is attempted? Specifically, I'd like to know the
    RFC that specifies how IPv4 clients are supposed to error out when
    they attempt to connect to a host that doesn't exist, e.g. for example
    say the client is in network 192.168.0.0/24 and attempts to connection
    to host 192.168.0.24 but that host is down (for whatever reason).

    I've been searching now for some time, and have found some interesting
    RFCs. What's really irritating is I remember find, a few months ago,
    information that answers this question (though I don't recall now if
    it were an RFC). I'm curious because I know that the behavior, in the
    scenario I painted above, changed from v4 to v6. In v4, I'm getting
    the error ETIMEDOUT but using v6 I get EHOSTUNRECH. So, what RFC(s)
    specify what error type for any given error?

    Thanks,
    Andy

  2. Re: What RFC specifies what errors should be returned for TCPoperations

    On Sep 18, 2:34*pm, Andrew Falanga wrote:

    > I've been searching now for some time, and have found some interesting
    > RFCs. *What's really irritating is I remember find, a few months ago,
    > information that answers this question (though I don't recall now if
    > it were an RFC). *I'm curious because I know that the behavior, in the
    > scenario I painted above, changed from v4 to v6. *In v4, I'm getting
    > the error ETIMEDOUT but using v6 I get EHOSTUNRECH. *So, what RFC(s)
    > specify what error type for any given error?


    Your question is based on several false assumptions. The main false
    assumption is that there is only one thing that will/can happen if you
    try to connect to a host that does not exist. In fact, two different
    things happened.

    In the first case, the attempt to make the connection timed out. This
    is certainly something that can happen if you try to connect to a
    machine that does not exist.

    In the second case, the attempt resulted in a router returning to the
    machine a 'host unreachable' error message which the host chose to
    trust. This is certainly something that can happen if you try to
    connect to a machine that does not exist.

    Only you know that the actual issue is that the host does not exist.
    The machine only knows what happened when it tried to reach it. A
    standard that required it to "somehow" know that the problem is that
    the machine doesn't exist would be impossible to implement.

    DS

  3. Re: What RFC specifies what errors should be returned for TCP operations

    Andrew Falanga writes:
    >Hi,
    >
    >What RFC contains the standards for what error is returned when a
    >particular operation is attempted? Specifically, I'd like to know the
    >RFC that specifies how IPv4 clients are supposed to error out when
    >they attempt to connect to a host that doesn't exist, e.g. for example
    >say the client is in network 192.168.0.0/24 and attempts to connection
    >to host 192.168.0.24 but that host is down (for whatever reason).
    >
    >I've been searching now for some time, and have found some interesting
    >RFCs. What's really irritating is I remember find, a few months ago,
    >information that answers this question (though I don't recall now if
    >it were an RFC). I'm curious because I know that the behavior, in the
    >scenario I painted above, changed from v4 to v6. In v4, I'm getting
    >the error ETIMEDOUT but using v6 I get EHOSTUNRECH. So, what RFC(s)
    >specify what error type for any given error?
    >
    >Thanks,
    >Andy


    The RFC's specify protocol. Unix and Unix-like operating system APIs are specified
    by POSIX. Look here for the errors from 'connect':

    http://www.opengroup.org/onlinepubs/...s/connect.html

    You'll also want to check your operating system documentation:

    man connect

    scott

  4. Re: What RFC specifies what errors should be returned for TCPoperations

    On Sep 18, 3:52*pm, David Schwartz wrote:
    > On Sep 18, 2:34*pm, Andrew Falanga wrote:
    >
    > > I've been searching now for some time, and have found some interesting
    > > RFCs. *What's really irritating is I remember find, a few months ago,
    > > information that answers this question (though I don't recall now if
    > > it were an RFC). *I'm curious because I know that the behavior, in the
    > > scenario I painted above, changed from v4 to v6. *In v4, I'm getting
    > > the error ETIMEDOUT but using v6 I get EHOSTUNRECH. *So, what RFC(s)
    > > specify what error type for any given error?

    >
    > Your question is based on several false assumptions. The main false
    > assumption is that there is only one thing that will/can happen if you
    > try to connect to a host that does not exist. In fact, two different
    > things happened.
    >
    > In the first case, the attempt to make the connection timed out. This
    > is certainly something that can happen if you try to connect to a
    > machine that does not exist.
    >
    > In the second case, the attempt resulted in a router returning to the
    > machine a 'host unreachable' error message which the host chose to
    > trust. This is certainly something that can happen if you try to
    > connect to a machine that does not exist.
    >
    > Only you know that the actual issue is that the host does not exist.
    > The machine only knows what happened when it tried to reach it. A
    > standard that required it to "somehow" know that the problem is that
    > the machine doesn't exist would be impossible to implement.
    >
    > DS


    David,

    Thanks for the reply. I understand why my question was poorly
    worded. I was hoping for an RFC for IPv4 similar to this one for
    IPv6: http://tools.ietf.org/html/rfc4443#section-3. You'll notice in
    this RFC that in section 3.1 it says, "A Destination Unreachable
    message SHOULD be generated by a router, or by the IPv6 layer in the
    originating node, in response to a packet that cannot be delivered to
    its destination address for reasons other than congestion."

    Because this RFC existed, and had some framework for what and when a
    given error is asserted, I thought that one existed for IPv4 as well.
    If I have misunderstood this RFC, please inform me how.

    Thanks,
    Andy

  5. Re: What RFC specifies what errors should be returned for TCPoperations

    On Sep 22, 10:55*am, Andrew Falanga wrote:

    > Thanks for the reply. *I understand why my question was poorly
    > worded. *I was hoping for an RFC for IPv4 similar to this one for
    > IPv6:http://tools.ietf.org/html/rfc4443#section-3. *You'll notice in
    > this RFC that in section 3.1 it says, "A Destination Unreachable
    > message SHOULD be generated by a router, or by the IPv6 layer in the
    > originating node, in response to a packet that cannot be delivered to
    > its destination address for reasons other than congestion."
    >
    > Because this RFC existed, and had some framework for what and when a
    > given error is asserted, I thought that one existed for IPv4 as well.
    > If I have misunderstood this RFC, please inform me how.


    But even that won't help you. First, that's only a "SHOULD". There's
    no guarantee it will happen. Second, a router being unable to deliver
    a packet is only one possible failure mode. For example, if the end
    node is powered off but its MAC address is statically-configured in a
    router, no router will detect anything wrong.

    DS

  6. Re: What RFC specifies what errors should be returned for TCPoperations

    On Sep 22, 1:16*pm, David Schwartz wrote:
    > On Sep 22, 10:55*am, Andrew Falanga wrote:
    >
    > > Thanks for the reply. *I understand why my question was poorly
    > > worded. *I was hoping for an RFC for IPv4 similar to this one for
    > > IPv6:http://tools.ietf.org/html/rfc4443#section-3. *You'll notice in
    > > this RFC that in section 3.1 it says, "A Destination Unreachable
    > > message SHOULD be generated by a router, or by the IPv6 layer in the
    > > originating node, in response to a packet that cannot be delivered to
    > > its destination address for reasons other than congestion."

    >
    > > Because this RFC existed, and had some framework for what and when a
    > > given error is asserted, I thought that one existed for IPv4 as well.
    > > If I have misunderstood this RFC, please inform me how.

    >
    > But even that won't help you. First, that's only a "SHOULD". There's
    > no guarantee it will happen. Second, a router being unable to deliver
    > a packet is only one possible failure mode. For example, if the end
    > node is powered off but its MAC address is statically-configured in a
    > router, no router will detect anything wrong.
    >
    > DS


    This is highly frustrating. Not that what you're saying is wrong but
    because some would so brazenly ignore the SHOULD directive in the
    RFC. In the picture you painted, about the MAC being statically
    assigned in a routers tables, from the RFC it would seem that the
    originating node, in this case, should generate, or assume,
    destination unreachable. It's just frustrating that implementers
    wouldn't do this.

    It also seems like a "fantasy hope" on the part of the standards
    writers to hope for some sort of standard error description mechanism
    like this for so many possibilites.

    Andy

  7. Re: What RFC specifies what errors should be returned for TCPoperations

    On Sep 23, 11:29*am, Andrew Falanga wrote:

    > This is highly frustrating. *Not that what you're saying is wrong but
    > because some would so brazenly ignore the SHOULD directive in the
    > RFC. *In the picture you painted, about the MAC being statically
    > assigned in a routers tables, from the RFC it would seem that the
    > originating node, in this case, should generate, or assume,
    > destination unreachable. *It's just frustrating that implementers
    > wouldn't do this.


    How does it know it's the destination that's unreachable, rather than
    the port being filtered?

    > It also seems like a "fantasy hope" on the part of the standards
    > writers to hope for some sort of standard error description mechanism
    > like this for so many possibilites.


    Then what happens when an application cares about the different
    possibilities?

    There is no simple solution. If an API carelessly folds all these
    different real-world outcomes into a single error code, many people
    will complain that they can't distinguish circumstances that are
    materially different. If they don't fold all the outcomes into one
    error, many people will complain that they can't detect a particular
    outcome class with a single test.

    DS

+ Reply to Thread