Opened 16 months ago

Last modified 4 weeks ago

#24300 new defect

Failed to find node for hop #1 of our path. Discarding this circuit

Reported by: dgoulet Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-client, bootstrap, 034-triage-20180328, 034-removed-20180328, 040-deferred-20190220
Cc: catalyst Actual Points:
Parent ID: #26310 Points:
Reviewer: Sponsor:


Been two days in a row with git master (033-alpha), when I boot up my computer and tor starts and fails to bootstrap. It takes around 8 minutes before it finally work.

The particularity I have with my tor client is that I pin my EntryNodes with one specific Guard for testing purposes and I stumbled on this issue.

Attached to the ticket are the info logs from the start of tor up to the 100% bootstrap.

Child Tickets

Attachments (1)

info-ticket.log (904.6 KB) - added by dgoulet 16 months ago.

Download all attachments as: .zip

Change History (11)

Changed 16 months ago by dgoulet

Attachment: info-ticket.log added

comment:1 Changed 16 months ago by asn

Brief log analysis:
Seems like we failed to fetch a consensus diff 4 times over 10 mins from different fallback dirs:

Nov 15 09:34:57.000 [info] directory_send_command(): Downloading consensus from using 
Nov 15 09:35:57.000 [info] directory_send_command(): Downloading consensus from using 
Nov 15 09:38:57.000 [info] directory_send_command(): Downloading consensus from using 
Nov 15 09:41:57.000 [info] directory_send_command(): Downloading consensus from using 

We got the diff the last time, but during those 10 mins we refused to populate our guard list because we had no live consensus:

Nov 15 09:34:57.000 [info] entry_guards_expand_sample(): Not expanding the sample guard set; we have no live consensus.

I think there are two questions here:
a) Why did we fail to fetch the consensus diff for 10mins?
b) Why did we wait for a live consensus to populate guard list? Why not a reasonably live one? i think the answer lies in #22400.

comment:2 Changed 16 months ago by catalyst

Cc: catalyst added
Keywords: bootstrap s8-errors added
Sponsor: Sponsor8-can

comment:3 Changed 15 months ago by dgoulet

I just want to point out that this thing is still really annoying... I get that every week where my tor client can't do anything because I have a pinned EntryNodes but seems no descriptor for it.

comment:4 Changed 13 months ago by teor

Milestone: Tor: 0.3.2.x-finalTor: 0.3.4.x-final

These feature and bugfix tickets have no patches. The earliest they will get done is 0.3.4.

comment:5 Changed 12 months ago by nickm

Keywords: 034-triage-20180328 added

comment:6 Changed 12 months ago by nickm

Keywords: 034-removed-20180328 added

Per our triage process, these tickets are pending removal from 0.3.4.

comment:7 Changed 11 months ago by nickm

Milestone: Tor: 0.3.4.x-finalTor: unspecified

These tickets, tagged with 034-removed-*, are no longer in-scope for 0.3.4. We can reconsider any of them, if time permits.

comment:8 Changed 3 months ago by teor

Milestone: Tor: unspecifiedTor: 0.4.0.x-final
Parent ID: #26310

We think the guard part of this is fixed by #24661, and the consensus diff part will be fixed in #26310.

comment:9 Changed 2 months ago by gaba

Keywords: s8-errors removed
Sponsor: Sponsor8-can

comment:10 Changed 4 weeks ago by nickm

Keywords: 040-deferred-20190220 added
Milestone: Tor: 0.4.0.x-finalTor: unspecified

Deferring 51 tickets from 0.4.0.x-final. Tagging them with 040-deferred-20190220 for visibility. These are the tickets that did not get 040-must, 040-can, or tor-ci.

Note: See TracTickets for help on using tickets.