[tor-bugs] #7157 [Tor]: "Low circuit success rate %u/%u for guard %s=%s."
Tor Bug Tracker & Wiki
blackhole at torproject.org
Fri Dec 14 17:04:48 UTC 2012
#7157: "Low circuit success rate %u/%u for guard %s=%s."
-----------------------------------------+----------------------------------
Reporter: arma | Owner:
Type: enhancement | Status: needs_revision
Priority: normal | Milestone: Tor: 0.2.4.x-final
Component: Tor | Version:
Keywords: tor-client, MikePerry201212 | Parent: #5456
Points: | Actualpoints: 19
-----------------------------------------+----------------------------------
Changes (by nickm):
* status: needs_review => needs_revision
Comment:
Okay, part two (which covers the rest of the branch up to
ccaeef22e168af34e9b6a63d65ce17e58dd702e2) is much shorter:
Documentation on pathbias_check_close seems inadequate; it should
really say what the function actually DOES. It happily calls
pathbias_count_successful_close.
Setting timestamp_dirty in circuit_extend_to_new_exit seems wrong.
The circuit *isn't* dirty! Maybe overloading timestamp_dirty in this
way, rather than grabbing a new bit, is a mistake?
04866055e8dadc9eb5b09773 freaks me out. This feels like a significant
redesign of the whole concept, and I didn't see it mentioned on
tor-dev anywhere or on the tickets. "As long as end-to-end tagging is
possible, we assume the adversary will use it over hop-to-hop
failure"? Is there any discussion of this anyplace? (The idea here
seems to be that entry nodes are allowed to filter for the second hop
as much as they like, and the pathbias code won't care, but that if
they start tagging/filtering for the third hop or later, they need to
be called out. Is that right?)
In general: use %f to printf a double, but %lf to scanf a double. At
least one compiler we care about complains when it sees %lf in a
printf format string.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/7157#comment:18>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list