Hi Jacob et al.,
On Tue, 11 Sep 2012 17:12:06 +0000 Jacob Appelbaum <jacob@appelbaum.net>
wrote:
It is nice to see you posting again, I had wondered where you had gone.
I've been here all along, but didn't have anything to say until this
matter came up.
Scott Bennett:
I know this really belongs on tor-talk, but I haven't been subscribed
to it for a long time now. Sorry if posting this here bothers anyone.
Seems like a fine place to discuss relay problems, which is what it
sounds like, no?
Um, no, it seems to me that Exclude{,Exit}Node matters are client-side
stuff. That's where the circuit routes are selected, which is where those
torrc lines come into play, right?
Back in early July, I upgraded from 0.2.3.13-alpha to 0.2.3.18-rc.
I immediately ran into problems with a python script that honors the
http_proxy environment variable, which I normally have set to the localhost
port for privoxy, which, in turn, connects to tor's SOCKS port. I couldn't
really see what was going wrong, but using arm to ask for a new identity
seemed to help sometimes to get a circuit that worked. Sending tor a
SIGHUP instead also seemed to work about as often.
If you use 0.2.2.x - what happens?
No idea. I haven't built a "stable" version in at least five years,
probably longer.
A bit over a week ago, I switched to 0.2.3.20-rc, and the problem
still occurs. However, 0.2.3.20-rc now also emits a new message from time
to time, the most recent occurrence of which is
Sep 06 06:02:45.934 [notice] Low circuit success rate 7/21 for guard TORy0=753E0B5922E34BF98F0D21CC08EA7D1ADEEE2F6B.
That is an interesting message - I wonder if the author of that message
might chime in?
Wondering whether such circuit-building failures might be related to the
other problem, I began a little experiment: each time I saw a "Low circuit
success rate" message, I added the key fingerprint of the node in question
to my ExcludeNodes list in torrc and sent tor a SIGHUP.
The problem is still occurring, though, and when I look at the
circuits involved, they all seem to have at least one of the excluded
nodes in them, usually in the entry position. So my question is, what
changed between 0.2.3.13-alpha and 0.2.3.18-rc (or possibly 0.2.3.20-rc)
in the handling of nodes listed in the ExcludeNodes line in torrc? And
is there anything I can do to get the ExcludeNodes list to work again
the way it used to work?
Thanks in advance for any relevant information.
It seems that there are two issues - one is that a guard is failing to
build circuits, the other is that you can't seem to exclude them. I have
Right, but the guard's problem really shouldn't be my problem, although
I suppose I could try emailing the node's operator about it.
to admit, I'm more interested in the former... Is there a pattern to the
failures? That is for the 7 successes for that node, did you see
anything interesting? Were say, the nodes that worked somehow in the
same country as that guard? Or perhaps were the other failed circuits
all seemingly unrelated to the guard?
I haven't the foggiest. I don't even know over how much time tor
has been calculating the ratio before it decides to issue that message.
It could be minutes, hours, days...
The failures I started getting with 0.2.3.18-rc were really
irritating, but I didn't have a clue to follow until switching to
0.2.3.20-rc, which issues the interesting messages. That prompted me
to turn INFO logging back on and watch what happened when I ran that
script. Between the log and looking at arm's display of current circuit
routes, I was able to see that nodes were being used that were supposed
to have been excluded.
As far as the ExcludeNodes - did you set StrictNodes at the same time?
No. However, there are usually 800 - 900 guards active at any time
these days, so I figured that excluding only the ones that gave me trouble
would leave plenty of others available for selection.
Are you also a relay?
Yes. See MYCROFTsOtherChild in the consensus, descriptors, or
tor status pages. It's the same one I've been running for years, apart
from short hiatuses in 2007 and 2008.
Scott
Scott Bennett