[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #6341 [Tor Relay]: connection_or_flush_from_first_active_circuit() does wrong thing when ewma_enabled
#6341: connection_or_flush_from_first_active_circuit() does wrong thing when
ewma_enabled
-----------------------+----------------------------------------------------
Reporter: arma | Owner:
Type: defect | Status: needs_review
Priority: normal | Milestone: Tor: 0.2.3.x-final
Component: Tor Relay | Version:
Keywords: | Parent:
Points: | Actualpoints:
-----------------------+----------------------------------------------------
Comment(by robgjansen):
Replying to [comment:37 arma]:
> As usual, it would be great if you could get me info-level logs from one
of these clients that doesn't bootstrap, and ideally from a directory
mirror that doesn't bootstrap too.
>
Right on:
[https://trac.torproject.org/projects/tor/attachment/ticket/6341/nonexit11.log.xz
relay log here],
[https://trac.torproject.org/projects/tor/attachment/ticket/6341/webclient5.log.xz
client log here].
A note on the log format: the first column is the real (wall clock) time,
and the third column is the virtual time (returned with any time() type
functions) as hours:minutes:seconds:nanoseconds.
The relay starts at just over the 1 virtual-minute mark and finally
reaches 100% at just under 28 minutes. The client starts at the 15
virtual-minute mark and reaches 100% at just over 37 minutes. After
reaching 100%, the client sees no additional socks connection errors.
> I just used nickm's chutney tool to launch a self-contained tor network,
and for the first 5 minute period, all the clients were getting 404's in
response to their consensus fetches. After about 15 minutes though,
everything had settled down and they all worked nicely. I wonder what is
different in your situation.
Me too. I ran a third experiment using 'FetchDirInfoEarly 1' and
'FetchDirInfoExtraEarly 1' for the relays, and 'FetchDirInfoEarly 1' for
the clients. There were no 404s for any of the nodes after the 5 virtual-
minute mark.
I'm still seeing a few socks errors though.
For
[https://trac.torproject.org/projects/tor/attachment/ticket/6341/webclient71.log.xz
webclient71 in this log file], the client started up at the 15 minute 7
seconds mark, and was bootstrapped to 100% 24 seconds later. The
'FG_ERR_SOCKSCONN' occurs at minute 43. It appears the circuit building
process may have been legitimately slow in this case because of exit8.
Perhaps increasing the SocksTimeout to 3 minutes could help in this case.
For
[https://trac.torproject.org/projects/tor/attachment/ticket/6341/webclient74.log.xz
webclient74 in this log file], the client didn't bootstrap 100% until
almost 36 minutes. There were 3 'FG_ERR_SOCKSCONN' errors before that, but
none after. The client again appeared to be attempting to download
descriptors.
Does any of this enlighten the problem? I'm curious if you can capture
something from the logs that I didn't notice.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/6341#comment:38>
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