tor-relays

tor-relays@lists.torproject.org

42 participants
4821 discussions

On the way to more diversity
by Moritz Bartl 12 Apr '13

12 Apr '13

Hi, I have started to make changes to the Torservers.net website to reflect that we have grown from "professional Tor Exit hosting" to a state where growth of a single organization is not useful any more. We have refrained from ramping up more exit capacity for quite some time because of that. With the help of TorProject Inc., and by being an example for others to follow, we can now refer to multiple organizations, and become an "umbrella organization" that distributes funds across these organizations. Legally, we might be able to offer "abuse handling services" for exit operators. I will discuss this with our lawyer, and keep you updated. With the German charitable Wau Holland Foundation, we have found a first great partner for the "new" Torservers.net. Instead of donating directly to us, you can now donate to the project account at Wau Holland Foundation. Hopefully, we can find even more partners in the future. All partner organizations have been chosen carefully. We will iron out details on how we distribute funds so we get a more diverse Tor network. Please, talk to us if you want to set up a similar organization. https://www.torservers.net/partners.html https://www.torservers.net/donate.html The next step is to also professionalize bridges hosting. It is quite a shame that we only have a few hundred bridges in total. The situation got worse now that regular bridges are blocked in several countries, and in China only obfs3 bridges work -- of which we only have a few. We are actively on the lookout for sponsors interested in funding bridges. -- Moritz Bartl https://www.torservers.net/

7 9

big spike in cpu usage
by Owen Gunden 12 Apr '13

12 Apr '13

I have been running a non-exit tor relay for a few months now. It's on a metered VPS, so after some experimenting I found that I can afford about this much bandwidth: RelayBandwidthRate 250 KB RelayBandwidthBurst 500 KB This worked fine until recently. However, just today I noticed the machine was sluggish, and sure enough tor was using 99% cpu and dumping these messages to syslog: Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [2022 similar message(s) suppressed in last 60 seconds] Digging deeper, I've seen these messages pop up from time to time over the last 30 days or so, but not consistently, and I've never noticed the cpu pegged (but it could have happened, I don't use the machine that often). I tried including: MaxAdvertisedBandwidth 50 KB and # https://lists.torproject.org/pipermail/tor-relays/2012-May/001352.html MaxOnionsPending 250 to no avail. I have had to dial all the way down to: RelayBandwidthRate 40 KB RelayBandwidthBurst 80 KB and that seems to make the messages go away, but the cpu is still pegged and the machine is sluggish. It's running on an up-to-date debian squeeze (6.0.7), with tor 0.2.3.25-1~~squeeze+1 and openssl 0.9.8o-4squeeze14. I run updates fairly often. I upgraded to this version of tor a couple of weeks ago, which could be related, but doesn't correlate perfectly to when I first find the "too slow" messages in my logs. The only other recent updates that seem plausibly related are libbind/libisc/libisccc/etc.

9 15

Relay overload
by cmeclax 11 Apr '13

11 Apr '13

I noticed when sshing to my relay box that it is responding much slower than normal - taking a minute or two to respond to a single keypress. I ran netstat -t and saw lots of bytes in the outqueue to various other relays. I telnetted to port 9051 and got the following bandwidth log: 650 BW 63449 10568 650 BW 62510 21671 650 BW 63433 22438 650 BW 40314 19035 650 BW 94448 61126 650 BW 10408 11154 650 BW 123157 58027 650 BW 62837 31070 650 BW 12002 3536 650 BW 159449 65423 650 BW 64487 23865 650 BW 65471 35381 650 BW 68892 21466 650 BW 65378 46215 650 BW 38807 11434 650 BW 90042 43329 650 BW 65909 44768 650 BW 77162 18627 650 BW 107393 56922 650 BW 67305 36924 650 BW 25255 11149 650 BW 79619 37266 650 BW 123230 25956 650 BW 67194 27742 650 BW 70871 49787 650 BW 62114 50882 650 BW 53981 60433 650 BW 42699 21631 650 BW 161246 77324 650 BW 66421 39994 650 BW 68306 51876 650 BW 37977 21411 650 BW 157806 71560 650 BW 67964 35298 650 BW 64643 38299 650 BW 41193 26601 650 BW 156710 106887 650 BW 18786 14135 650 BW 158192 48526 650 BW 62862 39633 650 BW 67273 38448 650 BW 57955 39696 650 BW 34695 28979 650 BW 156069 81872 650 BW 53572 28598 650 BW 159163 43722 650 BW 65412 41567 650 BW 67271 48134 650 BW 65372 46107 650 BW 36323 14414 650 BW 0 0 650 BW 158006 92438 650 BW 64455 56813 650 BW 53169 11364 650 BW 109892 82106 650 BW 65191 34845 650 BW 12916 10803 650 BW 76387 21984 650 BW 0 0 650 BW 91819 54140 650 BW 63323 43265 650 BW 66760 26847 650 BW 12030 5817 650 BW 62995 16102 650 BW 154965 70999 650 BW 68408 38650 650 BW 87724 30290 650 BW 44543 45024 650 BW 60544 35343 650 BW 103227 35954 650 BW 155268 53094 650 BW 64928 37615 650 BW 66599 33239 650 BW 111463 36394 650 BW 76657 67405 650 BW 65448 40502 650 BW 65778 49605 650 BW 23300 7620 650 BW 155335 70596 650 BW 65994 31356 650 BW 66109 27590 650 BW 158464 72332 650 BW 60705 36345 650 BW 102858 25936 650 BW 161401 24083 650 BW 86788 62280 650 BW 66162 54081 My throughput limit is 64K, which has not previously been a problem. I've sometimes seen steady throughput close to 64K; more often it's sporadic with an average around 5K. Any idea what's going on? I checked Blutmagie; I've lost the fast flag, but have not been selected as guard or any other new flag. I thought it might have something to do with the bitcoin crash that's going on, but netstat -t on the bitcoin box doesn't show any similar attempt to push more data than the line can handle. If I were selected as the middleman in one user's file upload, I'd see a steady stream of traffic, not this spikiness. cmeclax

1 0

Re: [tor-relays] How to limit number of sockets used?
by Roman Mamedov 10 Apr '13

10 Apr '13

On Wed, 10 Apr 2013 07:51:57 -0400 Steve Snyder <swsnyder(a)snydernet.net> wrote: > Yes, I have hit the limit, with the expected "Error creating network > socket: No buffer space available" messages seen. Afaik this is a different error, and it comes from the RAM limit for network buffers, not due to hitting the maximum quantity of open sockets. ConstrainedSockets/ConstrainedSockSize may actually help you here. Also next time you hit this error, check "lsof -n | grep tor | wc -l". My guess is it will be much lower than 4096. -- With respect, Roman

1 0

How to limit number of sockets used?
by Steve Snyder 10 Apr '13

10 Apr '13

I am running Tor v0.2.3.25 in a VPS that limits me to a max of 4096 sockets in use. How can I instruct Tor not to attempt to use more than this number? Yes, I know about ConstrainedSockets/ConstrainedSockSize, but the way I read these it limits the amount of memory used, not the socket count. Advice, please? Thanks.

5 5

Can you double check my exit policy for usefulness while minimizing complaints
by Nate Homier 09 Apr '13

09 Apr '13

I was wondering if I have a good compromise between not allowing BitTorrent and allowing enough ports to be useful. Here's mine. ExitPolicy accept *:119 # accept nntp as well as default exit policy ExitPolicy accept *:22 # ssh ExitPolicy accept *:80 # www ExitPolicy accept *:443 # www secure ExitPolicy accept *:110 # pop3 ExitPolicy accept *:143 # imap ExitPolicy accept *:995 # pop3 secure ExitPolicy accept *:6660-6669 # irc ExitPolicy accept *:6697 # irc ssl ExitPolicy accept *:7000-7001 # irc ssl ExitPolicy accept *:706 # silc ExitPolicy accept *:1863 # msn ExitPolicy accept *:5050 # yahoo messenger ExitPolicy accept *:5190 # various im programs ExitPolicy accept *:5222 # various im programs ExitPolicy accept *:5223 # various im programs ExitPolicy accept *:8300 # im ExitPolicy accept *:8888 # www ExitPolicy accept *:465 # smtps (SMTP over SSL) ExitPolicy accept *:993 # imaps (IMAP over SSL) ExitPolicy accept *:994 # ircs (IRC over SSL) ExitPolicy reject *:* # no exits allowed How does this compare with this policy located here: https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy Should I use the official Tor reduced policy or is mine good enough to be useful while minimizing complaints. Nate

2 2

tor cpu usage
by Martin Weinelt 09 Apr '13

09 Apr '13

Hey, I'm running a tor relay with version 0.2.4.11-alpha and there seems to be an issue about cpu usage. Usually when the bandwidth peaks (at about 10 MBit/s) the cpu is at about 25-35% load, however after a few days it gets stuck at 100%. The notices-logfile, to my knowledge, does not indicate any weirdness. I'm attaching the "[warn]" section though: Apr 04 18:19:16.000 [warn] crypto error while checking RSA signature: block type is not 01 (in rsa routines:RSA_padding_check_PKCS1_type_1) Apr 04 18:19:16.000 [warn] crypto error while checking RSA signature: padding check failed (in rsa routines:RSA_EAY_PUBLIC_DECRYPT) Apr 06 20:38:18.000 [warn] Tried to establish rendezvous on non-OR or non-edge circuit. Apr 06 21:01:05.000 [warn] Tried to establish rendezvous on non-OR or non-edge circuit. Apr 07 04:35:49.000 [warn] eventdns: Unable to add nameserver 2001:4860:4860::8888: error 2 Apr 07 04:35:49.000 [warn] eventdns: Unable to add nameserver 2001:4860:4860::8844: error 2 Unfortunately I don't do any statistics so I can't relate a specific event with the spiking cpu load. Does anybody else experience this? What could cause this? How can I fix it? Martin

1 0

How Can I Do This?
by Barack Obama 08 Apr '13

08 Apr '13

My website, Bypass-Censorship.org, is getting LOTS of spam traffic from Tor (specifically in the wp-cron.php script). I obviously don't want to block Tor as it's extremely beneficial for privacy geeks and people from Iran, China, etc, to access my site; however, I do have an alternative solution that I may need help with. Basically what I want to do is add some PHP code in the beginning of index.php (I use WordPress as my CMS). What the code should do is detect if the client is using Tor, and if the client is, the script redirects to the mobile version of my site (mobile.dudamobile.com/site/bypass-censorship - it is hosted for free on DudaMobile). I believe this would be beneficial for two reasons: 1. Spam attacks and hack attacks are useless since it is not on my primary host (meaning there is no wp-cron.php). 2. And it will take a huge load off my server (I am well-ranked for the term "hidden wiki" in Google and Ixquick). Please tell me what you think of this idea, and how I can implement it. Thanks, -BC

4 3

Advice on configuring Obfsproxy3 transport?
by Steve Snyder 06 Apr '13

06 Apr '13

Attempting to get Obfsproxy3 to work. With Tor v0.2.4.11-alpha and Obfsproxy pulled from https://git.torproject.org/obfsproxy.git yesterday this is what I get at runtime: Apr 05 14:57:23.000 [warn] Server managed proxy encountered a method error. (obfs3 could not setup protocol) Apr 05 14:57:23.000 [warn] Managed proxy at '/usr/bin/obfsproxy' failed the configuration protocol and will be destroyed I have no problems with obfs2, but obfs3 success continues to elude me. These are the relevant lines from my bridge config: ServerTransportListenAddr obfs3 aaa.bb.cc.dd:12647 ServerTransportPlugin obfs3 exec /usr/bin/obfsproxy --managed Any advice on how to get Obfsproxy to work would be greatly appreciated. Thanks.

2 1

Obfsproxy doesn't use specified addresses?
by Steve Snyder 05 Apr '13

05 Apr '13

I've got a server with 2 IP addresses, and a bridge running on each address. I followed the instructions for using Obfsproxy, adding this line to each Tor config file: ServerTransportPlugin obfs2 exec /usr/bin/obfsproxy --managed It seems that Obfsproxy is not running on a per-address basis but instead each instance is bound to all addresses. (See below). Is this really how it is supposed to work? Shouldn't each instance of Obfsproxy be bound to a specific IP address? ----------------- # lsof -ni | grep _tor tor TCP aaa.aa.aa.aa:https (LISTEN) tor TCP aaa.aa.aa.aa:57242->000.00.000.000:https (ESTABLISHED) tor TCP aaa.aa.aa.aa:48851->111.111.111.11:torrouting (ESTABLISHED) tor TCP aaa.aa.aa.aa:34865->222.22.222.222:torrouting (ESTABLISHED) tor TCP bbb.bb.bb.bb:https (LISTEN) tor TCP bbb.bb.bb.bb:42826->333.33.333.33:https (ESTABLISHED) tor TCP bbb.bb.bb.bb:https->444.4.444.444:58519 (ESTABLISHED) tor TCP bbb.bb.bb.bb:33745->55.55.555.55:https (ESTABLISHED) tor TCP bbb.bb.bb.bb:44772->666.666.666.666:https (ESTABLISHED) obfsproxy TCP *:34866 (LISTEN) obfsproxy TCP *:41887 (LISTEN)

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-relays