- tor-relays - lists.torproject.org

hardware
by Andreas Fink 16 Jul '13

16 Jul '13

can someone give me hints on what hardware would be best suited to run big fat tor exit nodes connected with multiple 1gbps or 10gps links? We are considering putting some fat boxes near major internet exchanges of the world. sent from iPhone

5 6

TCP: Peer unexpectedly shrunk window
by krishna e bera 15 Jul '13

15 Jul '13

Are such messages something to worry about? What do they mean? Example from dmesg log: [422949.356062] TCP: Peer 79.22.114.39:60467/9001 unexpectedly shrunk window 2565384113:2565389251 (repaired) [427073.032013] TCP: Peer 217.20.253.198:17482/9001 unexpectedly shrunk window 2017146666:2017147597 (repaired) [478256.668534] TCP: Peer 2.236.7.28:49367/9001 unexpectedly shrunk window 176191274:176194194 (repaired) [502615.724129] TCP: Peer 217.20.253.198:53308/9001 unexpectedly shrunk window 792267503:792268436 (repaired) [514591.656053] TCP: Peer 217.20.253.198:63743/9001 unexpectedly shrunk window 445257517:445258452 (repaired) [527753.064036] TCP: Peer 94.38.5.188:49377/9001 unexpectedly shrunk window 2291195973:2291197433 (repaired) [633078.304041] TCP: Peer 87.89.75.107:59567/9001 unexpectedly shrunk window 3718547610:3718553466 (repaired) [633079.672021] TCP: Peer 87.89.75.107:59567/9001 unexpectedly shrunk window 3718547610:3718553466 (repaired) [673170.600037] TCP: Peer 82.89.173.120:50392/9001 unexpectedly shrunk window 2473022599:2473024051 (repaired) [714540.672036] TCP: Peer 217.20.253.198:20805/9001 unexpectedly shrunk window 3814426018:3814426947 (repaired) [755391.792076] TCP: Peer 79.223.168.103:61238/9001 unexpectedly shrunk window 2799388466:2799406672 (repaired) [755392.864013] TCP: Peer 79.223.168.103:61238/9001 unexpectedly shrunk window 2799388466:2799406672 (repaired)

3 2

Why doesn't my Tor Relay (non-exit) show an Onion Key
by gongeek＠gmail.com 15 Jul '13

15 Jul '13

When i check my running tor relay (Fingerprint: $66a81cecd3aef6999982c5abee1942e3e5ab3b1c ) on this site<https://torstatus.blutmagie.de/router_detail.php?FP=66a81cecd3aef6999982c5a…>i notice that the "Onion Key" field (located near bottom of the page) is empty. My relay has been running for over 24 hours and i still dont see anything in that field. I tested out my relay as an EntryNode and i was able to access the internet through tor fine. I have watched the Bandwidth Graph and seen other users use my Relay so it is running fine. But i cant understand why my Onion Key field is empty. When i check other relays on the site (every relay i've checked) has an Onion Key displayed including relays that have just started running less than 10 mins ago. You can see all the relays here <https://torstatus.blutmagie.de/>. Click any and of the displayed relays and notice each has a displayed Onion Key -- except my relay. Any info on why this is would be great Thanks

2 1

Final Warning Notice
by Chris Sheats 11 Jul '13

11 Jul '13

Hey tor-relays, The past few months, since I upgraded my net connection to 1Gbps, I've hit the top 40 fastest relays and the top 20 fastest exit nodes, peaking to over 17 MB/s. I've always prided the fact that my ISP, CondoInternet in Seattle, has been very welcoming of my reduced exit node. In the past, the malicious activity hasn't been "too much" for my ISP--examples here: http://yawnbox.com/1461--but now they want me to shut it down. What are my options? Forwarded email: Final Warning Notice - IP address 216.243.58.198 I am writing you regarding the repeated abuse complaints that we're receiving for your IP allocation. While we at CondoInternet are all for an open and unmolested with Internet experience for our customers as it was one of our founders' primary reasons for starting CondoInternet, your Tor node has generated a disproportional amount of abuse and legal complaints compared to the rest of our customers. We are asking that you remove the Tor node from your CondoInternet connection or to please switch to an alternative service provider by July 15th 2013. We very much appreciate you being part of the CondoInternet family and do apologize for any inconvenience this change may cause you. Please feel free to contact me directly if you have any questions. Sincerely, Operations Manager CondoInternet -- Chris Sheats yawnbox(a)gmail.com

7 9

How does CERT-FI know my SOCKS4 port?
by Steve Snyder 10 Jul '13

10 Jul '13

My ISP recently sent to me a CERT-FI auto-report on malware-infected servers in my ISP's address space. I was send this report because my IP address was among those flagged. My entry looks like this: 51765|aa.bbb.ccc.dd|2013-07-08 02:39:23 +0000|||Proxy|743230|Datasource: C, Type: SOCKS4 (9050) I am wondering how CERT-FI knows about this port. This is a snippet of my relay config: OutboundBindAddress aa.bbb.ccc.dd ORPort [aa.bbb.ccc.dd]:443 DirPort [aa.bbb.ccc.dd]:80 SocksPort [127.0.0.1]:9050 Given that my SOCKS port is bound to localhost, how does CERT-FI know about it? (For more info on the auto-reporter, go to https://www.cert.fi/en/autoreporter/autoreporter.html and log into it with this username/password: auto/reporter) Thanks.

3 2

Unbalanced send/recieve
by Christian 10 Jul '13

10 Jul '13

Hi all, sorry for my probable newbie question. My bridge's log file reads: Jul 10 11:21:34.000 [notice] Heartbeat: Tor's uptime is 17:52 hours, with 4 circuits open. I've sent 12.55 MB and received 209.33 MB. Is it normal to have such an unbalanced ratio or do I have to worry about something? In the past, I always used to recieve a quart more than I sent which I couldn't quite explain, but now... Thanks for an answer. Sincerly christian

3 2

Circuit creation "storms" overwhelming > Raspberry Pi?
by temp5＠tormail.org 09 Jul '13

09 Jul '13

