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
tor-relays@lists.torproject.org