[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #11966 [Core Tor/Tor]: "Bootstrapped 20%: Asking for networkstatus consensus" is a lie for bridge users
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs