- tor-relays - lists.torproject.org

Tor node monitoring
by Alex Beal 17 Apr '13

17 Apr '13

Hello All, I was wondering what, if any, software you use for monitoring your relays. It would be nice if I could get an email when the Tor daemon crashes, and maybe another every night telling me about bandwidth used, average speed, etc. Thanks, Alex -- For sensitive information, use my public key: http://media.usrsb.in/files/pub.asc Fingerprint: 0BCE 27F8 FBED 34C0 B936 7625 1D7D CA76 C811 1C0C

6 5

Tor Relay on DSL connection
by Jochen 16 Apr '13

16 Apr '13

Hello, I'm running a tor relay (non-exit) on DSL connection. My ISP reconnects me every 24 hours and gives me a new ip. How must tor be configured to publish it's new ip address after reconnect? Can tor daemon (linux) do this automatically or do I have to run a cron job and restart service cron at specific times?

3 2

I need to shut down my relay for a month possibly, what should I do
by Nate Homier 15 Apr '13

15 Apr '13

I'm upgrading my internet to a static IP setup with custom reverse DNS, which is perfect for my relay as then all complaints go to the contact info in the reverse DNS, which would be me. However I'm leaving on a month long trip and if the upgrade won't happen before April 17th 9 AM, I probably will half to shut down the server for a month. The server would be turned back on about May 25th or 30th. If I shut down for a month what will happen to my relay. What if someone chooses the same nick for their relay and so on. Nate

3 3

BitTorrent complaint
by bartels 13 Apr '13

13 Apr '13

Hi People, Two days ago I opened two fast tor exit relays v2.3 on debian wheezy. Now I get complaints from paramount that I have unwittingly distributed Hansel and Gretel via BitTorrent <Port>39585</Port> <Type>BitTorrent</Type> Can this be linked to tor, or is that impossible? I don't want to shut down tor for no reason. - Bartels.

11 40

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