FWIW, I did some tuning on mine (not a pi, but had similar issues) and it seems more stable now too. I added the following to my torrc (where X and Y are your rates/units): MaxOnionsPending 250 BandwidthRate X BandwidthBurst Y RelayBandwidthRate X RelayBandwidthBurst Y I had the RelayBandwidth options already in it, but I read somewhere the added Bandwidth options above should limit directory port traffic bursts. And MaxOnionsPending allows more to queue up before creating errors. It sounds like the next major version of Tor (in release candidate stage right now) has several performance improvements, so you might just want to wait for that to release and see if the problems disappear on their own thanks to the hard work of the developers! > From: Gordon Morehouse <gordon(a)morehouse.me> > > Hi, Yes. This is absolutely on my to-do list. I've had a family > medical emergency and about 2 or 3 other things recently about that > level of stress, but BELIEVE me, a strategy for getting a Raspberry Pi > to be a rock solid relay is of paramount importance to me. > > I'm hoping to figure out all the tweaks I did, and then make an alpha > version of some iptables rules to defend against the "storms," within > the next couple of weeks. > > Please don't hesitate to bug me about this at my direct email. (The old > one is no longer valid, I've dropped pseudonyms on the tor lists.) > > Thanks much, > -Gordon M. > > > Thomas Hand: >> Hi torsion, >> >> I'm also running a tor relay on a raspberry pi and keep getting these >> storm >> creation events which crash the box. You said you made some adjustments >> to >> the configs to get a more stable system? Can you please email me copies >> of >> the configs or maybe list the changes you made? >> I'm trying to get my pi stable and then perhaps role out a few more >> relay >> nodes to friends and colleagues. >> Thanks, >> >> T >> >> >> On 4 May 2013 22:07, <torsion(a)ftml.net> wrote: >> >>> I did a lot of tuning on the Raspberry Pi and it's now much, much more >>> stable as a Tor relay, but just now I had another "circuit creation >>> storm." Interestingly, the Pi remained up, and my *router* crashed. >>> I've also seen huge bursts of circuit creation on a relay I run on a >>> VPS, but as it's a much more powerful box it rarely complains (and thus >>> I rarely notice). >>> >>> This many circuits and outbound connections is highly unusual for the >>> small relay I'm running on the Pi. And this behavior definitely occurs >>> in bursts. Is this an outbound DDOS or an attack on Tor itself? If >>> the >>> former (or maybe the latter), is there some way I could perhaps use >>> iptables to temporarily "clamp" the ability to open TCP connections >>> when >>> Tor (or anything on the Pi) opens a number over some threshold in some >>> short period of time? >>> >>> Here's log output (via 'arm') from the relay after my router crashed >>> twice, I went to the admin panel and noted hundreds of outbound >>> connections from my Tor box. Time is America/Los_Angeles. >>> >>> ? 13:55:00 [ARM_NOTICE] Relay unresponsive (last heartbeat: Sat May 4 >>> 13:54:14 2013) >>> ? 13:52:25 [WARN] 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. [404 similar message(s) suppressed >>> in last 60 seconds] >>> ? 13:51:07 [WARN] 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. [75 similar message(s) suppressed >>> in >>> last 60 seconds] >>> ? 13:50:52 [WARN] 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. [601 similar message(s) suppressed >>> in last 60 seconds] >>> ? 13:48:39 [WARN] 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. [99 similar message(s) suppressed >>> in >>> last 60 seconds] >>> ? 13:47:34 [WARN] 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. [22 similar message(s) suppressed >>> in >>> last 60 seconds] >>> ? 13:46:17 [WARN] 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. [253 similar message(s) suppressed >>> in last 60 seconds] >>> ? 13:43:47 [WARN] 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. [1396 similar message(s) suppressed >>> in last 60 >>> ? seconds] >>> ? 13:42:48 [WARN] 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. [16 similar message(s) suppressed >>> in >>> last 60 seconds] >>> >>> Here's how it crashed my router (blowing ip_conntrack limits is >>> sufficient only to mess up many of my TCP connections, but eventually >>> the router runs out of memory and starts killing processes): >>> >>> May 4 13:51:24 dedmaus user.warn kernel: ip_conntrack: table full, >>> dropping packet. >>> May 4 13:51:24 dedmaus user.warn kernel: ip_conntrack: table full, >>> dropping packet. >>> May 4 13:51:24 dedmaus user.warn kernel: ip_conntrack: table full, >>> dropping packet. >>> May 4 13:51:25 dedmaus user.warn kernel: ip_conntrack: table full, >>> dropping packet. >>> May 4 13:51:29 dedmaus user.warn kernel: NET: 152 messages suppressed. >>> May 4 13:51:29 dedmaus user.warn kernel: ip_conntrack: table full, >>> dropping packet. >>> May 4 13:51:34 dedmaus user.warn kernel: NET: 193 messages suppressed. >>> May 4 13:51:34 dedmaus user.warn kernel: ip_conntrack: table full, >>> dropping packet. >>> May 4 13:51:39 dedmaus user.warn kernel: NET: 227 messages suppressed. >>> >>> ...ad infinitum with the number of messages suppressed per 5 sec >>> increasing until the router crashes. >>> >>> >>> >>> On Mon, Mar 18, 2013, at 06:18 PM, torsion(a)ftml.net wrote: >>>> I'm also seeing occasional messages like this on the Pi (it never >>>> lasts >>>> long): >>>> >>>> 18:13:24 [ARM_NOTICE] Relay resumed >>>> 18:13:18 [ARM_NOTICE] Relay unresponsive (last heartbeat: Mon Mar 18 >>>> 18:13:04 2013) >>>> 17:28:43 [ARM_NOTICE] Relay resumed >>>> 17:28:38 [ARM_NOTICE] Relay unresponsive (last heartbeat: Mon Mar 18 >>>> 17:28:25 2013) >>>> 14:12:26 [ARM_NOTICE] Relay resumed >>>> 14:12:20 [ARM_WARN] Deduplication took too long. Its current >>>> implementation has difficulty handling large logs so disabling it to >>>> keep the interface responsive. >>>> 14:12:20 [ARM_NOTICE] Relay unresponsive (last heartbeat: Mon Mar 18 >>>> 14:12:06 20 >>>> >>>> On Mon, Mar 18, 2013, at 01:00 PM, torsion(a)ftml.net wrote: >>>>> Hi there, I just joined the mailing list and apologized if this has >>> been >>>>> discussed before. I did find discussion of a similar issue in >>>>> January >>>>> 2013's archive: >>>>> >>>>> >>> https://lists.torproject.org/pipermail/tor-relays/2013-January/001809.html >>>>> >>>>> It's important to note that I believe I've seen (but didn't save >>>>> logs) >>> a >>>>> couple "circuit creation burst" events on my established relay (about >>>>> 5Mbps, stable, guard, non-exit) which was mostly able to handle it >>>>> without crashing as it has plenty of RAM and the above-mentioned >>>>> messages - "Your computer is too slow to handle this many circuit >>>>> creation requests! Please consider using the MaxAdvertisedBandwidth >>>>> config option or choosing a m ore restricted exit policy." - appear >>> only >>>>> with the relay is under load for other reasons AND a large number of >>>>> circuits are being suddenly created. >>>>> >>>>> I wondered if this was some kind of DOS attempt but didn't think much >>> of >>>>> it because my fast relay continued working fine. >>>>> >>>>> However, I've just set up a Raspberry Pi, the 512MB model, as a relay >>> on >>>>> a slower connection. Here are the relevant settings on this relay: >>>>> >>>>> RelayBandwidthRate 130 KB >>>>> RelayBandwidthBurst 340 KB >>>>> >>>>> The Pi has a fairly slow CPU, so I'd occasionally get messages about >>> log >>>>> deduplication being too slow or something, but didn't think much of >>>>> it. >>>>> I finally got the relay up and left it up for over 24 hours. When I >>>>> woke up this morning it had crashed. Here are the relevant log >>> messages >>>>> - note the huge jump in number of circuits between 22:35 and 04:35 >>>>> (maybe I got the Stable flag), then the storm of circuit open >>>>> requests >>>>> starting at 05:49. Eventually I believe the Pi ran out of memory and >>>>> killed the tor process. >>>>> >>>>> What's very interesting here is that my fast VPS relay with a >>>>> RelayBandwidthRate over 5x faster is almost never handling much more >>>>> than 1000 circuits, so why all of a sudden the demand on the Pi >>>>> that's >>>>> advertising a lower bandwidth rate? >>>>> >>>>> Mar 17 22:35:00.000 [notice] Heartbeat: Tor's uptime is 1 day 0:00 >>>>> hours, with 26 circuits open. I've sent 974.13 MB and received 969.92 >>>>> MB. >>>>> Mar 18 04:35:00.000 [notice] Heartbeat: Tor's uptime is 1 day 6:00 >>>>> hours, with 972 circuits open. I've sent 1.61 GB and received 1.59 >>>>> GB. >>>>> Mar 18 05:49:44.000 [warn] 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. >>>>> Mar 18 05:49:44.000 [warn] Failed to hand off onionskin. Closing. >>>>> Mar 18 05:50:44.000 [warn] 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. [5817 similar message(s) suppressed in last 60 seconds] >>>>> Mar 18 05:52:30.000 [warn] Your system clock just jumped 101 seconds >>>>> forward; assuming established circuits no longer work. >>>>> Mar 18 05:53:51.000 [warn] 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. [1055 similar message(s) suppressed in last 60 seconds] >>>>> Mar 18 05:55:14.000 [warn] 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. [329 similar message(s) suppressed in last 60 seconds] >>>>> >>>>> I'd like to figure out just how much the Raspberry Pi is capable of, >>>>> because it could be a cheap way to build out the relay network by >>> people >>>>> who want to donate bandwidth - but of course it needs to be stable, >>>>> and >>>>> something about my setup is not. >>>>> >>>>> Also: >>>>> >>>>> Mar 16 20:55:33.000 [notice] No AES engine found; using AES_* >>> functions. >>>>> >>>>> I have no idea if the Broadcom BCM2835 SoC (ARM1176JZF-S CPU) in the >>>>> Pi >>>>> has any AES capability, but it'd be great to find out. >>>>> >>>>> _______________________________________________ >>>>> tor-relays mailing list >>>>> tor-relays(a)lists.torproject.org >>>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >>> _______________________________________________ >>> tor-relays mailing list >>> tor-relays(a)lists.torproject.org >>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >>> >> >> >> >> _______________________________________________ >> tor-relays mailing list >> tor-relays(a)lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> > >

1 0

Relay identity
by Jochen 08 Jul '13

08 Jul '13

Hello, I want to create a Raspberry PI image with preinstalled TOR relay for some friends. I will also include a config script to customize torrc (Nickname etc.). I also need to generate a new identity key in this script, so that every node is unique. But I don't know how to generate a new identity. Is there a command to do that, or must I remove /var/lib/*tor*/keys/?

2 1

Circuit creation "storms" overwhelming Raspberry Pi?
by torsion＠ftml.net 08 Jul '13

08 Jul '13

Hi there, I just joined the mailing list and apologized if this has been discussed before. I did find discussion of a similar issue in January 2013's archive: https://lists.torproject.org/pipermail/tor-relays/2013-January/001809.html It's important to note that I believe I've seen (but didn't save logs) a couple "circuit creation burst" events on my established relay (about 5Mbps, stable, guard, non-exit) which was mostly able to handle it without crashing as it has plenty of RAM and the above-mentioned messages - "Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a m ore restricted exit policy." - appear only with the relay is under load for other reasons AND a large number of circuits are being suddenly created. I wondered if this was some kind of DOS attempt but didn't think much of it because my fast relay continued working fine. However, I've just set up a Raspberry Pi, the 512MB model, as a relay on a slower connection. Here are the relevant settings on this relay: RelayBandwidthRate 130 KB RelayBandwidthBurst 340 KB The Pi has a fairly slow CPU, so I'd occasionally get messages about log deduplication being too slow or something, but didn't think much of it. I finally got the relay up and left it up for over 24 hours. When I woke up this morning it had crashed. Here are the relevant log messages - note the huge jump in number of circuits between 22:35 and 04:35 (maybe I got the Stable flag), then the storm of circuit open requests starting at 05:49. Eventually I believe the Pi ran out of memory and killed the tor process. What's very interesting here is that my fast VPS relay with a RelayBandwidthRate over 5x faster is almost never handling much more than 1000 circuits, so why all of a sudden the demand on the Pi that's advertising a lower bandwidth rate? Mar 17 22:35:00.000 [notice] Heartbeat: Tor's uptime is 1 day 0:00 hours, with 26 circuits open. I've sent 974.13 MB and received 969.92 MB. Mar 18 04:35:00.000 [notice] Heartbeat: Tor's uptime is 1 day 6:00 hours, with 972 circuits open. I've sent 1.61 GB and received 1.59 GB. Mar 18 05:49:44.000 [warn] 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. Mar 18 05:49:44.000 [warn] Failed to hand off onionskin. Closing. Mar 18 05:50:44.000 [warn] 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. [5817 similar message(s) suppressed in last 60 seconds] Mar 18 05:52:30.000 [warn] Your system clock just jumped 101 seconds forward; assuming established circuits no longer work. Mar 18 05:53:51.000 [warn] 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. [1055 similar message(s) suppressed in last 60 seconds] Mar 18 05:55:14.000 [warn] 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. [329 similar message(s) suppressed in last 60 seconds] I'd like to figure out just how much the Raspberry Pi is capable of, because it could be a cheap way to build out the relay network by people who want to donate bandwidth - but of course it needs to be stable, and something about my setup is not. Also: Mar 16 20:55:33.000 [notice] No AES engine found; using AES_* functions. I have no idea if the Broadcom BCM2835 SoC (ARM1176JZF-S CPU) in the Pi has any AES capability, but it'd be great to find out.

3 4

Re: [tor-relays] stats
by Armand 07 Jul '13

07 Jul '13

