[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-bugs] #9557 [Tor]: Clients waste a whole minute when bootstrapping using bridges
#9557: Clients waste a whole minute when bootstrapping using bridges
------------------------+---------------------------------------------------
Reporter: karsten | Owner:
Type: defect | Status: new
Priority: normal | Milestone:
Component: Tor | Version:
Keywords: tor-client | Parent:
Points: | Actualpoints:
------------------------+---------------------------------------------------
When a client bootstraps for the first time using bridges, it sits there
for a whole minute doing nothing between "Bootstrapped 50%" and
"Bootstrapped 80%":
{{{
Aug 21 19:08:20.804 [notice] Tor 0.2.5.0-alpha-dev (git-7121e7bd15659052)
opening log file.
Aug 21 19:08:20.805 [warn] Your log may contain sensitive information -
you're logging above "notice". Please log safely. Don't log unless it
serves an important reason. Overwrite the log afterwards.
Aug 21 19:08:20.805 [warn] Your log may contain sensitive information -
you disabled SafeLogging. Please log safely. Don't log unless it serves an
important reason. Overwrite the log afterwards.
Aug 21 19:08:21.923 [notice] Bootstrapped 5%: Connecting to directory
server.
Aug 21 19:08:21.925 [notice] Bootstrapped 10%: Finishing handshake with
directory server.
Aug 21 19:08:21.942 [notice] Learned fingerprint
224FC9615C2899B3C982A947FF7912201F986B1C for bridge 174.129.86.221:9001.
Aug 21 19:08:21.942 [notice] Bootstrapped 15%: Establishing an encrypted
directory connection.
Aug 21 19:08:21.985 [notice] Bootstrapped 20%: Asking for networkstatus
consensus.
Aug 21 19:08:21.987 [notice] Bootstrapped 50%: Loading relay descriptors.
Aug 21 19:08:21.993 [notice] new bridge descriptor 'utpbridge' (fresh):
$224FC9615C2899B3C982A947FF7912201F986B1C~utpbridge at 174.129.86.221
Aug 21 19:08:21.993 [notice] I learned some more directory information,
but not enough to build a circuit: We have no usable consensus.
Aug 21 19:09:23.194 [notice] I learned some more directory information,
but not enough to build a circuit: We have no usable consensus.
Aug 21 19:09:23.390 [notice] I learned some more directory information,
but not enough to build a circuit: We need more microdescriptors: we have
0/4455, and can only build 0% of likely paths. (We have 0% of guards bw,
0% of midpoint bw, and 0% of exit bw.)
Aug 21 19:09:24.928 [notice] We now have enough directory information to
build circuits.
Aug 21 19:09:24.928 [notice] Bootstrapped 80%: Connecting to the Tor
network.
Aug 21 19:09:24.930 [notice] Bootstrapped 90%: Establishing a Tor circuit.
Aug 21 19:09:26.162 [notice] Tor has successfully opened a circuit. Looks
like client functionality is working.
Aug 21 19:09:26.162 [notice] Bootstrapped 100%: Done.
}}}
My current theory is that the first directory request fetches the bridge's
server descriptor, which works fine. But then the client sees that it
doesn't have a microdesc consensus, decides that it just finished a
directory request, so schedules the next request for in a minute later.
What it should really do is make another request right then.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9557>
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