Opened 5 years ago

Closed 5 years ago

Last modified 4 years ago

#15006 closed defect (implemented)

Improve error message "Connecting to a relay directory failed (no route to host)."

Reported by: krichter Owned by: nickm
Priority: Medium Milestone: Tor: 0.2.6.x-final
Component: Core Tor/Tor Version:
Severity: Keywords: 026-deferrable
Cc: brade, mcs, atagar Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Instead of stating "Connecting to a relay directory failed (no route to host)." it'd be useful to give the error message "Connecting to a relay directory failed (no route to host [host])." so that the user can investigate.

experienced with Tor Browser 4.0.3

Child Tickets

Change History (17)

comment:1 Changed 5 years ago by mcs

Cc: brade mcs added
Component: Tor BrowserTor
Owner: changed from tbb-team to nickm
Status: newassigned

I can see how it would be helpful to know which host / IP address could not be reached. To fix this, I think the error messages generated by the tor daemon would need to be modified to add host information; currently, Tor Launcher does not have access to that info.

Nick, please reassign as appropriate.

comment:2 Changed 5 years ago by nickm

Keywords: 026-deferrable added
Milestone: Tor: 0.2.6.x-final

Where would it be helpful to see this information added? Is there a particular control message, log message, or somewhere else that it should go?

(I can't find "Connecting to a relay directory failed" in the Tor source; isn't not one of our messages, is it?)

Tentatively assigning this into the 0.2.6.x milestone, since it looks trivial, though we might have to defer it.

comment:3 Changed 5 years ago by mcs

I experimented by deleting all of my tor cache files, disconnecting my Ethernet cable, and trying to start Tor Browser. The error message that is the focus of this ticket can be generated in response to a bootstrap status event that looks like this:

650 STATUS_CLIENT WARN BOOTSTRAP PROGRESS=5 TAG=conn_dir SUMMARY="Connecting to directory server" WARNING="No route to host" REASON=NOROUTE COUNT=4 RECOMMENDATION=warn

I also saw a similar response to a 'GETINFO status/bootstrap-phase' command:

250-status/bootstrap-phase=WARN BOOTSTRAP PROGRESS=5 TAG=conn_dir SUMMARY="Connecting to directory server" WARNING="No route to host" REASON=NOROUTE COUNT=2 RECOMMENDATION=warn

The error message displayed by the browser is not in the tor code; that is because Tor Launcher uses TAG and REASON as keywords to produce localized error messages (conn_dir is mapped to 'Connecting to a relay directory' and NOROUTE is mapped to 'no route to host').

Since Tor Launcher does not show users the text within the SUMMARY and WARNING fields, I am not sure where to add the host within these control port responses. You could add an optional HOST field and return it for certain failures (e.g., CONNECTREFUSED, TIMEOUT, NOROUTE). Or you could hack it into the WARNING field using some parsable convention, e.g., WARNING="No route to host [1.2.3.4]" (but this is hacky and violates the "Controllers SHOULD NOT rely on the format of any warning string" clause within the control protocol spec).

comment:4 Changed 5 years ago by nickm

Cc: atagar added
Status: assignedneeds_review

Branch "feature15006_026" in my public tor repo has a simple implementation of this that might do what you want. The corresponding spec change is in branch "feature15006" in my public torspec repo.

comment:5 Changed 5 years ago by atagar

+ [HOST=" QString

Typo, s/[/". Also please spell out 'QuotedString'. QString doesn't currently exist in the spec...

% grep QString ./* | wc -l
0
% grep QuotedString ./* | wc -l
18

Also, is the spec saying all these keyword fields are optional or it's an 'all or nothing'? Usually we have "[keyword1=foo] [keyword2=bar]...". Don't think I've seen square brackets around multiple fields before.

Otherwise spec change looks good to me!

comment:6 Changed 5 years ago by nickm

Thanks! Pushed an updated branch.

comment:7 Changed 5 years ago by atagar

Looks good to me!

comment:8 Changed 5 years ago by mcs

With these changes, I now get:

650 STATUS_CLIENT WARN BOOTSTRAP PROGRESS=5 TAG=conn_dir SUMMARY="Connecting to directory server" WARNING="Network is unreachable" REASON=NOROUTE COUNT=3 RECOMMENDATION=warn HOST="$BD6A829255CB08E66FBE7D3748363586E46B3810"

But I cannot figure out what control port command to use to translate the ID into something like hostname:port or IP:port. Pointers appreciated!

comment:9 Changed 5 years ago by atagar

To get the address/ORPort you can fetch the descriptor ('GETINFO desc/id/BD6A829255CB08E66FBE7D3748363586E46B3810' or 'GETINFO ns/id/BD6A829255CB08E66FBE7D3748363586E46B3810' should both do the trick for this).

comment:10 in reply to:  9 Changed 5 years ago by mcs

Replying to atagar:

To get the address/ORPort you can fetch the descriptor ('GETINFO desc/id/BD6A829255CB08E66FBE7D3748363586E46B3810' or 'GETINFO ns/id/BD6A829255CB08E66FBE7D3748363586E46B3810' should both do the trick for this).

Thanks! My problem was that I started with a completely clean tor data directory. In that case, GETINFO desc/id/... seems to return:

552 Unrecognized key "desc/id/$BD6A829255CB08E66FBE7D3748363586E46B3810"

and GETINFO ns/id/... returns:

250-ns/id/$BD6A829255CB08E66FBE7D3748363586E46B3810=
250 OK

I guess this ID is one of the directory servers and tor does not yet have any info to report. But I admit I do not fully understand everything that happens during the Tor bootstrapping process.

Would you be willing to always include ip:port? Maybe tor could always include HOST="ip:port" but also include HOSTID="..." if it is available.

comment:11 Changed 5 years ago by nickm

Status: needs_reviewneeds_revision

Sure, that wouldn't be hard.

comment:12 Changed 5 years ago by nickm

Status: needs_revisionneeds_review

Updated branches; ready for re-review. :)

comment:13 Changed 5 years ago by mcs

Looks good to me, and I think we can use this nicely inside Tor Launcher... although a tor developer should probably review the code. Questions like "Is conn->identity_digest guaranteed to be non-NULL?" run through me head because I do not know the tor code well (actually, I looked at that one and saw that it is a fixed-size array... but you get the idea).

Last edited 5 years ago by mcs (previous) (diff)

comment:14 Changed 5 years ago by atagar

the "hostaddr" is an address:port combination.

Mentioned on other specs but please specify if the address is IPv4, IPv6, both, or whatever it should be. :)

comment:15 Changed 5 years ago by ln5

FWIW, 0f2f8fd..98822df looks good to me.

Only nitpicking question I have is why cast uint16_t base_.port to an int in the tor_snprintf call and not in the log_fn call?

comment:16 Changed 5 years ago by nickm

Resolution: implemented
Status: needs_reviewclosed

Merged; thanks all!

Linus: the (int) is is optional, since passing anything shorter than an int into a varargs implicitly casts it... but that's not 100% obvious, so sometimes my fingers stick the cast in anyway.

comment:17 Changed 4 years ago by mcs

The related Tor Launcher ticket is #15657.

Note: See TracTickets for help on using tickets.