Sent from my Cricket smart phone ma455(a)mykolab.com wrote: >hello, >i'm running an exit node from 2 or 3 month, in UA, on a vps, xeon 2650 >2Ghz, 128mb RAM, debian 6 >tor v0.2.3.25-1 > > >on atlas there is some stat on those days it's seem to be at max 100Kb/s > > > > > > > >//atlas.torproject.org/#details/62C3FB37C44555E55A62BBD7CDDD97FE4894F317 > >but on arm or with iftop i'm beetween 300 and 900Kb/s download and the >same in upload > >my load average is 4.74, 2.97, 2.98 >there is just tor on this server > >this append form the beguining, > >there is a problem? who is right? can you help me to verify if my node >is fine configured? > > >thanks > >PS: sorry for my english is not my first language >_______________________________________________ >tor-relays mailing list >tor-relays(a)lists.torproject.org >https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

3 2

stats
by ma455＠mykolab.com 07 Jul '13

07 Jul '13

hello, i'm running an exit node from 2 or 3 month, in UA, on a vps, xeon 2650 2Ghz, 128mb RAM, debian 6 tor v0.2.3.25-1 on atlas there is some stat on those days it's seem to be at max 100Kb/s //atlas.torproject.org/#details/62C3FB37C44555E55A62BBD7CDDD97FE4894F317 but on arm or with iftop i'm beetween 300 and 900Kb/s download and the same in upload my load average is 4.74, 2.97, 2.98 there is just tor on this server this append form the beguining, there is a problem? who is right? can you help me to verify if my node is fine configured? thanks PS: sorry for my english is not my first language

2 2

Re: [tor-relays] stats
by Armand 07 Jul '13

07 Jul '13

Sent from my Cricket smart phone ma455(a)mykolab.com wrote: >hello, >i'm running an exit node from 2 or 3 month, in UA, on a vps, xeon 2650 >2Ghz, 128mb RAM, debian 6 >tor v0.2.3.25-1 > > >on atlas there is some stat on those days it's seem to be at max 100Kb/s > > > > > > > >//atlas.torproject.org/#details/62C3FB37C44555E55A62BBD7CDDD97FE4894F317 > >but on arm or with iftop i'm beetween 300 and 900Kb/s download and the >same in upload > >my load average is 4.74, 2.97, 2.98 >there is just tor on this server > >this append form the beguining, > >there is a problem? who is right? can you help me to verify if my node >is fine configured? > > >thanks > >PS: sorry for my english is not my first language >_______________________________________________ >tor-relays mailing list >tor-relays(a)lists.torproject.org >https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

1 0

Address mismatch on received DNS packet
by TonyXue 05 Jul '13

05 Jul '13

Hi Everyone, I've just started to run a tor relay these days. But there are many warnings like this in my log file. Jul 05 11:25:19.000 [warn] eventdns: Address mismatch on received DNS packet. Apparent source was 66.80.130.234:53Jul 05 11:25:38.000 [warn] eventdns: Address mismatch on received DNS packet. Apparent source was 66.80.130.235:53Jul 05 11:25:42.000 [warn] eventdns: Address mismatch on received DNS packet. Apparent source was 66.80.130.235:53Jul 05 11:32:18.000 [warn] eventdns: Address mismatch on received DNS packet. Apparent source was 66.80.130.235:53Jul 05 11:32:18.000 [warn] eventdns: Address mismatch on received DNS packet. Apparent source was 66.80.130.235:53Jul 05 11:32:18.000 [warn] eventdns: Address mismatch on received DNS packet. Apparent source was 66.80.130.234:53Jul 05 11:32:18.000 [warn] eventdns: Address mismatch on received DNS packet. Apparent source was 66.80.130.234:53Jul 05 11:32:23.000 [warn] eventdns: Address mismatch on received DNS packet. Apparent source was 66.80.130.236:53Jul 05 11:39:14.000 [warn] eventdns: Address mismatch on received DNS packet. Apparent source was 66.80.130.235:53Jul 05 11:39:48.000 [warn] eventdns: Address mismatch on received DNS packet. Apparent source was 66.80.130.235:53Jul 05 11:39:48.000 [warn] eventdns: Address mismatch on received DNS packet. Apparent source was 66.80.130.235:53Jul 05 11:39:48.000 [warn] eventdns: Address mismatch on received DNS packet. Apparent source was 66.80.130.235:53Jul 05 11:39:48.000 [warn] eventdns: Address mismatch on received DNS packet. Apparent source was 66.80.130.234:53Jul 05 11:39:48.000 [warn] eventdns: Address mismatch on received DNS packet. Apparent source was 66.80.130.236:53Jul 05 11:39:53.000 [warn] eventdns: Address mismatch on received DNS packet. Apparent source was 66.80.130.234:53Jul 05 11:39:53.000 [warn] eventdns: Address mismatch on received DNS packet. Apparent source was 66.80.130.234:53Jul 05 11:39:58.000 [warn] eventdns: Address mismatch on received DNS packet. Apparent source was 66.80.130.235:53 Also with some warnings: Jul 05 12:36:58.000 [warn] eventdns: All nameservers have failedJul 05 12:36:58.000 [notice] eventdns: Nameserver 64.81.45.2:53 is back up Is the nameservers mentioned above are set to be Tor's resolvers? If they are, where can I change the settings of DNS servers? Hope someone can help me with this... Thanks a lot.

3 2

Vidalia can't open Tor after machine restart
by Shane Nagle 04 Jul '13

04 Jul '13

Hello Tor team! And thanks so much for doing what you do. I have a novice/newbie question. Perhaps you could point me to the best source of problem solving data/info you have regarding it. My problem is: after successfully downloading TBB 64bit, and having the browser work very well all day, I shut down my machine at night, then restart the next day only to find that Vidalia cannot open Tor. I've done this four times now. The 'temporary solution' each time was to uninstall, re-download and install TBB again. However the same errors would occur the following morning. I see this: in the fIrefox interface - Firefox is configured to use a proxy server that is refusing connections. And in the Vidalia pane: Vidalia was unable to connect to Tor. (Connection refused by peer.) I have sent several emails to the Tor mailing lists but so far have heard no reply or seen any posting of my inquiry. Any support would be appreciated. S

2 1

Summary of v0.2.3.x --> v0.2.4.x changes?
by Steve Snyder 04 Jul '13

04 Jul '13

Now that Tor v0.2.4.x has reached Release Candidate status, could someone please inform those who haven't been following the development process what is new? I just mean the broad strokes. Like: What changes to a working relay are required or recommended when moving to v0.2.4.x? What are the major new features of this release? (Any benefit now to using more than 2 CPU cores? IPv6 support for non-bridge relays? That sort of thing.) Thanks.

2 1

Re: [tor-relays] [tor-talk] Theft of Tor relay private keys?
by Mike Perry 03 Jul '13

03 Jul '13

thomas.hluchnik(a)netcologne.de: > Hello all, please help me understanding this: > > supposed, the NSA were able to break into a large scale of tor nodes, > stealing the tor private server key. At the same time they were able > to gather all traffic they can get. Wouldnt this increase the > likelihood that data from complete circuits can be decrypted and > traced back to the original sender? If their intercepts are passive, merely stealing relays' private identity key won't accomplish much because Tor uses Forward Secrecy for both the relay TLS links and for circuit setup. https://en.wikipedia.org/wiki/Perfect_forward_secrecy However, if their intercepts are active (as in they can arbitrarily manipulate traffic in-flight), then stealing either Guard node keys or directory authority keys allows complete route capture and traffic discovery of targeted clients. So you are right to worry about this, in my opinion. I am also very concerned. I want to make some changes to Tor to make such key theft easier to detect, less damaging, and harder to make use of: https://trac.torproject.org/projects/tor/ticket/7126 https://trac.torproject.org/projects/tor/ticket/5968 However, I want to do a lot of other things in 0.2.5.x though too, and there's this whole browser thing that I'm technically supposed to be paying attention to too, so I might not get to those. :/ That first one (#7126) is probably a good volunteer/student project for someone who likes Python, though. It would be easy to make a prototype with Stem, txtorcon, or even TorCtl. > Maybe this is paranoid, but this arises the question for me: what > would happen when I stop my tor node once a week, throw away my keys > and restart tor so that new server keys were generated. So NSA would > have to break into my system again, but this would make it harder for > NSA agency to decrypt circuits where my host is involved. I am in favor of regular identity key rotation for relays, and I want to work towards supporting that better by default: https://trac.torproject.org/projects/tor/ticket/5563 I think keeping your keys on a ramdisk or encrypted filesystem with a memory-only random key (so if you experience unexplained reboots, etc they go away) is a good idea. Also, since Tor reads/creates its identity key at startup and doesn't need the file afterwords, you can even 'shred'/'wipe' it after that, so the adversary can't easily pull them off the FS while the system is running. Better still, you can load a Kernel module to disable gdb debugger support so the adversary has to actually dig through/manipulate raw memory to get the key (which will be error prone and is more likely to lead to crashes/panics/reboots): https://gist.github.com/1216637 I started describing these and related ideas here: https://trac.torproject.org/projects/tor/wiki/doc/TorRelaySecurity But I got distracted by more pressing issues before I could finish the scripts.. Also, many of those encrypted+authenticated Tor container things probably don't make much sense without Secure Boot to authenticate the boot process up until you can start up Tor. :/ > What were the disadvantages for the tor network? Would this confuse > the tor director in any way? Sort of. Weekly identity key rotation is too frequent to recommend for people to do for a few reasons. First, it takes the bandwidth measurement servers a couple days to ramp up your capacity of your new identity key, so you will spend a lot of time below your max throughput. Second, you would also likely never get the Guard flag. Third, there are also load balancing issues with Guard nodes where as soon as you get the Guard flag, it will take 1-2 months before clients switch to your new Guard, so you will also likely spend that time at less than your full capacity. > Would it be able to keep the nickname or would it have to change also? > Would this have effect on the onion address if I had a hidden server? No and no, but your hidden server might have brief downtimes/descriptor publish times that correlate with your key rotation. Not sure how severe that is in practice. -- Mike Perry

