[tor-bugs] #27066 [Core Tor/Tor]: circuit_build_times_update_alpha(): Bug: Could not determine largest build time
Tor Bug Tracker & Wiki
blackhole at torproject.org
Thu Aug 9 05:12:01 UTC 2018
#27066: circuit_build_times_update_alpha(): Bug: Could not determine largest build
time
---------------------------------------+-----------------------------------
Reporter: cstest | Owner: (none)
Type: defect | Status: new
Priority: Medium | Milestone: Tor:
| 0.3.5.x-final
Component: Core Tor/Tor | Version: Tor: 0.3.3.9
Severity: Normal | Resolution:
Keywords: 034-backport 033-backport | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor:
---------------------------------------+-----------------------------------
Comment (by mikeperry):
Replying to [comment:3 cstest]:
> And sometime this appears in random order:
> {{{
> Your network connection speed appears to have changed. Resetting timeout
to 60s after 18 timeouts and 143 buildtimes.
> }}}
This line is not consistent with the lines about "No valid circuit build
time data". Unless you perhaps see several "Your network connection speed
appears to have changed", and then they stop, and *then* you see the "No
valid circuit build time data"?
Whatever you are doing differently for this to appear vs not appear (if
anything) would be useful info.
> but above line could be related v2 hidden service running because that
line is regular in log file when v2 domains are active. Then almost 5
hours later new lines began to appear (hundreds probably due to large
number of v3 domains in torrc):
> {{{
> Failed to launch rendezvous circuit to
$835BDF974D1B6A324C15C48A95D49605AAAB51C1~ at ....
> Giving up on launching a rendezvous circuit to
$D405FCCF06ADEDF898DF2F29C9348DCB623031BA~ at 5.45.111.149 for hidden
service v3onion....................
> Giving up launching first hop of circuit to rendezvous point
$A379AD9020BB119B53785888DACC63C7...........
> }}}
These all indicate that you can't actually build paths, which is different
than attempting circuits. This could be caused by the use of ExcludeNodes,
HSLayer2/3, vanguards, or anything else that restricts paths. Are you
using any options like that?
If not, it could be a result of n_circuit_failures being high (which could
be caused by your timeout issues). But I don't know why your timeout
failures are sometimes causing you to reset your timeout (the expected
behavior) vs sometimes causing invalid data.
> and occasionaly
> {{{
> Extremely large value for circuit build timeout: 123s. Assuming clock
jump. Purpose 14 (Measuring circuit timeout)
> Couldn't relaunch rendezvous circuit to
'$0299F268FCA9D55CD157976D39AE92B4B.........
> }}}
Now this is even weirder.. It means libevent didn't manage to call its
seconds_elapsed_callback() for like 63 seconds, at least. Though I think a
very large oneshot NTP update could do this.
> Server was running only couple of v2 domains and they worked fine and
there were also over 100 v3 domains which did not work at all. After
restarting tor instance, v3 domains started to work fine (nothing else
have been changed). All v3 domains were generated (added) by tor instance
reload, not restart.
Does the issue only happen when the v2 domains are disabled/inactive?
Do the v3 domains have to be in use for this to happen, or can I reproduce
by just making 100 of them on a random tor client and letting them sit
mostly idle?
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/27066#comment:5>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list