On Tue, 11 Sep 2012 16:24:36 -0400 Nick Mathewson nickm@freehaven.net wrote:
On Tue, Sep 11, 2012 at 1:12 PM, Jacob Appelbaum jacob@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 subscribedto 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.)
You switched trackers a year or two ago. I don't recall whether I've tried the new one. Either way, I hesitate to submit a bug report until I'm pretty sure I'm looking at a bug, which is why I asked on this list whether anyone else could suggest anything.
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?
The problem is that the python script in question often has no trouble, but also often does. When it does, it usually gets a good connection twice and fails on the third connection. (Or at least I *think* that's what it does.) Then I either ask tor nicely with arm for a new set of circuits or I pound on tor with a SIGHUP for same, and then try the python script again. The process is slow, so it's very irritating to have to babysit it repeatedly until it finally gets a good connection. If I've left the script a small list of work to do, the failure may come at any point in the list, which then terminates the script. :-( I think it may have an option to ignore errors, but I don't really see an option like that as being very helpful in this situation because it would just fail its way through the rest of the list from that point, but it would take a long time to do that. Quitting outright is much faster.
A bit over a week ago, I switched to 0.2.3.20-rc, and the problemstill 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.
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.
Okay. Skipping over local port and IP address usage, here's some client-side stuff.
TunnelDirConns 1 PreferTunneledDirConns 1 UseEntryGuards 1 NumEntryGuards [if you really need the number here, let me know--SB] AllowDotExit 0 LongLivedPorts 20-23,47,115,119,143,144,152,178,194,563,706,989,990,992-994,1863,5050,5190-5193,5222,5223,6000-6063,6523,6667,6697,8021,8300
There are also several NodeFamily statements and extensive ExcludeNodes and ExludeExitNodes statements. If there is other stuff you want, let me know, but depending upon what you ask for, I may choose to send it to you directly rather than post it here.
(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!)
The only thing remotely related that I saw was the following item in the Changelog for 0.2.3.15-rc.
o Minor bugfixes (on 0.2.2.x and earlier): . . . - After we pick a directory mirror, we would refuse to use it if it's in our ExcludeExitNodes list, resulting in mysterious failures to bootstrap for people who just wanted to avoid exiting from certain locations. Fixes bug 5623; bugfix on 0.2.2.25-alpha.
It probably has nothing to do with what has been causing me trouble, but it was the only item I found about either of the Exclude{,Exit}Nodes statement that mentioned a change between 0.2.3.13-alpha and 0.2.3.18-rc.
Scott