2 1

Exit node with bad time.
by Bernard Tyers - ei8fdb 02 Jul '13

02 Jul '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi there, I am running an exit node on a VPS. For some reason (I've opened a support ticket) a) my systems clock is off by 2 hours (even though its hosted in CEST land) and b) I cannot change it, even though I am root. As a result, I am getting recurring skewed time errors as below: Accounting (awake) Time to reset: 29:12:02:58 21 GB / 1 PB 22 GB / 1 PB Events (TOR/ARM NOTICE - ERR): │ 12:25:39 [WARN] Received directory with skewed time (server '86.59.21.38:80'): It seems that our clock is ahead by 2 hours, 3 minutes, or that theirs is behind. Tor requires an accurate clock to work: please check your time, timezone, and date settings. │ 12:25:03 [WARN] Received NETINFO cell with skewed time from server at 76.73.17.194:9090. It seems that our clock is ahead by 2 hours, 3 minutes, or that theirs is behind. Tor requires an accurate clock to work: please check your time and date settings. I haven't found any mention in the archives of this (except [1] which is NOT the same, just mentions wrong time), if it results in issues to the network overall. Until I can get it resolved (today hopefully) is there any negative affects on the network of having a node with bad time? thanks, Bernard [1] https://lists.torproject.org/pipermail/tor-relays/2011-November/001001.html - -------------------------------------- Bernard / bluboxthief / ei8fdb IO91XM / www.ei8fdb.org -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJR0o/WAAoJENsz1IO7MIrr8SoIALW8W1+SawsVv6r2sLCEPetp u05dGZ4E2vyuey5VIRfPsG1Lc2kPmE+dzY2jgHm2Q66htBqMXtv+WQ1P8TMBYyzj ke/LkXOW2aE2NkyJ95navfnImJGWS+Ie4eyk+PnHL0d6RoRc9K2JKnQKTCPLRQvQ kiFUkKWuHVn/aRzalrlKH7yFdoPosh5pdqqyRLQ4sDQ0dAye0u4GxfvMsrdCP8oO ediSXiRaupSr24V+yK7ceZNUiEBcdNp6VudwJXQ+YH1uF4obSHeVWQFC7ZRpAbAI VrqNVqBx7Xbij0wC83VR6ifz/AYJNoKlG56H72w/jg1hVwi7x58CIuLWBOm1bUM= =2AY7 -----END PGP SIGNATURE-----

2 2

Tor Exit Node and Skype
by var 28 Jun '13

28 Jun '13

Hello everybody, I am running a Tor exit node since some year´s. In the last month I experienced problems with Skype. Skype won´t connect anymore....but if I shutdown the EXIT NODE Skype connects again. Just want to ask all of you if you experienced similar problems? I also opened a ticket at Skype.com So if you got the same problem like me pls go there and post some additional information. > http://community.skype.com/t5/Security-Privacy-Trust-and/Is-Skype-blocking-… Cheers VarVarna

6 5

Munin graphs from fast relays before/after crypto acceleration
by Karsten Loesing 19 Jun '13

19 Jun '13

Hi fast-relay operators, I'm looking for some Munin graphs (or similar) showing the effect of turning on crypto acceleration on fast relays. Does anyone have such graphs to share that show decrease in CPU load and corresponding increase in bandwidth use? Thanks! Karsten

1 0

Upload and download data usage do not match
by Torry Torah 17 Jun '13

17 Jun '13

Hi, I've set up my relays as obfuscated bridges and when I run arm, I see that there's been ~100MB of data downloaded but only ~20MB of data uploaded. Is it the desired behaviour, or is there a config issue on my side? Cheers, -- Torry

1 0

Re: [tor-relays] [tor-talk] Tor 0.2.4.13-alpha is out
by Mike Perry 17 Jun '13

17 Jun '13

Roger Dingledine: > Tor 0.2.4.13-alpha fixes a variety of potential remote crash > vulnerabilities, makes socks5 username/password circuit isolation > actually actually work (this time for sure!), and cleans up a bunch > of other issues in preparation for a release candidate. > > https://www.torproject.org/dist/ As a heads up, a bug was introduced in this release that allows malicious websites to discover a client's Guard nodes in a very short amount of time (on the order an hour), if those Guard nodes upgrade to this release. Unfortunately, the bug was introduced by fixing another issue that allows Guard nodes to be selectively DoSed with an OOM condition, so Guard node (and Guard+Exit node) operators are kind of in a jam. I think the best course of action is to suggest that nodes with the Guard flag *not* upgrade to this release, unless they are experiencing unexplained OOMing? If we can't find a solution that rigorously fixes both issues, I think that future releases should have the OOM DoS fix off by default but available through a torrc option. See also: https://trac.torproject.org/projects/tor/ticket/9072 > Changes in version 0.2.4.13-alpha - 2013-06-14 > o Major bugfixes (robustness): > - Close any circuit that has too many cells queued on it. Fixes > bug 9063; bugfix on the 54th commit of Tor. This bug is a further > fix beyond bug 6252, whose fix was merged into 0.2.3.21-rc. > - Prevent the get_freelists() function from running off the end of > the list of freelists if it somehow gets an unrecognized > allocation. Fixes bug 8844; bugfix on 0.2.0.16-alpha. Reported by > eugenis. > - Avoid an assertion failure on OpenBSD (and perhaps other BSDs) > when an exit connection with optimistic data succeeds immediately > rather than returning EINPROGRESS. Fixes bug 9017; bugfix on > 0.2.3.1-alpha. > - Fix a directory authority crash bug when building a consensus > using an older consensus as its basis. Fixes bug 8833. Bugfix > on 0.2.4.12-alpha. > > o Major bugfixes: > - Avoid a memory leak where we would leak a consensus body when we > find that a consensus which we couldn't previously verify due to > missing certificates is now verifiable. Fixes bug 8719; bugfix > on 0.2.0.10-alpha. > - We used to always request authority certificates by identity digest, > meaning we'd get the newest one even when we wanted one with a > different signing key. Then we would complain about being given > a certificate we already had, and never get the one we really > wanted. Now we use the "fp-sk/" resource as well as the "fp/" > resource to request the one we want. Fixes bug 5595; bugfix on > 0.2.0.8-alpha. > - Follow the socks5 protocol when offering username/password > authentication. The fix for bug 8117 exposed this bug, and it > turns out real-world applications like Pidgin do care. Bugfix on > 0.2.3.2-alpha; fixes bug 8879. > - Prevent failures on Windows Vista and later when rebuilding the > microdescriptor cache. Diagnosed by Robert Ransom. Fixes bug 8822; > bugfix on 0.2.4.12-alpha. > > o Minor bugfixes: > - Fix an impossible buffer overrun in the AES unit tests. Fixes > bug 8845; bugfix on 0.2.0.7-alpha. Found by eugenis. > - If for some reason we fail to write a microdescriptor while > rebuilding the cache, do not let the annotations from that > microdescriptor linger in the cache file, and do not let the > microdescriptor stay recorded as present in its old location. > Fixes bug 9047; bugfix on 0.2.2.6-alpha. > - Fix a memory leak that would occur whenever a configuration > option changed. Fixes bug 8718; bugfix on 0.2.3.3-alpha. > - Paste the description for PathBias parameters from the man > page into or.h, so the code documents them too. Fixes bug 7982; > bugfix on 0.2.3.17-beta and 0.2.4.8-alpha. > - Relays now treat a changed IPv6 ORPort as sufficient reason to > publish an updated descriptor. Fixes bug 6026; bugfix on > 0.2.4.1-alpha. > - When launching a resolve request on behalf of an AF_UNIX control > socket, omit the address field of the new entry connection, used in > subsequent controller events, rather than letting tor_dup_addr() > set it to "<unknown address type>". Fixes bug 8639; bugfix on > 0.2.4.12-alpha. > > o Minor bugfixes (log messages): > - Fix a scaling issue in the path bias accounting code that > resulted in "Bug:" log messages from either > pathbias_scale_close_rates() or pathbias_count_build_success(). > This represents a bugfix on a previous bugfix: the original fix > attempted in 0.2.4.10-alpha was incomplete. Fixes bug 8235; bugfix > on 0.2.4.1-alpha. > - Give a less useless error message when the user asks for an IPv4 > address on an IPv6-only port, or vice versa. Fixes bug 8846; bugfix > on 0.2.4.7-alpha. > > o Minor features: > - Downgrade "unexpected SENDME" warnings to protocol-warn for 0.2.4.x, > to tolerate bug 8093 for now. > - Add an "ignoring-advertised-bws" boolean to the flag-threshold lines > in directory authority votes to describe whether they have enough > measured bandwidths to ignore advertised (relay descriptor) > bandwidth claims. Resolves ticket 8711. > - Update to the June 5 2013 Maxmind GeoLite Country database. > > o Removed documentation: > - Remove some of the older contents of doc/ as obsolete; move others > to torspec.git. Fixes bug 8965. > > o Code simplification and refactoring: > - Avoid using character buffers when constructing most directory > objects: this approach was unwieldy and error-prone. Instead, > build smartlists of strings, and concatenate them when done. > > _______________________________________________ > tor-talk mailing list > tor-talk(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk -- Mike Perry

2 1

Email to post to list
by S.P. Ace 14 Jun '13

14 Jun '13

Just emailing to be able to post. Thanks.

1 0

Multiple Bridges on same AWS Account
by torrelay＠mail.md 10 Jun '13

10 Jun '13

Greetings! I currently have 1 bridge relay running on my AWS account. Is it possible to add another 2 bridge relays to run as separate instances from the same AWS account? I'm wondering if there might be issues with IP address allocation? For example, would I need to make any ammendment to the tor configuration file a la 'tor family' to differentiate between the different nodes running on the same amazon account? Any advise appreciated. Best regards, Johnnie

5 10

Bandwidth/Accounting considerations
by Conrad Hoffmann 07 Jun '13

07 Jun '13

