Opened 8 years ago

Closed 4 years ago

#4035 closed defect (fixed)

tor unable to connect/use/get network consensus

Reported by: mr-4 Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version: Tor: 0.2.3.4-alpha
Severity: Normal Keywords: blocking tor-client
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

When I start tor (note this is the new alpha version of tor-client!) it gets stuck as it cannot get network consensus for some reason, thus I cannot use tor at all.

I get the following syslog (excerpts):

Sep 16 01:15:20 test1 Tor[2337]: Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now.
Sep 16 01:15:21 test1 Tor[2337]: OpenSSL OpenSSL 1.0.0d-fips 8 Feb 2011 looks like version 0.9.8m or later; I will try SSL_OP to enable renegotiation
Sep 16 01:15:22 test1 Tor[2337]: Reloaded microdescriptor cache. Found 0 descriptors.
Sep 16 01:15:22 test1 Tor[2337]: I learned some more directory information, but not enough to build a circuit: We have no usable consensus.
Sep 16 01:15:23 test1 Tor[2337]: Bootstrapped 5%: Connecting to directory server.
Sep 16 01:15:23 test1 Tor[2337]: Heartbeat: Tor's uptime is 0:00 hours, with 6 circuits open. I've sent 0 kB and received 0 kB.
Sep 16 01:15:23 test1 Tor[2337]: Bootstrapped 10%: Finishing handshake with directory server.
Sep 16 01:15:25 test1 Tor[2337]: Bootstrapped 15%: Establishing an encrypted directory connection.
Sep 16 01:15:25 test1 Tor[2337]: Bootstrapped 20%: Asking for networkstatus consensus.
Sep 16 01:15:25 test1 Tor[2337]: Bootstrapped 50%: Loading relay descriptors.
Sep 16 01:15:25 test1 Tor[2337]: I learned some more directory information, but not enough to build a circuit: We have no usable consensus.
[...]

It doesn't progress any further. Please note that I am using bridges (about 3 of them, fully functional), but even if I alter torrc and switch to "normal" mode (i.e. with UseBridges 0) I get the same result - tor cannot get its network consensus to make a proper connection.

Please also note that tor 2.2.33 has no problems connecting (using the same torrc) and connects almost instantly, so I am thinking that there is something not tight there.

Child Tickets

Change History (12)

comment:1 Changed 8 years ago by mr-4

Any luck with this?

comment:2 Changed 8 years ago by arma

Status: newneeds_information

Not enough info to guess at what might be going wrong.

Is your clock wrong?

Try without bridges and with setting 'usemicrodescriptors 0' in your torrc. I expect that will work.

Then take out the 'usemicrodescriptors 0' line but continue to not use bridges (see also #4035).

comment:3 in reply to:  2 Changed 8 years ago by arma

Replying to arma:

(see also #4035).

and by 4035 I mean #4013.

comment:4 in reply to:  2 Changed 8 years ago by mr-4

Replying to arma:

Is your clock wrong?

No, it polls initally at boot up and then every 6 hours (the delta usually is less than .05 seconds for each 6 hour period).

Try without bridges and with setting 'usemicrodescriptors 0' in your torrc. I expect that will work.

OK, thanks, will try that.

Then take out the 'usemicrodescriptors 0' line but continue to not use bridges (see also #4035).

Unfortunately, I can't do that - I *have to* use bridges. I can only start tor for limited period (i.e. testing) without bridges, but I need to use bridges with tor when in "general" use. In any case, as I already pointed out in my initial report, without bridges tor still cannot bootstrap to 100%.

comment:5 Changed 8 years ago by mr-4

Setting "usemicrodescriptors 0" partially helps.

I can now connect (using Tor v0.2.3.5-alpha), but at regular intervals - say every 15 minutes or so - I have to stop and then start tor again as I cannot connect/use Tor. I get this series of messages:

Oct 16 21:36:54 test1 Tor[5593]: no known bridge descriptors running yet; stalling
Oct 16 21:36:54 test1 Tor[5593]: Our directory information is no longer up-to-date enough to build circuits: No live bridge descriptors.
Oct 16 21:36:56 test1 Tor[5593]: Giving up on marked_for_close conn that's been flushing for 15s (fd 4, type OR, state open).
Oct 16 21:37:33 test1 Tor[5593]: Tried for 120 seconds to get a connection to [scrubbed]:80. Giving up. (waiting for circuit)

I don't know whether this is a problem with the bridges I am using (although I don't seem to get this error with the -stable tor release), but having to reconnect at regular intervals is VERY annoying!

comment:6 Changed 8 years ago by arma

Don't use Tor 0.2.3.x with bridges running on 0.2.2.x until #4013 is fixed.

Is your need to use bridges due to security or reachability?

comment:7 in reply to:  6 Changed 8 years ago by mr-4

Replying to arma:

Don't use Tor 0.2.3.x with bridges running on 0.2.2.x until #4013 is fixed.

I won't - I will be reverting back to 2.2.33 then. Any chance of this being fixed soon-ish?

Is your need to use bridges due to security or reachability?

Both - I am constrained by my provider (throttling) as well as the "authorities", hence why I can't run tor without bridges.

On a separate note, there is a web site address which gives a short list of 3 bridges (I think it was https://bridges.torproject.org, but I am not 100% sure), but that no longer works with 2.3.x - I am constantly getting the same 3 bridges listed and I can't believe there are just 3 bridges present at any given time. Why am I not getting different ones?

comment:8 Changed 8 years ago by nickm

Keywords: blocking added
Milestone: Tor: unspecified

comment:9 Changed 7 years ago by nickm

Keywords: tor-client added

comment:10 Changed 7 years ago by nickm

Component: Tor ClientTor

comment:11 Changed 4 years ago by arma

Severity: Normal

Looks like we should close this one now that #4013 is long fixed?

comment:12 Changed 4 years ago by nickm

Resolution: fixed
Status: needs_informationclosed
Note: See TracTickets for help on using tickets.