Opened 8 years ago

Closed 7 years ago

Last modified 7 years ago

#4013 closed defect (fixed)

Tor 0.2.3.x client can't use 0.2.2.x bridge

Reported by: arma Owned by:
Priority: High Milestone: Tor: 0.2.3.x-final
Component: Core Tor/Tor Version:
Severity: Keywords: microdescriptors regression tor-client
Cc: twilde@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

My 0.2.3.3-alpha client, when configured to use a bridge, asks the bridge for /tor/status-vote/current/consensus-microdesc.z. But 0.2.2.x bridges don't know how to answer this question (they return a 404), so my client can't bootstrap from them.

Child Tickets

Change History (14)

comment:1 Changed 8 years ago by nickm

Hrm. 0.2.2.x directories are supposed to be caching microdesc consensuses and microdescs. Perhaps 0.2.2.x bridges don't know that they're supposed to be doing that? That's bug one.

Bug two is a missing feature: For 0.2.3.x bridge users, we need some way for them to try to use microdescs, but fall back to not using microdescs if their bridges can serve them.

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

Replying to nickm:

Bug two is a missing feature: For 0.2.3.x bridge users, we need some way for them to try to use microdescs, but fall back to not using microdescs if their bridges can serve them.

Fortunately, step 1 for using a bridge is to fetch its descriptor. Now you know its version.

So we could for example say "if all our known running bridges are 0.2.3.x, use microdescriptors, otherwise fall back". We could also say "if _one_ of our known running bridges is 0.2.3.x, use microdescriptors". I'm not sure which one is smarter.

comment:3 in reply to:  description ; Changed 8 years ago by dcf

Replying to arma:

My 0.2.3.3-alpha client, when configured to use a bridge, asks the bridge for /tor/status-vote/current/consensus-microdesc.z. But 0.2.2.x bridges don't know how to answer this question (they return a 404), so my client can't bootstrap from them.

I saw this on my 0.2.2.34 bridge with a 0.2.3.7-alpha client. It was the reason for c1f7a98d (UseMicrodescriptors 0) in flashproxy.git.

I want to add that just upgrading the bridge to 0.2.3 didn't seem to cause it to start serving microdescriptors. (I continued to get 404s.) On CentOS 5, I changed from the centos5 to the centos5-experimental repository and did a yum upgrade, which installed 0.2.3.6-alpha. But the bridge reported

Nov 15 16:50:59.000 [warn] Please upgrade! This version of Tor (0.2.3.6-alpha) is not recommended, according to the directory authorities. R
ecommended versions are: 0.2.1.31,0.2.2.34,0.2.3.7-alpha
Nov 15 16:50:59.000 [notice] Reloaded microdescriptor cache.  Found 0 descriptors.

And the client continued to say.

Nov 15 14:10:09.000 [warn] Received http status code 404 ("Not found") from server 'scrubbed' while fetching consensus directory.

I deleted the files /var/lib/tor/{cached-certs,cached-consensus,cached-descriptors,cached-descriptors.new,lock,state} . cached-microdesc-consensus and cached-microdescs.new didn't exist. I restarted the bridge and the deleted files reappeared along with cached-microdesc-consensus and cached-microdescs.new. The bridge log said

Nov 15 17:12:02.000 [notice] Reloaded microdescriptor cache.  Found 0 descriptors.

After that the client was able to connect. Restarting the bridge once more says

Nov 15 17:35:49.000 [notice] Reloaded microdescriptor cache.  Found 2449 descriptors.

comment:4 Changed 8 years ago by twilde

Cc: twilde@… added

comment:5 Changed 7 years ago by nickm

Keywords: microdescriptors added

comment:6 Changed 7 years ago by nickm

Keywords: regression added

comment:7 Changed 7 years ago by arma

Status: newneeds_review

See my bug4013 branch for a fix for 0.2.3.x.

Then see my bug4013-part2 branch for an improved fix. The improvement might be a feature, so maybe it's best saved for 0.2.4.x.

comment:8 Changed 7 years ago by nickm

I'm not really in love with either fix, but I think bug4013 is indeed probably the better choice for 0.2.3.x. I worry about oscillation; perhaps instead we should have a rule that once we have decided "no microdescriptors for us because of our bridges' versions", we shouldn't change our mind again till we restart. What do you think?

comment:9 Changed 7 years ago by arma

bug4013 now has a new commit on it, doing what you suggest

(we do change our mind and go back to microdescs in the case where we turn off usebridges)

this commit makes bug4013-part2 fail to merge; but we'll deal with that one later.

comment:10 Changed 7 years ago by nickm

Milestone: Tor: 0.2.3.x-finalTor: 0.2.4.x-final

Merged bug4013; kicking bug4013-part2 off to 0.2.4.

comment:11 Changed 7 years ago by arma

Milestone: Tor: 0.2.4.x-finalTor: 0.2.3.x-final
Resolution: fixed
Status: needs_reviewclosed

#4013 is dead; long live #4994.

comment:12 in reply to:  3 Changed 7 years ago by arma

Replying to dcf:

I want to add that just upgrading the bridge to 0.2.3 didn't seem to cause it to start serving microdescriptors. (I continued to get 404s.)

For the record, I bet that was due to #4011.

comment:13 Changed 7 years ago by nickm

Keywords: tor-client added

comment:14 Changed 7 years ago by nickm

Component: Tor ClientTor
Note: See TracTickets for help on using tickets.