Dear all, I have now been running an exit node for approximately two weeks, it has a fast connection (100Mbit) but I have a traffic limit of 1000GB per month. I have been closely monitoring it via [1] and Munin. I believe to have read that using accounting/hibernation is preferrable over rate limiting with fast connections, but I can't seem to find the exact page at the moment. As you can see (well, guess) from [1], the node is up for about 6-8 hours until its daily quota (currently 10GB, may become a little more) is exhausted, with peaks of around 900K/s but usually around 400-500K/s. In my quest to maximize the usefulness of my node, I would very much appreciate if someone could explain or make educated guesses about the following questions: 1. Note that there are two significant dips in the exit probability chart [1]. The first one I can explain, because I had to reconfigure and restart the server. Nothing special happened after that. What may have caused the second dip? What tools could I use to figure it out/monitor it in the future? 2. My server is bored in terms of memory/CPU usage. I set NumCPUs to 2 and BandwidthRate 100 MB, BandwidthBurst 200 MB as suggested in [2]. Besides the fact that I wouldn't want to exhaust my daily quota in a few hours, shouldn't the traffic become more than 900K/s peaks? 3. What is a good trade-off in terms of speed and uptime with such a daily quota? Should I go for speed? If so, are there any pretty graphs that show at what time of the day the Tor network needs the most bandwidth? If I should go for uptime, what is a good bandwidth limit to keep this a fast node? 4. I enabled directory mirroring, but apparently this does not work with hibernation (i.e. it is not advertised). If I understand correctly, directory mirrors are very useful, so how does that weigh in on the decision to maybe limit the bandwidth to keep the node up 24/7? 5. Related to 4., why is DirPort not advertised when hibernation is configured? References to papers are sufficient if this requires a complicated answer :) [1] https://atlas.torproject.org/#details/5A91910C1B3F3FCC15EA6C6538FB9A5FAF360… [2] http://archives.seul.org/or/relays/Aug-2010/msg00034.html Thank you very much for any pointer on any of these questions! Cheers, Conrad

2 1

Re: [tor-relays] Circuit creation "storms" overwhelming Raspberry Pi?
by temp5＠tormail.org 06 Jun '13

06 Jun '13

I've been seeing these storms as well on my relay. I average something like 100 connections for weeks and weeks per the tor logs, but then suddenly it will jump into the thousands and I'll see the "Failed to hand off onionskin." and "Your computer is too slow to handle this many circuit creation requests!" messages. I wonder if it's some type of DDOS too. I thought about using this method (http://www.debian-administration.org/articles/187) on the relay and dir ports, but I'm not sure what sort of limits to set. Like does 1 Tor circuit = 1 iptables connection? Or if a user hits a webpage with 100 ads on it, maybe it would be 1 Tor circuit = 100 iptables connections? That's about as far as I got. I didn't want to break things by trying to fix another. > I did a lot of tuning on the Raspberry Pi and it's now much, much more > stable as a Tor relay, but just now I had another "circuit creation > storm." Interestingly, the Pi remained up, and my *router* crashed. > I've also seen huge bursts of circuit creation on a relay I run on a > VPS, but as it's a much more powerful box it rarely complains (and thus > I rarely notice). > > This many circuits and outbound connections is highly unusual for the > small relay I'm running on the Pi. And this behavior definitely occurs > in bursts. Is this an outbound DDOS or an attack on Tor itself? If the > former (or maybe the latter), is there some way I could perhaps use > iptables to temporarily "clamp" the ability to open TCP connections when > Tor (or anything on the Pi) opens a number over some threshold in some > short period of time? > > Here's log output (via 'arm') from the relay after my router crashed > twice, I went to the admin panel and noted hundreds of outbound > connections from my Tor box. Time is America/Los_Angeles. > > │ 13:55:00 [ARM_NOTICE] Relay unresponsive (last heartbeat: Sat May > 4 13:54:14 2013) > │ 13:52:25 [WARN] 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. [404 similar message(s) > suppressed > in last 60 seconds] > │ 13:51:07 [WARN] 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. [75 similar message(s) > suppressed in > last 60 seconds] > │ 13:50:52 [WARN] 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. [601 similar message(s) > suppressed > in last 60 seconds] > │ 13:48:39 [WARN] 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. [99 similar message(s) > suppressed in > last 60 seconds] > │ 13:47:34 [WARN] 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. [22 similar message(s) > suppressed in > last 60 seconds] > │ 13:46:17 [WARN] 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. [253 similar message(s) > suppressed > in last 60 seconds] > │ 13:43:47 [WARN] 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. [1396 similar message(s) > suppressed > in last 60 > │ seconds] > │ 13:42:48 [WARN] 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. [16 similar message(s) > suppressed in > last 60 seconds] > > Here's how it crashed my router (blowing ip_conntrack limits is > sufficient only to mess up many of my TCP connections, but eventually > the router runs out of memory and starts killing processes): > > May 4 13:51:24 dedmaus user.warn kernel: ip_conntrack: table full, > dropping packet. > May 4 13:51:24 dedmaus user.warn kernel: ip_conntrack: table full, > dropping packet. > May 4 13:51:24 dedmaus user.warn kernel: ip_conntrack: table full, > dropping packet. > May 4 13:51:25 dedmaus user.warn kernel: ip_conntrack: table full, > dropping packet. > May 4 13:51:29 dedmaus user.warn kernel: NET: 152 messages suppressed. > May 4 13:51:29 dedmaus user.warn kernel: ip_conntrack: table full, > dropping packet. > May 4 13:51:34 dedmaus user.warn kernel: NET: 193 messages suppressed. > May 4 13:51:34 dedmaus user.warn kernel: ip_conntrack: table full, > dropping packet. > May 4 13:51:39 dedmaus user.warn kernel: NET: 227 messages suppressed. > > ...ad infinitum with the number of messages suppressed per 5 sec > increasing until the router crashes. > > > > On Mon, Mar 18, 2013, at 06:18 PM, torsion at ftml.net wrote: >> I'm also seeing occasional messages like this on the Pi (it never lasts >> long): >> >> 18:13:24 [ARM_NOTICE] Relay resumed >> 18:13:18 [ARM_NOTICE] Relay unresponsive (last heartbeat: Mon Mar 18 >> 18:13:04 2013) >> 17:28:43 [ARM_NOTICE] Relay resumed >> 17:28:38 [ARM_NOTICE] Relay unresponsive (last heartbeat: Mon Mar 18 >> 17:28:25 2013) >> 14:12:26 [ARM_NOTICE] Relay resumed >> 14:12:20 [ARM_WARN] Deduplication took too long. Its current >> implementation has difficulty handling large logs so disabling it to >> keep the interface responsive. >> 14:12:20 [ARM_NOTICE] Relay unresponsive (last heartbeat: Mon Mar 18 >> 14:12:06 20 >> >> On Mon, Mar 18, 2013, at 01:00 PM, torsion at ftml.net wrote: >> > Hi there, I just joined the mailing list and apologized if this has >> been >> > discussed before. I did find discussion of a similar issue in January >> > 2013's archive: >> > >> > https://lists.torproject.org/pipermail/tor-relays/2013-January/001809.html >> > >> > It's important to note that I believe I've seen (but didn't save logs) >> a >> > couple "circuit creation burst" events on my established relay (about >> > 5Mbps, stable, guard, non-exit) which was mostly able to handle it >> > without crashing as it has plenty of RAM and the above-mentioned >> > messages - "Your computer is too slow to handle this many circuit >> > creation requests! Please consider using the MaxAdvertisedBandwidth >> > config option or choosing a m ore restricted exit policy." - appear >> only >> > with the relay is under load for other reasons AND a large number of >> > circuits are being suddenly created. >> > >> > I wondered if this was some kind of DOS attempt but didn't think much >> of >> > it because my fast relay continued working fine. >> > >> > However, I've just set up a Raspberry Pi, the 512MB model, as a relay >> on >> > a slower connection. Here are the relevant settings on this relay: >> > >> > RelayBandwidthRate 130 KB >> > RelayBandwidthBurst 340 KB >> > >> > The Pi has a fairly slow CPU, so I'd occasionally get messages about >> log >> > deduplication being too slow or something, but didn't think much of >> it. >> > I finally got the relay up and left it up for over 24 hours. When I >> > woke up this morning it had crashed. Here are the relevant log >> messages >> > - note the huge jump in number of circuits between 22:35 and 04:35 >> > (maybe I got the Stable flag), then the storm of circuit open requests >> > starting at 05:49. Eventually I believe the Pi ran out of memory and >> > killed the tor process. >> > >> > What's very interesting here is that my fast VPS relay with a >> > RelayBandwidthRate over 5x faster is almost never handling much more >> > than 1000 circuits, so why all of a sudden the demand on the Pi that's >> > advertising a lower bandwidth rate? >> > >> > Mar 17 22:35:00.000 [notice] Heartbeat: Tor's uptime is 1 day 0:00 >> > hours, with 26 circuits open. I've sent 974.13 MB and received 969.92 >> > MB. >> > Mar 18 04:35:00.000 [notice] Heartbeat: Tor's uptime is 1 day 6:00 >> > hours, with 972 circuits open. I've sent 1.61 GB and received 1.59 GB. >> > Mar 18 05:49:44.000 [warn] 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. >> > Mar 18 05:49:44.000 [warn] Failed to hand off onionskin. Closing. >> > Mar 18 05:50:44.000 [warn] 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. [5817 similar message(s) suppressed in last 60 seconds] >> > Mar 18 05:52:30.000 [warn] Your system clock just jumped 101 seconds >> > forward; assuming established circuits no longer work. >> > Mar 18 05:53:51.000 [warn] 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. [1055 similar message(s) suppressed in last 60 seconds] >> > Mar 18 05:55:14.000 [warn] 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. [329 similar message(s) suppressed in last 60 seconds] >> > >> > I'd like to figure out just how much the Raspberry Pi is capable of, >> > because it could be a cheap way to build out the relay network by >> people >> > who want to donate bandwidth - but of course it needs to be stable, >> and >> > something about my setup is not. >> > >> > Also: >> > >> > Mar 16 20:55:33.000 [notice] No AES engine found; using AES_* >> functions. >> > >> > I have no idea if the Broadcom BCM2835 SoC (ARM1176JZF-S CPU) in the >> Pi >> > has any AES capability, but it'd be great to find out. > > >

