[tor-relays] [OT] ExcludeNodes no longer working

[Jacob Appelbaum]

Nick Mathewson:
> On Tue, Sep 11, 2012 at 1:12 PM, Jacob Appelbaum <jacob at appelbaum.net> wrote:
>> Hi Scott,
>>
>> It is nice to see you posting again, I had wondered where you had gone.
>>
>> 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?
> 
> Maaybe!  The very best place would be the bugtracker, of course. (I do
> seem to recall that you have some issues with trac -- I'm just
> mentioning the bugtracker so that other people don't get the idea that
> the mailing lists are the best place for bug reports.  But a bug
> report on the mailing list is much much better than no bug report at
> all.)
> 

Oh, I don't mean to imply not to file bugs but rather, if we have a
guard that fails circuits, I'd say we should discuss it openly. Is it a
load issue? Or something else?

>>>      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?
> 
> I'm not sure what the bug described here is, fwiw.  What is the
> behavior for the circuits that don't work, and to what extent is
> 0.2.2.x better?

Scott?

> 
>>>      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?
> 
> Looks like bug #6475.

Ok.

> 
>>> 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
>> 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?
>>
>> As far as the ExcludeNodes - did you set StrictNodes at the same time?
>> Are you also a relay?
> 
> Any other configuration info would be helpful here too.
> 
> (To answer your question: looking through the changelogs, and the
> commit logs for src/or/circuitbuild.c and src/or/routerlist.c, I can't
> find anything that stands out to me as something that might cause an
> ExcludeNodes regression.  So more investigation will be needed!)
> 

I didn't see anything either - my first thought was of course to the
worst case "a guard that selectively fails circuits, perhaps only
allowing creation to nodes that they also control/watch/etc."

All the best,
Jake