- tor-relays - lists.torproject.org

hardware
by Andreas Fink 15 Jul '13

15 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