4 3

Running Obfsproxy on a Raspberry Pi
by Richard Budd 01 Jun '13

01 Jun '13

Don't know how common this is but I've had a Pi running for 35 days 6 hours (so far). With over 80GB transferred on my half assed comcast cable connection. Not bad for $25 a credit card sized board sitting in a cardboard box in my broom closet. I think I'm going to give one to everyone of my family members preloaded with Tor. Plug it into their cable router and let it run. That would be another 4 bridges added to the total. If we could get another 100 people to do this it it might be a good way to add capacity with very little cost or power use. BTW, I have nothing to do with the Pi foundation, I just like playing around with them. Richard

2 5

Re: [tor-relays] Issues with vidalia-obfsproxy-bridge-bundle-0.2.4.12-alpha-0.3.3-alpha on Windows
by Asa Rossoff 01 Jun '13

01 Jun '13

From: Asa Rossoff [mailto:asa@lovetour.info] Sent: Saturday, June 01, 2013 4:33 AM To: 'tor-talk(a)lists.torproject.org' Cc: 'tor-relays(a)lists.torproject.org' Subject: Issues with vidalia-obfsproxy-bridge-bundle-0.2.4.12-alpha-0.3.3-alpha on Windows [A. R.] . > 5) Sometimes, problem #4 never occurs: Tor simply stops generating log messages and I dissappear from the consensus (onionoo status=down). This also takes some hours. This is the state at this moment as I write this message, and looking at the log, there is nothing unusual reported (level=notice/warning) (if beneficial, I can learn how to have Tor generate a full debug log when run directly without Vidalia). Tor is still functioning as a client -- without log messages to the terminal, at least for a longstanding existing connection. [A. R.] Interesting development just now: I went to the Tor console window that has shown no activity for many hours (andonionoo shows me down). I was about to close it and restsart Tor, but on a whim hit the ESC keep instead. Tor immediatiately came back to life, ebginning with the following message "[warn] Your system clock just jumped 64376 seconds forward; assuming established circuits no longer work." and restested it's OR port (which succeeded quickly). I guess it's working again.. will leave it for now..strange trange strange. I guess I can run it from a batch file that pipes a huge file with ESC's into it.. might keep it alive.. Thanks again if any insights; Asa

1 0

Issues with vidalia-obfsproxy-bridge-bundle-0.2.4.12-alpha-0.3.3-alpha on Windows
by Asa Rossoff 01 Jun '13

01 Jun '13

Dear tor-talk and tor-relays experts: Hi, The solution to my problems is probably obvious: "well, downgrade" (or perhaps, if skilled or daring, try compiling the latest code), however: I'd like to report that the current obfsproxy bridge bundle for Windows seems to be essentially unusable on my system. Windows 7 Ultimate x64, first gen i3/2 core/4 thread mobile system. I think this is the first Windows obfsproxy bridge bundle released. Previously I used the 0.2.4.11 pyobfsproxy browser bundle and simply reconfigured it as a bridge, which seemed to work fine and be very stable. My initial difficulties were all my own: configuration file changes between the two versions and filename changes (pyobfsproxy -> obfsproxy). Solved them, to my knowledge. 1) Then, Tor always crashed on startup, which may have been a timing issue as this was mostly/only observed with Vidalia configured to startup with the system/login. This "fixed itself" (more evidence it may have been a timing issue with differing startup/login timing). However, I think this is a bug, as startup with the system should just work (I had no problems with 0.2.4.11). 2) Then, although Tor didn't crash on startup anymore, there were numerous error messages (unfortunately, I don't recall them) in the Tor log when starting with the system, and I think it was not fully working anyway. 3) Maybe a showstopper: in between 20 minutes and and an hour, Vidalia either lost communication with Tor, or Tor was failing in some way. Vidalia did not know it had lost communication, but there were no more log messages, and all the other information tabs either reported nothing, or in the case of the network map -- mapped nothing but showed some connections. Nothing happened if I tried to terminate connections from the interface. Clicking the "Stop Tor" button and then "Start Tor" resolved the issue -- for 20-60 minutes. My solution: stop using Vidalia, and just run Tor directly. I made a hardlink to the torrc file in Vidalia's appdata folder, from Tor's so they could both find it (there is probably a command-line switch or two I could have used :) -- I didn't check!) 4) Now, things were better. Next problem: periodically, usually after some hours of running fine, the Tor log began showing errors re. the cached-microdescs file. First, a permission/file access error, and then hundreds of other errors related to building the micro descriptor cache would be generated every some minutes. Actually---I also observed this problem the first time, even running under Vidalia, that Tor ran without crashing on startup. My solution attempt: delete the file. It was locked. When I closed Tor --- the lock was released [Tor was tied to the file lock] and I could delete the file. I restarted Tor and it worked fine for some hours before repeating this behavior. Once this happens, my node goes down. I think it has to do more bootstrapping work on restart when this file is lost, if I understand correctly. 5) Sometimes, problem #4 never occurs: Tor simply stops generating log messages and I dissappear from the consensus (onionoo status=down). This also takes some hours. This is the state at this moment as I write this message, and looking at the log, there is nothing unusual reported (level=notice/warning) (if beneficial, I can learn how to have Tor generate a full debug log when run directly without Vidalia). Tor is still functioning as a client -- without log messages to the terminal, at least for a longstanding existing connection. 6-sort of) I'll note in passing---in the off-chance it might be an issue on the Tor end, and in the other off-chance that an issue on "my end" is adding to Tor's instability. I suppose in both cases it might be called a Tor bug if in deed relevant at all, as I would expect Tor to handle it gracefully: I have my OR address specified using a DNS name (a dynamic DNS name). I run a dynamic DNS updater that either polls for changes every 5 minutes, or else Tor does a lookup every 5 minutes, because Tor is reporting IP address changes sometimes as frequently as every 5 minutes, between my real IP (which has not changed) and an IP on an entirely different network owned by an unaffiliated ISP!. This gererates frequent ORPort reachablity tests, which are always done, for some reason, on the correct IP address. The incorrect address has a long tracert to another state before it dwindles off to no-reporting private network routers, and a reverse nslookup indicates it is on a cellular address block. --- I will have to study this issue on my own, most likely (bug in updater, my dynamic dns service, etc. - it may be the last known address on one of the configured interfaces on my coputer - which is down -- for when I use my phone's connection on occasion.) I can simply try returning to my old batch file that worked great as a dynamic ip updater, and can the fancy but possibly buggy executable in the system tray. 7) Minor issue: ORPort reachability tests do not always succeed in the 20 minutes alotted (but I can perform a telnet test from a foreign server to the port and get a connection). The tests are repeated and eventually succeed. On the other hand, sometimes the test succeeds within seconds. I have trouble understanding why they would fail (or why they would take more than 30 seconds) unless it is an issue where other nodes refuse to cooperate in reachability testing or make it a low priority. This is probably not a version-specific issue, but might be a design issue. 8) This issue comes chronologically early in the sequence of problems I experienced: Some controls in the Vidalia 0.2.4.12-0.3.3 Settings dialog that I tried didn't save the values, So I relied on manually editing the config files. -------------- If you've read this far, thanks! I will soon--time permitting--and lacking other advice--try the non-obfsproxy bridge bundle (0.2.4.12-alpha-0.2.21) supplemented with the obfsproxy executable from alpha 0.3.3. If that fails, I will go back to the 0.2.4.11 browser bundle configured as a bridge. When I achieve a stable combination, I might try a tool for installing anything as a service and try to run the Tor executable as a service. Seems like Vidalia should be able to talk to it, but I might have to overcome automatic Vidalia behavior like trying to start Tor itself and exiting if the Tor process is killed, etc. ---------------- There are many great minds here, so if anyone has any pointers or links o a page with the info I need, that would be great. Otherwise, consider this a bug report and let me kow if I can aid in debugging. I want to support the Tor network in such ways as I can. Thanks, Asa

1 0

Re: [tor-relays] [tor-talk] Skype banned tor-nodes?
by Mike Perry 29 May '13

29 May '13

Cross-posting to tor-relays to give everyone the heads up - I just added 33033 to the ReducedExitPolicy page for Skype: https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy Non-relay related discussion should remove tor-relays from the Cc. James Brown: > Hello, people! > > Because many my contacts continue to use Skype and don't want to use any > nice soft (such as jabber, torchat and etc.) I need to use it too. > For protecting of my location and etc. I use it only through Tor (on VM > working under transparently-torifed user). > Some days ago I would be very, very difficalt to connect to skype > through the Tor-net (earlier it was very easy). > As can I see in my Vidalia, my skype application can make resolving > through tor and can connect to hosts through port 443, but conncetions > with port 33033 cannot establish (I can the the trying to open it and > after it it closed immediatly). > As can I see the skype doesn't work without that connections which now > establishes very rarely. > I have 2 versions: > a) the Skype team ban the Tor-connections to skype (but I can still > connect to skype to ports 443 and I can to browse their web-site and > even log in to it through the Tor without any problems) > or > b) many Tor-exits don't let the above-mentioned port (33033) in their > ExitPolicy. > It is not good from the Skype team if they do the first. > If the second hypothesis is right I ask owners of Exit-nodes, if it > possible, to let that port in their ExitPolicies. Not sure if that's actually the problem, but if the only way you can get to Skype is to use a Bittorrent-supporting exit, it certainly seems like a possibility. Thanks for the heads up James! -- Mike Perry

1 0

obfsproxy on freebsd
by Peter Kasper 28 May '13

28 May '13

