Opened 5 years ago

Closed 4 years ago

#13506 closed task (implemented)

Explain/document what various hidden service close reasons mean

Reported by: arma Owned by: dgoulet
Priority: Medium Milestone: Tor: 0.2.8.x-final
Component: Core Tor/Tor Version:
Severity: Keywords: tor-hs, doc
Cc: dgoulet Actual Points:
Parent ID: Points: small
Reviewer: Sponsor: SponsorR

Description (last modified by arma)

Phil and Rob fetched a bunch of hidden services, and watched the controller events while doing so. They saw a bunch of REMOTE_REASONS that were not self-evident in what they mean happened, or what it means their fetcher should do:

RESOLVEFAILED - Crawler should not return to this onion for
                this round, or forever?
EXITPOLICY    - Crawler should try again, but should target a
                different Hidden Service port, as the HS in
                not using port 80 as its virtual port.
INTERNAL      - should the crawler try again...try diff RP?
DESTROY       - should the crawler try again...try diff RP?
MISC          - should the crawler try again...try diff RP?
CONNRESET     - should the crawler try again...try diff RP?
NOROUTE       - should the crawler try again...try diff RP?
CANT_ATTACH   - should the crawler try again...try diff RP?
CONNECTREFUSED - should the crawler try again...try diff RP?
TIMEOUT       - should the crawler try again...try diff RP?

For example, RESOLVEFAILED is what Tor says when it tried to fetch the hidden service descriptor from the hsdirs but none of them had it. This is not obvious.

Whereas CONNECTREFUSED means, I think, that every step of the rendezvous worked great, and that the hidden service was indeed configured to use virtual port 80, but there was nothing listening on the other end of that virtual port.

What do the other cases mean? And what do they imply about whether a retry is likely to work?

Child Tickets

Change History (13)

comment:1 Changed 5 years ago by arma

Description: modified (diff)

comment:2 Changed 5 years ago by nickm

Cc: dgoulet added
Keywords: doc added

comment:3 Changed 5 years ago by arma

Here are the notes I wrote up during the January hack week:

RESOLVEFAILED - Tor tried to fetch the hidden service descriptor from
the hsdirs but none of them had it. This implies that the hidden service
has not been running in the past 72 hours.
[This last sentence is actually wrong -- we also give out resolvefailed
when we fetched the descriptor, tried the intro points, fetched a new
one to see if it had changed, and gave up because it hadn't changed.]

EXITPOLICY    - The destination port that you tried is not configured
on the hidden service side. That is, the hidden service was up and
reachable, but it isn't listening on this port. (Hidden services running
Tor 0.2.6.2-alpha and later don't send this error code; instead they send
back an END cell with reason DONE reason then close the circuit on you.)

DONE          - If you get an END cell with reason DONE, *before*
you've gotten your CONNECTED cell, that indicates a similar situation
to EXITPOLICY, but the hidden service is running 0.2.6.2-alpha or later,
and it has now closed the circuit on you.

INTERNAL      - Internal error inside the Tor client -- hopefully you
will not see this much; let us know if you do.

DESTROY       - The circuit closed before you could get a response back
-- transient failure, e.g. a relay went down unexpectedly. Trying again
might work.

MISC          - "Catch-all for unlisted reasons" -- shouldn't happen
much in practice.

CONNECTREFUSED - every step of the rendezvous worked great, and that the
hidden service is indeed up and running and configured to use the virtual
port you asked for, but there was nothing listening on the other end of
that virtual port. For example, the HS's Tor client is running fine but
its apache service is down.

CONNRESET     - Like CONNECTREFUSED except the errno at the hidden
service when trying to connect() to the service was ECONNRESET.

NOROUTE       - Like CONNECTREFUSED except the errno at the hidden service
when trying to connect() to the service was ENETUNREACH, EHOSTUNREACH,
EACCES, or EPERM.

TIMEOUT       - Two cases unfortunately blurred together -- either
like CONNECTREFUSED above but connect() got the ETIMEDOUT errno, or the
client-side timeout of 120 seconds kicked in and we gave up.

CANT_ATTACH   - Tor failed to find an appropriate circuit to attach this
stream to.
[I think this case happens in many different situations, and we likely want
to invent some new stream end reasons and break out the cases.]

comment:4 Changed 5 years ago by nickm

Owner: set to dgoulet
Status: newassigned

dgoulet has said he'll turn this into a patch on something. So calling it assigned.

comment:5 Changed 5 years ago by dgoulet

Status: assignedneeds_review

Ok branch ticket13506_01 in https://git.torproject.org/user/dgoulet/torspec.git contains a new section in rend-spec.txt that explains end stream reasons for HS.

comment:6 Changed 5 years ago by nickm

Resolution: implemented
Status: needs_reviewclosed

cool; merged!

comment:7 Changed 4 years ago by arma

Resolution: implemented
Status: closedreopened

comment:8 Changed 4 years ago by arma

David just came to ask me what CANT_ATTACH means, and I said "hey, wasn't there that ticket", and we looked in rend-spec.txt and there's no mention of CANT_ATTACH. What happened here?

comment:9 Changed 4 years ago by nickm

Milestone: Tor: 0.2.6.x-finalTor: 0.2.7.x-final

comment:10 Changed 4 years ago by nickm

Milestone: Tor: 0.2.7.x-finalTor: 0.2.8.x-final

comment:11 Changed 4 years ago by nickm

Keywords: SponsorR removed
Sponsor: SponsorR

Bulk-replace SponsorR keyword with SponsorR sponsor field in Tor component.

comment:12 Changed 4 years ago by dgoulet

Points: small
Status: reopenedaccepted

comment:13 Changed 4 years ago by nickm

Resolution: implemented
Status: acceptedclosed

CANT_ATTACH isn't there because it isn't part of the protocol:

/* These high-numbered end reasons are not part of the official spec,
 * and are not intended to be put in relay end cells. They are here
 * to be more informative when sending back socks replies to the
 * application. */
Note: See TracTickets for help on using tickets.