[OT] ExcludeNodes no longer working
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. 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. 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. 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. Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at cs.niu.edu * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************
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?
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?
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 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? All the best, Jacob
On Tuesday, September 11, 2012 1:12pm, "Jacob Appelbaum" <jacob@appelbaum.net> said: [snip]
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?
I get those same messages occasionally. The following are from last week (v0.2.3.20-rc), seen from a Los Angeles datacenter. I haven't seen this rate of complaint before or since so I wrote it off as a fluke. Sep 01 05:20:31.000 [notice] Low circuit success rate 3/21 for guard BramaH4=39A0907D409836D7F014364C5FF5AC1DA79E0289. Sep 01 05:21:52.000 [notice] Low circuit success rate 6/21 for guard TORy2=F08F537D245A65D9C242359983718A19650A25F7. Sep 01 05:25:36.000 [notice] Low circuit success rate 3/21 for guard GreenDragon=7ED90E2833EE38A75795BA9237B0A4560E51E1A0. Sep 01 05:28:11.000 [notice] Low circuit success rate 7/21 for guard TORy2=F08F537D245A65D9C242359983718A19650A25F7. Sep 01 05:28:12.000 [notice] Low circuit success rate 8/21 for guard WhiteDragon=5DEF69E67BAF2CF26D36B5AC2A925BB2EA376593. Sep 01 05:28:14.000 [notice] Low circuit success rate 3/21 for guard fejkse=EE129A8040807A63741F28C2AD1814CDABC2AD13. Sep 03 05:12:30.000 [notice] Low circuit success rate 4/21 for guard afo=E3F77CC99C4CB9F2E9F1531C6C5FBE8F49694F70. Sep 04 12:31:25.000 [notice] Low circuit success rate 10/26 for guard DFRI1=A10C4F666D27364036B562823E5830BC448E046A. Sep 04 13:24:51.000 [notice] Low circuit success rate 19/48 for guard TORy2=F08F537D245A65D9C242359983718A19650A25F7. Sep 04 13:24:55.000 [notice] Low circuit success rate 71/182 for guard WhiteDragon=5DEF69E67BAF2CF26D36B5AC2A925BB2EA376593. Sep 04 13:25:05.000 [notice] Low circuit success rate 29/74 for guard TORy2=F08F537D245A65D9C242359983718A19650A25F7. Sep 04 13:25:35.000 [notice] Low circuit success rate 7/22 for guard KoenigEdmundI=896F7E93A1FD31FC4671A965CD0D663B0A11D350. Sep 04 13:25:39.000 [notice] Low circuit success rate 13/33 for guard DFRI1=A10C4F666D27364036B562823E5830BC448E046A. Sep 04 13:26:13.000 [notice] Low circuit success rate 7/34 for guard afo=E3F77CC99C4CB9F2E9F1531C6C5FBE8F49694F70. Sep 04 13:28:11.000 [notice] Low circuit success rate 21/53 for guard PPrivCom053=674B191AD2F8325120D128E5447DBD99206784F0. Sep 04 13:39:49.000 [notice] Low circuit success rate 22/56 for guard Ydia=6727D7751EDD5CF3254488A45330674D9FD0AFEC. Sep 04 14:42:04.000 [notice] Low circuit success rate 22/56 for guard coinet=C863FB2A6109C9CE2993C8855BAC59583B15475B. Sep 04 15:34:00.000 [notice] Low circuit success rate 28/71 for guard fejkse=EE129A8040807A63741F28C2AD1814CDABC2AD13. Sep 04 16:30:07.000 [notice] Low circuit success rate 23/58 for guard GreenDragon=7ED90E2833EE38A75795BA9237B0A4560E51E1A0. Sep 04 16:31:38.000 [notice] Low circuit success rate 9/23 for guard TorLand1=4E377F91D326552AAE818D5A17BC3EF79639C2CD. Sep 04 16:54:26.000 [notice] Low circuit success rate 23/58 for guard GreenDragon=7ED90E2833EE38A75795BA9237B0A4560E51E1A0. Sep 04 16:54:26.000 [notice] Low circuit success rate 28/76 for guard TORy2=F08F537D245A65D9C242359983718A19650A25F7. Sep 04 16:55:08.000 [notice] Low circuit success rate 48/126 for guard KoenigEdmundI=896F7E93A1FD31FC4671A965CD0D663B0A11D350. Sep 04 16:55:16.000 [notice] Low circuit success rate 27/86 for guard Ydia=6727D7751EDD5CF3254488A45330674D9FD0AFEC. Sep 04 16:55:18.000 [notice] Low circuit success rate 16/50 for guard DFRI1=A10C4F666D27364036B562823E5830BC448E046A. Sep 04 16:55:20.000 [notice] Low circuit success rate 26/69 for guard coinet=C863FB2A6109C9CE2993C8855BAC59583B15475B. Sep 04 16:55:28.000 [notice] Low circuit success rate 34/86 for guard TORy2=F08F537D245A65D9C242359983718A19650A25F7. Sep 04 16:58:29.000 [notice] Low circuit success rate 8/21 for guard WhiteDragon=5DEF69E67BAF2CF26D36B5AC2A925BB2EA376593. Sep 04 17:01:27.000 [notice] Low circuit success rate 4/21 for guard normatalmadge=FA632D7758867661D4A88D95BFC56EF347A2D796. Sep 04 17:09:40.000 [notice] Low circuit success rate 31/78 for guard fejkse=EE129A8040807A63741F28C2AD1814CDABC2AD13. Sep 04 17:13:26.000 [notice] Low circuit success rate 10/26 for guard TorLand1=4E377F91D326552AAE818D5A17BC3EF79639C2CD. Sep 04 18:27:04.000 [notice] Low circuit success rate 7/21 for guard psilotorlu=372D36900E37171A5E38653A2AF4AA5C1C51FF45. Sep 04 18:51:46.000 [notice] Low circuit success rate 31/79 for guard fejkse=EE129A8040807A63741F28C2AD1814CDABC2AD13. Sep 04 18:51:46.000 [notice] Low circuit success rate 32/93 for guard TORy2=F08F537D245A65D9C242359983718A19650A25F7. Sep 04 18:51:47.000 [notice] Low circuit success rate 13/36 for guard WhiteDragon=5DEF69E67BAF2CF26D36B5AC2A925BB2EA376593. Sep 04 18:51:47.000 [notice] Low circuit success rate 36/96 for guard TORy2=F08F537D245A65D9C242359983718A19650A25F7. Sep 04 18:52:24.000 [notice] Low circuit success rate 30/79 for guard coinet=C863FB2A6109C9CE2993C8855BAC59583B15475B. Sep 04 18:52:24.000 [notice] Low circuit success rate 52/142 for guard KoenigEdmundI=896F7E93A1FD31FC4671A965CD0D663B0A11D350. Sep 04 18:52:25.000 [notice] Low circuit success rate 32/103 for guard Ydia=6727D7751EDD5CF3254488A45330674D9FD0AFEC. Sep 04 18:52:25.000 [notice] Low circuit success rate 7/36 for guard normatalmadge=FA632D7758867661D4A88D95BFC56EF347A2D796. Sep 04 18:52:26.000 [notice] Low circuit success rate 10/28 for guard TorLand1=4E377F91D326552AAE818D5A17BC3EF79639C2CD. Sep 04 18:52:27.000 [notice] Low circuit success rate 20/63 for guard DFRI1=A10C4F666D27364036B562823E5830BC448E046A. Sep 04 18:52:27.000 [notice] Low circuit success rate 8/22 for guard psilotorlu=372D36900E37171A5E38653A2AF4AA5C1C51FF45. Sep 04 18:52:28.000 [notice] Low circuit success rate 9/47 for guard afo=E3F77CC99C4CB9F2E9F1531C6C5FBE8F49694F70.
On Tue, Sep 11, 2012 at 1:52 PM, Steve Snyder <swsnyder@snydernet.net> wrote:
On Tuesday, September 11, 2012 1:12pm, "Jacob Appelbaum" <jacob@appelbaum.net> said: [snip]
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?
I get those same messages occasionally. The following are from last week (v0.2.3.20-rc), seen from a Los Angeles datacenter. I haven't seen this rate of complaint before or since so I wrote it off as a fluke.
Sep 01 05:20:31.000 [notice] Low circuit success rate 3/21 for guard BramaH4=39A0907D409836D7F014364C5FF5AC1DA79E0289. Sep 01 05:21:52.000 [notice] Low circuit success rate 6/21 for guard TORy2=F08F537D245A65D9C242359983718A19650A25F7.
This looks like bug #6475. Those warnings should be suppressed in 0.2.3.31-rc and fixed for real in 0.2.4.x. -- Nick
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 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.)
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?
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.
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!) -- Nick
Nick Mathewson:
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 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
On Tue, Sep 11, 2012 at 4:48 PM, Jacob Appelbaum <jacob@appelbaum.net> wrote:
Nick Mathewson:
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 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?
We should definitely discuss stuff openly, yeah. It was the possible ExcludeNodes bug that seemed most like an issue that would go well with the bugtracker to me. -- Nick
Nick Mathewson:
On Tue, Sep 11, 2012 at 4:48 PM, Jacob Appelbaum <jacob@appelbaum.net> wrote:
Nick Mathewson:
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 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?
We should definitely discuss stuff openly, yeah. It was the possible ExcludeNodes bug that seemed most like an issue that would go well with the bugtracker to me.
Agreed - that said - I like the idea of a client telling users that a given guard is failing a lot of circuits - is there anyway today that we can start to learn the distribution of those failures? Say with some useful client side logging? All the best, Jake
Jacob Appelbaum <jacob@appelbaum.net> wrote:
Nick Mathewson:
On Tue, Sep 11, 2012 at 4:48 PM, Jacob Appelbaum <jacob@appelbaum.net> wrote:
Nick Mathewson:
On Tue, Sep 11, 2012 at 1:12 PM, Jacob Appelbaum <jacob@appelbaum.net> wrote:
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?
We should definitely discuss stuff openly, yeah. It was the possible ExcludeNodes bug that seemed most like an issue that would go well with the bugtracker to me.
Agreed - that said - I like the idea of a client telling users that a given guard is failing a lot of circuits - is there anyway today that we can start to learn the distribution of those failures? Say with some useful client side logging?
It would also be great if there was an easy way to correlate messages in the Tor client log with the log of the socks client. Fabian
participants (5)
-
Fabian Keil -
Jacob Appelbaum -
Nick Mathewson -
Scott Bennett -
Steve Snyder