hi, i'm trying to run obfsproxy on freebsd 9.1, i have installed packages obfsproxy-0.1.4,1 and tor-devel-0.2.4.12.a log file: May 24 16:36:29.000 [notice] Your OpenSSL version seems to be 0.9.8y. We recommend 1.0.0 or later. May 24 16:36:52.000 [notice] To correct this, use a more recent OpenSSL, built without disabling any secure ciphers or features. May 24 16:36:53.000 [warn] The communication stream of managed proxy '/usr/local/bin/obfsproxy' is 'closed'. Most probably the managed proxy stopped running. This might be a bug of the managed proxy, a bug of Tor, or a misconfiguration. Please enable logging on your managed proxy and check the logs for errors. May 24 16:36:53.000 [notice] Failed to terminate process with PID '12021' ('No such process'). when i start obfsproxy directly, there is only obfs2 protocol 2013-05-25 21:09:51 [notice] Starting (obfsproxy version: 0.1.4 (git-94ebc4c3edf1e3e5)). Usage: obfsproxy [obfsproxy_args] protocol_name [protocol_args] protocol_options protocol_name ... * Available protocols: [dummy] [obfs2] any idea? peter ---------- ZPS 14 za 16,90 EUR - vypredaj internetoveho skladu pokracuje! SUPER AKCIA! Registracia nove .EU domeny len za 1,99 EUR! Najdite si strateny alebo ukradnuty telefon programom Zoner AntiVirus Free pre Android Domeny .SK len za 12.29 EUR Ponuka z vydavatelstva Zoner Press Mam rad Android - klikni tu

2 2

Increasing nofiles when running Tor-Relay in a chroot environment
by Sven Reissmann 28 May '13

28 May '13

Hi, I'm running Tor inside a chroot that I built long ago, using this guide: https://trac.torproject.org/projects/tor/wiki/doc/TorInChroot For some weeks my traffic limitations are gone, so I' d like to increase the allowed traffic on my relay. Problem is, that I also need to increase the maximum number of open file descriptors, tor may use. I did this in the limits.conf configuration file, but it has no effect in the chroot environment. Is anyone running a similar setup or has a hint how it could be solved? Regards, Sven. -- PGP Schluessel : https://0x80.io/files/key.asc Anonyme Antwort: https://privacybox.de/srm.msg

1 0

Several IP address on the same box
by Torry Torah 24 May '13

24 May '13

