[tor-bugs] #11966 [Core Tor/Tor]: "Bootstrapped 20%: Asking for networkstatus consensus" is a lie for bridge users

[Tor Bug Tracker & Wiki]

#11966: "Bootstrapped 20%: Asking for networkstatus consensus" is a lie for bridge
users
-------------------------------------------------+-------------------------
 Reporter:  arma                                 |          Owner:  isis
     Type:  defect                               |         Status:
 Priority:  Medium                               |  needs_review
Component:  Core Tor/Tor                         |      Milestone:  Tor:
 Severity:  Normal                               |  0.2.9.x-final
 Keywords:  tor-bridge, TorCoreTeam201605,       |        Version:
  review-group-2                                 |     Resolution:
Parent ID:                                       |  Actual Points:
 Reviewer:  arma                                 |         Points:  1
                                                 |        Sponsor:
-------------------------------------------------+-------------------------
Changes (by isis):

 * status:  needs_information => needs_review


Comment:

 Replying to [comment:13 dgoulet]:
 > One question. When we trigger the
 `BOOTSTRAP_STATUS_REQUESTING_BRIDGE_DESC` control event, we do it in the
 circuit building function instead of the "requesting bridge desc" function
 which I assume is `directory_get_from_dirserver`.
 >

 So... what happens is that we just build a circuit to our bridge, without
 knowing it's key, and then we ask the bridge for the consensus. The bridge
 responds with its descriptor. Then, usually, because the scheduled events
 run we call `fetch_bridge_descriptors()` and the bridge gives us the
 descriptor again. ''Then'' we decide "oh, I actually have the bridge
 descriptor, now I can ask for the consensus again." When we ask for the
 consensus again, at this point is the first time that any of the code in
 `directory.c` is called, but never before that (because of this fumbling
 around that happens with fetching the bridge descriptor).

 However, if we were to trigger `BOOTSTRAP_STATUS_REQUESTING_BRIDGE_DESC`
 in `fetch_bridge_descriptors`,  then it seems like we would want to make
 this event be at like 3% bootstrapped, because "15%" is "establishing an
 encrypted directory connection" where the "directory" in question is
 actually the bridge (for which we already have it's descriptor at this
 point, because the stupid fumbling) and the point that we get the
 descriptor is before `BOOTSTRAP_STATUS_CONN_DIR=5` (5%).

 > For instance, `BOOTSTRAP_STATUS_REQUESTING_DESCRIPTORS` is used when we
 realize we need more descriptors rather than when the circuit is built for
 that request. What if that onehop circuit never gets build, we won't know
 that it was because we requested a bridge descriptor?

 Ah. That is true.

 ------

 Okay, there's an alternate version of the patch in my `bug11966_v2`
 [https://gitweb.torproject.org/user/isis/tor.git/log/?h=bug11966_v2
 branch] and it does like this:

 {{{
 May 31 15:11:45.000 [notice] Bootstrapped 0%: Starting
 May 31 15:11:45.000 [notice] Delaying directory fetches: No running
 bridges
 May 31 15:11:46.000 [notice] Bootstrapped 3%: Asking for bridge
 descriptors
 May 31 15:11:46.000 [notice] Bootstrapped 5%: Connecting to directory
 server
 May 31 15:11:46.000 [notice] Bootstrapped 10%: Finishing handshake with
 directory server
 May 31 15:11:46.000 [notice] Learned fingerprint
 8F347C5673390E46642B06A7B1F4088B59437AD0 for bridge 127.0.0.1:5009.
 May 31 15:11:46.000 [notice] Bootstrapped 15%: Establishing an encrypted
 directory connection
 May 31 15:11:46.000 [notice] new bridge descriptor 'test009br' (fresh):
 $8F347C5673390E46642B06A7B1F4088B59437AD0~test009br at 127.0.0.1
 May 31 15:11:46.000 [notice] I learned some more directory information,
 but not enough to build a circuit: We have no usable consensus.
 May 31 15:11:47.000 [notice] Bootstrapped 20%: Asking for networkstatus
 consensus
 May 31 15:11:47.000 [notice] Bootstrapped 25%: Loading networkstatus
 consensus
 }}}

 (FWIW, I still like the 18% method better but I don't really care either
 way.)

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/11966#comment:14>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online