Hello all. This is my first time using a mailing list, so apologies if Im not doing it right! I have ran a couple of Tor Relays now for a few months, one was steady and reliable, and providing about 2MB/s of bandwidth. Of late, its slowed down dramatically. A reboot resolved it temporarily, but its slowed right down again, below 500KB/s. You can see the graph here- https://atlas.torproject.org/#details/2DAEE4EBA687A517F8B473894341A56820CDDC... Does anyone have any suggestions? I have checked with my ISP and they are not throttling or managing the traffic in anyway, and my CPU and RAM isnt under heavy load. Ive uploaded my torrc here- http://pastebin.com/ZCnLQF0w I have read that file discriptors can also be a problem, Im not sure if this is relevant but- $ sysctl fs.file-nr fs.file-nr = 832 0 199036 Thanks in advance for your help, keep up the good work!
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 31.01.2013 11:21, schrieb Matthew Harrold:
Hello all.
I have ran a couple of Tor Relays now for a few months, one was steady and reliable, and providing about 2MB/s of bandwidth. Of late, its slowed down dramatically. A reboot resolved it temporarily, but its slowed right down again, below 500KB/s. You can see the graph here- https://atlas.torproject.org/#details/2DAEE4EBA687A517F8B473894341A56820CDDC...
Does anyone have any suggestions? I have checked with my ISP and they are not throttling or managing the traffic in anyway, and my CPU and RAM isnt under heavy load.
Hello, i have no suggestion, but i am seeing the same thing on my relay. https://atlas.torproject.org/#details/5A58FB3D0858148D4F4727AAC71B0D67F09033... Would be nice to know what happened. Regards, Norman -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRCmTFAAoJEMCA6frkLT6zOUwH/3x253R5rM3gnoYWWqwqS+U6 8IfMHAmiK4OLpNg5Yvceb7qbEAPE6zbXJi2C1Ro3Fry0uLdXOoZUkqHPpGKXBKkT ld9r8JJ5gTntDLSmh0Ty7vXQzdR3DhU5DnP2qYgw368fC3f4vR/uU2thG6+q6hu7 QVWwK2+cxc7C+4V9kudIhdp4LUnGgRLhUv3SHv2BxmycU5GioQ+P/jnvt6l58sJG qS93zT6D/bPWQ9M7W1vANToqM6mdakS9DPFdHiGuWKyMk53IXZyJlqTiMER+QtiV sHpV8ituPMEawKsO5wO4bMjF27LqG95sbr0gZjj0vIOkO8FAi6pc1EKWxf2I0es= =NT2p -----END PGP SIGNATURE-----
On Thu, 31 Jan 2013 10:21:42 +0000 Matthew Harrold <tormailinglist@marrold.co.uk> wrote:
I have ran a couple of Tor Relays now for a few months, one was steady and reliable, and providing about 2MB/s of bandwidth. Of late, its slowed down dramatically. A reboot resolved it temporarily, but its slowed right down again, below 500KB/s. You can see the graph here- https://atlas.torproject.org/#details/2DAEE4EBA687A517F8B473894341A56820CDDC...
Does anyone have any suggestions? I have checked with my ISP and they are not throttling or managing the traffic in anyway, and my CPU and RAM isnt under heavy load.
Hello, It looks like your node got the "Guard" status - google around for what that means, or wait for someone to explain. When that happens, your traffic drops significantly, and it can take weeks or months till it recovers to initial levels, if it ever will at all. Personally I don't agree with the theory behind "Guards", and it is highly annoying that there is no way to prevent nodes from becoming Guard. The only way to drop that status seems to be nuking the whole /var/lib/tor/keys/ directory and restarting tor; this has the same effect as if you have just started a new node. Needs to be done every couple of weeks, but getting back to expected traffic levels takes at most 3-5 hours after that each time. -- With respect, Roman ~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Stallman had a printer, with code he could not see. So he began to tinker, and set the software free."
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 31 Jan 2013 13:34:13 +0100 Norman Rieß <norman@smash-net.org> wrote:
Hello,
i have no suggestion, but i am seeing the same thing on my relay.
https://atlas.torproject.org/#details/5A58FB3D0858148D4F4727AAC71B0D67F09033...
Would be nice to know what happened.
Hello, See my adjacent reply about the Guard status; for yours it is the same, see "guard probability" on graphs about half way down on that page. - -- With respect, Roman ~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Stallman had a printer, with code he could not see. So he began to tinker, and set the software free." -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlEKaboACgkQTLKSvz+PZwhA3QCfexGWX6YKqYElTj+f+sW2NBeN nz0AoIHtfR1Wd0lbp0Li4ijl/DSOjkFm =aLf+ -----END PGP SIGNATURE-----
Am 31.01.2013 um 13:55 schrieb Roman Mamedov <rm@romanrm.ru>:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, 31 Jan 2013 13:34:13 +0100 Norman Rieß <norman@smash-net.org> wrote:
Hello,
i have no suggestion, but i am seeing the same thing on my relay.
https://atlas.torproject.org/#details/5A58FB3D0858148D4F4727AAC71B0D67F09033...
Would be nice to know what happened.
Hello,
See my adjacent reply about the Guard status; for yours it is the same, see "guard probability" on graphs about half way down on that page.
- -- With respect, Roman
Thank you! Norman
On Thu, Jan 31, 2013 at 2:51 PM, Roman Mamedov <rm@romanrm.ru> wrote:
Hello,
It looks like your node got the "Guard" status - google around for what that means, or wait for someone to explain. When that happens, your traffic drops significantly, and it can take weeks or months till it recovers to initial levels, if it ever will at all.
Why would traffic fall after becoming a guard node? Aren't guard nodes selected as middle nodes too?
Personally I don't agree with the theory behind "Guards", and it is highly annoying that there is no way to prevent nodes from becoming Guard.
What don't you agree with? With the fact that Tor sticks to a set of three nodes for the first hop of each circuit, or with the way the guard flag is awarded to nodes?
On Sun, 3 Feb 2013 16:14:07 +0200 Konstantinos Asimakis <inshame@gmail.com> wrote:
Why would traffic fall after becoming a guard node? Aren't guard nodes selected as middle nodes too?
"clients avoid using relays with the Guard flag for hops other than the first hop, since they assume they've got lots of load from clients who are using them for the first hop -- but when you first get your Guard flag, nobody uses you as a guard yet, so you don't have much traffic." -- arma@mit.edu You don't follow tor-talk@?
Personally I don't agree with the theory behind "Guards", and it is highly annoying that there is no way to prevent nodes from becoming Guard.
What don't you agree with? With the fact that Tor sticks to a set of three nodes for the first hop of each circuit
This ^
or with the way the guard flag is awarded to nodes?
There should exist a torrc option of "I don't want it, dammit." -- With respect, Roman
But if you constantly switch guard nodes then chances are that very soon you will use at the same time two compromised nodes, probably revealing which sites you visit. Also Tor users usually use Tor to visit specific sites, not generally browse the web, so even if someone peeks into their circuits once, he can get a good idea of what the user uses Tor for. So fixing the guard nodes means that either no one peeks into your circuits or that someone peeks constantly into your circuits (well 1/3rd of them) for a long time, which is not really worse than peeking for a day into them. I don't follow tor-talk. I wouldn't mind of course having the option of excluding your node from the guard position. ----- My blog: http://www.inshame.com My full signature with lots of links etc: http://bit.ly/trtsig On Sun, Feb 3, 2013 at 4:42 PM, Roman Mamedov <rm@romanrm.ru> wrote:
On Sun, 3 Feb 2013 16:14:07 +0200 Konstantinos Asimakis <inshame@gmail.com> wrote:
Why would traffic fall after becoming a guard node? Aren't guard nodes selected as middle nodes too?
"clients avoid using relays with the Guard flag for hops other than the first hop, since they assume they've got lots of load from clients who are using them for the first hop -- but when you first get your Guard flag, nobody uses you as a guard yet, so you don't have much traffic." -- arma@mit.edu
You don't follow tor-talk@?
Personally I don't agree with the theory behind "Guards", and it is highly annoying that there is no way to prevent nodes from becoming Guard.
What don't you agree with? With the fact that Tor sticks to a set of three nodes for the first hop of each circuit
This ^
or with the way the guard flag is awarded to nodes?
There should exist a torrc option of "I don't want it, dammit."
-- With respect, Roman
On Sun, 3 Feb 2013 16:53:21 +0200 Konstantinos Asimakis <inshame@gmail.com> wrote:
that someone peeks constantly into your circuits (well 1/3rd of them) for a long time, which is not really worse than peeking for a day into them.
Observing for a long period allows to build some profile on the user, observing for a short time is much more harmless. To continue quoting for you from tor-talk, "...to me it just seems to be an elaborate trade off that results in "if you are f***ed, ensure you are f***ed as completely as possible and with the most dire consequences possible". "An adversary has a chance to see some of my entry traffic for some time" ...seems rather harmless to me compared to the Guards system's of: "an adversary has a chance to see ALL of my entry traffic for a long period" -- With respect, Roman
If you are an insurgent communicating with your comrades, the moment your government sees that you visit some suspicious sites, they will simply get a warrant (or not), get in your house, and use a $5 wrench on you till you start spewing names or cooperate with them and help them catch the rest of your comrades. I don't think they'll just keep watching your connection silently. In other words most governments would prefer to peek once per day into each tor circuit than having the ability to constantly monitor a specific subset of all circuits. The former would practically make Tor useless since anyone running a few guard nodes and a few exit nodes would be able create a graph of users and the sites they visit through Tor. In most cases, there is no way to get "a little" f'ed up unless we are talking about sharing MP3s over Tor. ----- My blog: http://www.inshame.com My full signature with lots of links etc: http://bit.ly/trtsig On Sun, Feb 3, 2013 at 5:08 PM, Roman Mamedov <rm@romanrm.ru> wrote:
On Sun, 3 Feb 2013 16:53:21 +0200 Konstantinos Asimakis <inshame@gmail.com> wrote:
that someone peeks constantly into your circuits (well 1/3rd of them) for a long time, which is not really worse than peeking for a day into them.
Observing for a long period allows to build some profile on the user, observing for a short time is much more harmless. To continue quoting for you from tor-talk, "...to me it just seems to be an elaborate trade off that results in "if you are f***ed, ensure you are f***ed as completely as possible and with the most dire consequences possible".
"An adversary has a chance to see some of my entry traffic for some time"
...seems rather harmless to me compared to the Guards system's of:
"an adversary has a chance to see ALL of my entry traffic for a long period"
-- With respect, Roman
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 01.02.2013 20:38, schrieb Norman Rie:
Am 31.01.2013 um 13:55 schrieb Roman Mamedov <rm@romanrm.ru>:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, 31 Jan 2013 13:34:13 +0100 Norman Rie <norman@smash-net.org> wrote:
Hello,
i have no suggestion, but i am seeing the same thing on my relay.
https://atlas.torproject.org/#details/5A58FB3D0858148D4F4727AAC71B0D67F09033...
Would be nice to know what happened.
Hello,
See my adjacent reply about the Guard status; for yours it is the same, see "guard probability" on graphs about half way down on that page.
- -- With respect, Roman
Thank you!
Norman
Hello, seems like after getting the stable flage, throughput rose significantly. https://atlas.torproject.org/#details/5A58FB3D0858148D4F4727AAC71B0D67F09033... Regards, Norman -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRD1UnAAoJEMCA6frkLT6zbp0H/RY5gHOeFStmfTaloVLzmZJi W51nZ63Ru7onCR/Hh112U0vNH3YcMUg+qSiaw7Znoc9ElCq+kdRxdfYOOtsdDS3k ktp+hnmV20Gy0dYiovUo/flTMNQMmrj2DK4tKTND1kmziPDwMpkrSSeRZpyE6c9K Wf0A5OvsFGwS0pbWouJU9UOdislHH3bepzngdoMT/rIFXqWI8Ar9WH8jQKer1qum 94Cm6OQJX/KGM8iuYiiUWb6B8KCAWCcYwAaC5kbZdr56z18y9XYwRRnEehtKV536 HDLkM049+3eXrwoFjHR+fAelhZ3wgVwmupRbHMK8N+mpLQ2gAubp4dhon4fbLzI= =R7Ug -----END PGP SIGNATURE-----
participants (4)
-
Konstantinos Asimakis -
Matthew Harrold -
Norman Rieß -
Roman Mamedov