Hi, I have two network interfaces on my server and thus 2 IP addresses. Since tor uses only a very small fraction of my resources (I'm running a bridge), I was wondering if I could put up two bridges, one on each interface. I didn't find anything in the docs about that. Many thanks, -- Torry

2 1

Is TOR using more than just OrPort and DirPort?
by Daniel Wu 13 May '13

13 May '13

I just started a relay (non-exit node, not running a client myself), on Windows, using the latest Vidalia Relay Bundle. Looks like from the configuration, given that I'm running in relay mode, there should be only two ports used by Tor (OrPort and DirPort), right? However, when I run "netstat -ano", I see that the Tor process is using up a lot more ports. There are these connections, from 127.0.0.1 back to itself. Some sort of internal process used by Tor? Not as concerned about these, since these are internal. But still curious. TCP 127.0.0.1:63417 127.0.0.1:63418 ESTABLISHED TCP 127.0.0.1:63418 127.0.0.1:63417 ESTABLISHED TCP 127.0.0.1:63419 127.0.0.1:63420 ESTABLISHED But then I see connections like these: TCP 192.168.1.202:55049 174.136.105.86:9001 ESTABLISHED TCP 192.168.1.202:56804 37.128.208.46:9002 ESTABLISHED TCP 192.168.1.202:56896 171.25.193.9:80 ESTABLISHED TCP 192.168.1.202:57113 109.232.224.74:9001 ESTABLISHED TCP 192.168.1.202:57206 91.227.249.44:9001 ESTABLISHED TCP 192.168.1.202:57221 67.164.46.197:9001 ESTABLISHED TCP 192.168.1.202:57253 128.31.0.34:9101 ESTABLISHED TCP 192.168.1.202:57259 204.124.83.132:587 ESTABLISHED TCP 192.168.1.202:57260 128.232.18.57:9001 ESTABLISHED TCP 192.168.1.202:57309 204.124.83.131:443 ESTABLISHED TCP 192.168.1.202:57331 81.24.98.236:9001 ESTABLISHED These appear to be the actual Tor relay traffic (192.168.1.202 is my computer). Why are these using ports in the 55000+ range, when I specified my OrPort to be a singular value (in my case, 9031)? I would like to know the port ranges used by Tor for relay traffic, so I can use my dd-wrt to set the QoS by specifying these Tor port ranges. Thanks, DW

4 6

"Localized" TOR exit notices?
by Conrad Hoffmann 07 May '13

07 May '13

Hi all, I recently decided I should run a TOR exit node. I am new to the list and still in the process of setting things up. One thing I noticed is that the TOR exit notice [1] contains a US-specific section (it even says so in the comments). Is there a resource anywhere as to how this paragraph might look in other countries? I am located in Germany for example, and I suppose a short mention of the TMG [2], specifically § 8 and § 15 would be suitable replacement for the above mentioned paragraph. I guess that even if not in the git repo, at least a collection in the wiki might be a neat idea? Or did I just not find it? Cheers and thanks for any hints, Conrad [1] https://gitweb.torproject.org/tor.git/blob/HEAD:/contrib/tor-exit-notice.ht… [2] http://www.gesetze-im-internet.de/tmg/index.html (in german)

2 1

A call to arms for obfuscated bridges
by George Kadianakis 06 May '13

06 May '13

Greetings, A year ago we asked you to run obfuscated bridges to help people in Iran [0]. Many people answered our call and we ended up having a big pool of obfuscated bridges to give to our users. Unfortunately, today, most of those bridges are down, and fresh ones are needed more than ever, since obfuscated bridges are the only way for people to access Tor in some areas of the world (like China, Iran and Syria). On the bright side, Tor's anti-censorship infrastructure has improved, and now you don't have to send the bridge addresses to us; if you run an obfuscated bridge with Tor 0.2.4.x, Tor will send its own address to BridgeDB [1] like normal bridges do. Also, obfsproxy was rewritten in Python and it now supports a new pluggable transport called 'obfs3' which works even in China [2]. We have dropped support for the C-version of Obfsproxy, and the new Pluggable Transport Bundles contain the Python version [3]. Finally, future pluggable transports will be developed for the Python version. Looking into BridgeDB, we have 200 obfs2 bridges, but only 40 obfs3 bridges: this means that we need more people running the new Python obfsproxy! Upgrading obfsproxy should be easy now, since we prepared new instructions and Debian/Ubuntu packages. If you run Debian or Ubuntu check out these instructiosn: https://www.torproject.org/projects/obfsproxy-debian-instructions.html.en otherwise use these: https://www.torproject.org/projects/obfsproxy-instructions.html.en (and make sure your pip is upgraded so that it uses HTTPS [4]) Furthermore, Tor's support assistants need some _unpublished_ bridges to give to censored users who ask for help via email. To configure an unpublished bridge you add "PublishServerDescriptor 0" to its torrc. After you do so, fire up Tor, and check its logs to find the ports that 'obfs2' and 'obfs3' are using. Send your IP and ports to tor-assistants(a)torproject.org. Finally, if in the future we need you to do something extra (for example to upgrade obfsproxy to support a new pluggable transport) we will send another mail to tor-relays. Thanks for the help! [0]: https://lists.torproject.org/pipermail/tor-talk/2012-February/023070.html [1]: https://bridges.torproject.org [2]: In China obfs2 is blocked using active probes: https://trac.torproject.org/projects/tor/ticket/8591 [3]: https://blog.torproject.org/blog/new-name-obfsproxy-tor-browser-bundles [4]: https://groups.google.com/forum/#!msg/python-virtualenv/foXxh-NpdGg/uT0NPc9…

14 26

Support for Relay Operators (signed)
by Moritz Bartl 04 May '13

04 May '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 The last mail was not signed, because the Mail Merge addon does not work together with Enigmail. Sorry. - ---- cut ---- Hi, I just noticed that I never announced that we offer support for relay operators at support [at] torservers [dot] net. You can encrypt your mails using PGP -- https://www.torservers.net/torservers_pub.asc fingerprint B099 CF5D 5B97 DC65 2406 B458 C8F4 2EB2 E033 4E90 Currently, four founding members of Torservers.net read that address. If you are a "Torservers partner", please think about joining the support team. We can use your help! - -- Moritz Bartl https://www.torservers.net/ -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJRg7atAAoJEOGPxWJITcUAHc4H/2mv6Wlpg5bLA5aHTx7lFn19 Dfgr2NTslfwRSA5CO3HeGRytoEoZUJ1xiZMh3SNZzLB6241WxBhdp5mExXFgTe0e E4WFP9rcDVSY2wuzi9QkjergQy3oeaadL17eiRs//GK+eb9wcBfpZ8OHyCTrauln dTUWVCAdtglptTed4Kx2ZUEPjHVoA9pWr9DQ9mxJjXLbREiu4ru0acC7QYswBj/r zt44LfkqPwEOzCrnvqEKOLT/MPP1lPk27tq7dfsTTozdII7VsrVj+nxdoWsfbFOp MyWe7240q4+0QOxHddWXMAAOgnnHOT+QfMeK1BYc1/FBosm9TAVVQmSQvbsb0HU= =BuJ9 -----END PGP SIGNATURE-----

3 3

Support for Relay Operators
by Moritz Bartl 03 May '13

03 May '13

Hi, I just noticed that I never announced that we offer support for relay operators at support [at] torservers [dot] net. You can encrypt your mails using PGP -- https://www.torservers.net/torservers_pub.asc fingerprint B099 CF5D 5B97 DC65 2406 B458 C8F4 2EB2 E033 4E90 Currently, four founding members of Torservers.net read that address. If you are a "Torservers partner", please think about joining the support team. We can use your help! -- Moritz Bartl https://www.torservers.net/

1 0

Preparation for reimbursement: partner mailinglists
by Moritz Bartl 03 May '13

03 May '13

Hi, In preparation of Torservers.net reimbursing exit and bridge operators, we have set up two new mailing lists. Entities that receive reimbursement are called "Torservers partners" and listed at https://www.torservers.net/partners.html (if they want to be listed) If you want to become a partner, we have to get to know you first: Ideally, we have personally met you multiple times, and learned about your motives. I announce these lists publicly, because the list archives of both lists are *public* and you are welcome to use them. You can send messages to the discussion list, but they will be moderated. The list called "partners" is *compulsory* if you want to receive reimbursements, as it will be used for important announcements that *must* be read by all participating entities. The list "partners-discuss" is optional. Subscription is limited to partners, so you are free to use it for whatever you want to discuss with other partners. If you are a member of a participating organization, you can subscribe and we will confirm your membership (moderated subscription). Summary of list options: partners: - important announce list! - *public* archive - subscription for anyone, but *required* for partners - moderated posting, so you can reach all members with important notices, but only after verification - subscription list private - reply-to set to partners-discuss https://www.torservers.net/services/mailman/listinfo/partners partners-discuss: - *public* archive - subscription and posting for partners only - subscription list private https://www.torservers.net/services/mailman/listinfo/partners-discuss Emails by non-members are *rejected*. If you want to reach partner organizations, please use the public mailinglist at http://www.freelists.org/list/torservers . It will be read at least by Torservers "staff". -- Moritz Bartl https://www.torservers.net/

1 0

Any operators in Singapore?
by Sanjeev Gupta 25 Apr '13

25 Apr '13

Hi, I run a number of Tor Relays, including exit nodes, in Singapore. I have recieved a request from the Singapore Police, who are investigating a case of "unauthorised payments via Paypal". They have asked for the customer to whom I have assigned the IP address (the request is because I am the whois contact for the network). Is there any other Singapore operator on the list who has experience? -- Sanjeev Gupta +65 98551208 http://www.linkedin.com/in/ghane

2 2

Using the name of a named node
by Konstantinos Asimakis 25 Apr '13

25 Apr '13

https://atlas.torproject.org/#details/A84D7DF9D58E0FAFF8CCC06A6A49DD96BD1DF… https://atlas.torproject.org/#details/12404BB1BB4F09CA65B76D77F347BC0D79CB7… How is this possible? I though that if you try to take the name of an unnamed node, your node switched to Unnamed or something like that automatically. Does the named flag prohibit other nodes from taking that name, or is it merely enabling clients to refer to you by name unambiguously? ----- My blog: http://www.inshame.com My full signature with lots of links etc: http://bit.ly/trtsig

2 1

Restart relay daily
by peckman＠hushmail.com 23 Apr '13

23 Apr '13

Hi! I am running a middle-man relay on a Raspberry Pi averaging 700 kBps. The board is very limited in processing power and memory. After some days, maybe a week, the Tor daemon runs out of memory and I have to start it manually again. I have tried different Tor versions, built alphas with and without the --enable-openbsd-malloc but it's no measurable difference; eventually a bad malloc will terminate the program. To solve this I have added a cron job to restart the daemon on a daily basis. Is this an OK solution? Traffic-wise it takes around 30 minutes to get back to normal throughput but the alternative is long downtimes until I notice the crash. Will there be any problem with the directory interaction? Relay info: Fast Guard Named Running Stable V2Dir Valid Tor 0.2.4.11-alpha Kind Regards, peckman

2 1

Re: [tor-relays] [tor-talk] NPA to urge Internet providers to block users of hijacking software [Tor]
by grarpamp 22 Apr '13

22 Apr '13

>> http://mainichi.jp/english/english/newsselect/news/20130418p2a00m0na013000c… "to voluntarily block communications if an anonymous software system ... is found abused online." The second ripline leaves some room but is without specifics. > It seems they are blurring the line between recommending that websites > refuse to answer connections from the Tor network, vs recommending that > ISPs prevent their users from reaching the Tor network. "The panel specifically recommends that communications be blocked when there is access from IP addresses publicly listed as those allocated to the third in a chain of computers that are used by Tor." This quote clears that up to be the former. However, it appears they also intend to ask network operators to block exits as well, not just websites: http://mainichi.jp/select/news/20130418k0000e040232000c.html "Based on the recommendations, the National Police Agency to encourage voluntary efforts such as the industry of Internet connection operators." They don't seem to say whether non-exits (thus the EG's among them) would remain accessible or not. "The Tor system was utilized by citizens in pro-democracy movements in the Middle East to escape government suppression, while Wikileaks also recommends Tor to information providers. The planned access restrictions are therefore expected to spark a backlash from the industry. 'Communication privacy is our lifeline. We won't be able to accept such a request,' said an industry insider. An NPA official said, 'We will make detailed explanations and seek their understanding.'" http://mainichi.jp/select/news/20130124k0000e040166000c.html "police were summarized for the strengthening of cyber crime investigation the 'emergency program' ... According to the National Police Agency, the police has been promoting public-private partnerships with such Internet-related companies so far, but pointed out that investigation and not keep up with the rapid advances in information and communication technology ... In the future, expanding the range to exchange personal level regardless of the occupation of the other party, and that improve the information collection... Emergency program, mentioned considerations and be entrusted to the private sector, the analysis of the modus operandi of education and other investigators" It's a little unclear to what degree these groups are for enforcement or education, whether they attend public conferences, etc. Likely the usual mix. There could be some good opportunities there. Cracking, corp/finance, data theft, copyright that sort of deal is one thing. But these idiots making death/bomb threats and such are really getting old not just on its face but due to their tendency to make the news and piss people off, and against Tor, in a different sort of way. I presume exit operators in Japan could ask NPA/Mainichi for the full panel doc and would be very interested in following this issue ... cc'd.

1 0

What is "regular" traffic on an obfuscated bridge
by Torry Torah 20 Apr '13

20 Apr '13

Hi there, After seeing the call to arm [1], I decided to spin up some 2 new obfuscated bridges. I am already running 2 (non-obf) bridges, and was about to boot 3 others. I'm seeing something like 4MB/day of traffic with those obf bridges, whereas the 2 non-obf bridges show something like 10MB/sec. ( All the servers more or less have the same specs, so it's not a hardware/connectivity issue. My question is: is it a "normal" amount of traffic on an obf bridge? For what it's worth, I followed intructions here [2] on an ubuntu precise with a firewall. I allowed communications on the OR port and the 2 ports given by obf2 and obf3. I've set up the 2 obf bridges 8 hours ago, give or take, maybe is it just a matter of insufficient uptime? Cheers, [1] https://lists.torproject.org/pipermail/tor-relays/2013-April/002089.html [2] https://www.torproject.org/projects/obfsproxy-debian-instructions.html.en

4 5

Trying to set up an obfs2/3 bridge on Windows, missing something.
by Asa Rossoff 18 Apr '13

18 Apr '13

I think I'm suppling the ServerTransport parameters incorrectly. the log seems to indicate it is listening on the wrong ports for obfs2 and obfs3. Since it was the only compiled package I saw for Windows with obfs support, I downloaded the tor-pluggable-transports-browser-2.4.11-alpha-2. I am using the following .torrc -- Address *obfuscated* AvoidDiskWrites 1 BridgeRelay 1 LearnCircuitBuildTimeout 0 CircuitBuildTimeout 60 ClientTransportPlugin websocket exec flashproxy-client --register :0 :56833 *[not useful, I realize]* ContactInfo *obfuscated* ControlPort 9051 CookieAuthentication 1 DataDirectory *obfuscated* DirPort 0 DirReqStatistics 0 ExitPolicy reject *:* GeoIPFile *obfuscated*/geoip GeoIPv6File *obfuscated*/geoip6 HardwareAccel 1 ServerTransportPlugin obfs2,obfs3 exec pyobfsproxy managed ServerTransportListenAddr obfs2,obfs3 0.0.0.0:56831 0.0.0.0:56832 Log notice stdout Nickname *obfuscated* NumCPUs 4 ORPort 56830 RelayBandwidthBurst 97280 RelayBandwidthRate 71680 SocksListenAddress 127.0.0.1 SocksPort 9050 I get the following log messages on starting Tor: [Notice] Tor v0.2.4.11-alpha (git-fcd9248387249d68) running on Windows 7 with Libevent 2.0.21-stable and OpenSSL 1.0.0k. [Notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning [Notice] This version is not a stable Tor release. Expect more bugs than usual. [Notice] Read configuration file "*obfuscated*\torrc". [Notice] Opening Socks listener on 127.0.0.1:9050 [Notice] Opening Control listener on 127.0.0.1:9051 [Notice] Opening OR listener on 0.0.0.0:56830 [Notice] Parsing GEOIP IPv4 file *obfuscated*/geoip. [Notice] Parsing GEOIP IPv6 file *obfuscated*/geoip6. [Notice] Your Tor server's identity key fingerprint is '*obfuscated* *obfuscated*' [Notice] We now have enough directory information to build circuits. [Notice] Bootstrapped 80%: Connecting to the Tor network. [Notice] New control connection opened. [Notice] Bootstrapped 85%: Finishing handshake with first hop. [Notice] Registered server transport 'obfs3' at '0.0.0.0:60093' [Notice] Registered server transport 'obfs2' at '0.0.0.0:60094' [Notice] Bootstrapped 90%: Establishing a Tor circuit. [Notice] Tor has successfully opened a circuit. Looks like client functionality is working. [Notice] Bootstrapped 100%: Done. I have ports 56830, 56831, 56832, and 56833 forwarded to this machine from my router/nat. I get connections on my ORPort 56830 -- though in 2-3 days, not a single client. Seems to be directory exchanges (?) or my own Tor Browser use. Isn't 2-3 days long enough to be discovered? Looks like it is listening on 60093 and 60094 for obfs3 and obfs2 instead of the intended 56832 and 56831 (the ports I have forwarded) for the purpose. Any help? Is it just a syntax error on my part (I tried using two lines for the ServerTransportListenAddr but one was automatically deleted after editing in Vidalia), or am I further off-track? Thanks a bundle :) Asa

2 2

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 14 Apr '13

14 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