- tor-relays - lists.torproject.org

Relay bandwidth usage drop
by Jobiwan Kenobi 27 Sep '13

27 Sep '13

About 2 days ago, around midnight of September 20, bandwidth usage on my relay dropped from averaging a bit over 100KB/s to around 20KB/s. It's been low ever since. Consensus weight dropped accordingly. You can see on the graphs on atlas and globe. My relay is named jobiwan. There seems to be nothing wrong with my relay. Log is pretty clean and handshake and heartbeat reports indicate normal operation (just not much of it). From time to time I have bits of normal throughput. I have no indication that I'm being throttled or traffic shaped. Is there anything I should look into? Thanks, -Job

2 2

(no subject)
by ابوصالح 27 Sep '13

27 Sep '13

Android مرسل من الهاتف المحمول Samsung

2 1

. Re: Relay security, re: local network
by Harold Naparst 26 Sep '13

26 Sep '13

I have been running an exit relay from my home for many years with no issues. If you are willing to support the ideals of the Tor project, you should be willing to run an exit relay. Obviously, without exit relays, the Tor project would be useless. I am unable to surf to exactly one site that I know of, a hosting provider. I solved that problem by choosing another hosting provider, Amazon Web Services (AWS). If you are ever blocked, it is easy enough to rent another IP address at AWS for $7 per month by signing a one-year contract for a reserved micro-instance. Then run a squid server on that micro instance and use it as a proxy server. But as I said, this hasn't been a problem for me. Also, keep in mind that running an exit relay from your home will provide you with better anonymity. If you combine that with surfing using the Tor Browser bundle, you will have pretty good anonymity. (I read that once on the Tor project's site.) Regards, Harold

3 2

Which is more helpful, availability or speed?
by phoneyball＠vfemail.net 26 Sep '13

26 Sep '13

Hello all, If my relay is in a datacenter with a fast link but constrained by a in+out<100GByte monthly limit, is it more helpful to provide: * a slow relay that is usually available, e.g. 30KByte/sec available about two-thirds of the time, or: * a fast relay that hibernates a lot, e.g. 1MByte/sec but only available 1/50th of the time? Secondly, is it more helpful to be: * available every day for a fraction of that day, or: * available continuously for some consecutive days then hibernated for the rest of the month? Thanks for any advice. (I've read differing opinions on these questions written at different times, but haven't found a clear consensus.) P. Honeyball ------------------------------------------------- VFEmail.net - http://www.vfemail.net $24.95 ONETIME Lifetime accounts with Privacy Features! 15GB disk! No bandwidth quotas! Commercial and Bulk Mail Options!

3 2

Future versions and Vidalia?
by J.C. 25 Sep '13

25 Sep '13

Are all future versions of Tor Browser Bundle going to have Vidalia permanently stripped? I'm running a stable relay on Linux with the TBB (and thus, Vidalia) instead of installing the Tor packages, and i quite like it this way. I don't remember what exactly went wrong, but some months ago i tried to get a relay running by installing and configuring it with the terminal and failed miserably, even though i was following instructions to the letter. I could try again but i'm a huge fan of the "if it's not broken, don't touch it" approach, and my relay works fantastic right now. If Vidalia is going to be permanently dropped at some point, is there any other way to continue running a relay than the terminal? I had a look at TBBv3 and didn't find a way to enable relaying.

3 5

Tor Slides
by Simon 24 Sep '13

24 Sep '13

Hello Is there a public share with presentationslides for tor ? I'll soon hava a presentation, and i want to use the most recent informations. Simon

2 1

Re: [tor-relays] Future versions and Vidalia?
by Jesse Victors 24 Sep '13

24 Sep '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 > Date: Mon, 23 Sep 2013 12:54:34 +0300 > From: "J.C." <jc80(a)riseup.net> > To: tor-relays(a)lists.torproject.org > Subject: [tor-relays] Future versions and Vidalia? > Message-ID: <52400FDA.2060309(a)riseup.net> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Are all future versions of Tor Browser Bundle going to have Vidalia > permanently stripped? I'm running a stable relay on Linux with the TBB > (and thus, Vidalia) instead of installing the Tor packages, and i quite > like it this way. I don't remember what exactly went wrong, but some > months ago i tried to get a relay running by installing and configuring > it with the terminal and failed miserably, even though i was following > instructions to the letter. I could try again but i'm a huge fan of the > "if it's not broken, don't touch it" approach, and my relay works > fantastic right now. > > If Vidalia is going to be permanently dropped at some point, is there > any other way to continue running a relay than the terminal? I had a > look at TBBv3 and didn't find a way to enable relaying. I'm in exactly the same boat. I would _highly_ recommend that the current TBB stay exactly the way it is. I'm against having a ton of services start up by themselves. As a Linux user, I enjoy having the power to control what I start things up, and when. Sometimes I start my computer and I don't want certain things to start. The disadvantage of having a service install is that I lose much of that control. I too have tried to set up a Tor relay via packages and such, and I also failed. The TBB was orders of magnitude easier: I just click "configure relay" and things work fine. Vidalia is also extremely easy to use, and I like the interface. I would advise that the dev team reconsider. Jesse V. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQF8BAEBCgBmBQJSQPJhXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxMjgyMjhENjEyODQ1OTU1NzBCMjgwRkFB RDk3MzY0RkMyMEJFQzgwAAoJEK2XNk/CC+yAWX4H/jp1DlCgdJqRQd9I0pVpozDu VlA75uAtFxIM0VYr+eIVuC2OqQHUUFZLYNwFfePUZvIxy9bedL5WlkdZQCsaenaY wu3sLMpoBz8cH2qM/Ne5JIiFCTUEOL7XwA5d8ehdGSmnZUaBXANwiJ23uh2eVpeE HKvU/bnS5wp0YG7x/xHyQ5SGCpyWXb5H7LnGtNol9GTvbTgepo9rHtVmUCgdA5Wg BJe1yXAy/lAv5GjloejBtTu4whPuZOuY5FU+1LRHt3wnShLgEMy7UXeVQpAK2pDa mEvKD75aIb2AevGAsSdqBs2FsOOimQ7FrWudH3aZHYB6g5+nfOouLxBVcDoVjts= =Bjy+ -----END PGP SIGNATURE-----

2 1

Tor flood symptom?
by David Carlson 24 Sep '13

24 Sep '13

My relay that has been running release 0.2.4.17-rc for several day now has become saturated with what I would consider 'noise' - namely a huge amount of handshake activity. It does respond downward to lowereing the bandwidth setting, but the bandwidth graph is nearly flat. Now I have just noticed two crypto errors in the message log. Sep 23 14:17:32.902 [Notice] Circuit handshake stats since last time: 224326/224887 TAP, 40/40 NTor. Sep 23 15:17:32.999 [Notice] Circuit handshake stats since last time: 224169/225104 TAP, 77/77 NTor. Sep 23 16:17:32.016 [Notice] Circuit handshake stats since last time: 224655/225333 TAP, 63/63 NTor. Sep 23 16:50:14.883 [Warning] crypto error while checking RSA signature: block type is not 01 (in rsa routines:RSA_padding_check_PKCS1_type_1) Sep 23 16:50:14.883 [Warning] crypto error while checking RSA signature: padding check failed (in rsa routines:RSA_EAY_PUBLIC_DECRYPT) Sep 23 17:17:32.782 [Notice] Circuit handshake stats since last time: 222538/222987 TAP, 14/14 NTor. Sep 23 17:36:03.704 [Warning] eventdns: All nameservers have failed Sep 23 17:36:03.829 [Notice] eventdns: Nameserver 192.168.1.254:53 is back up Is this acceptable or should I report this to bugzilla? David?

1 0

Re: [tor-relays] Reimbursement of Exit Operators
by tor＠t-3.net 21 Sep '13

21 Sep '13

On Friday 20/09/2013 at 6:37 am, Moritz Bartl wrote: > > I don't think exit relay operators are in a position to have anonymity > in the first place. It is fine if you manage to pay for and run your > relay anonymously, but I doubt it will survive more than a few LEA > inquiries where they end up with a fake name instead of a real > contact. > I get the sense that there are some exit node operators who can't attempt it or deliberately aren't for reasons related to the direct ownership of abuse complaints. But there are some where there could be ambiguity. It is not always clear-cut who the end-user of each service is. Things like leased servers with multiple sub-users, roommate/shared internet, shared VPNs, shells given away to friends, etc, are a part of it. > > How is the method of transferring funds relevant to liability or risk > in > that respect? What method of transfer would change anything about > that? > It's not all about the method. Thoughts are: - One way to damage Tor would be to mess things up for exit node operators either personally or professionally. IMO the less 'they' know about exit operators, the less damage they can do with that kind of approach. That would include information obtained from getting to know someone on IRC in this context, as you don't really know who you are talking to or if you're being monitored. - If authorities can ever build a case where Tor can be accused of being a dirty little network which hosts criminal content and profits from it, it seems that it could be fucked. I already saw Tor identified by one media source as simply being an internet network that criminals use. We know that this isn't a fair description but I'm not sure that would make a difference if certain cards get played? - When you can be demonstrated to have received money, depending upon what that money was sent for, it can be used against you. If money was to be sent, it seems better if it were done as a consulting sort of agreement? It would be invoiced like any other internet consulting service you are willing to provide (and it wouldn't be the only service offered). It wouldn't involve personal-feeling chats on IRC, it would be a professional relationship. What do you think? I don't want to scare anyone away with this stuff. Just feel like we should be more careful than what I was reading. Doesn't feel right to encourage exit node operators to show up on IRC with their bank account #s ready to go.

2 1

What happens with the time on turtles 76.73.17.194?
by tor-admin 21 Sep '13

21 Sep '13

Hi Mike, I am seeing many of these messages in the logs of torland1/torland2: Sep 21 12:09:34.000 [warn] Received NETINFO cell with skewed time from server at 76.73.17.194:9090. It seems that our clock is ahead by 15969 days, 10 hours, 9 minutes, or that theirs is behind. Tor requires an accurate clock to work: please check your time and date settings. Can you please check turtles. Thanks & regards, torland

2 2

Is this HAL?
by I 21 Sep '13

21 Sep '13

3 2

non-exit risks?
by That Guy 21 Sep '13

21 Sep '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > You're probably fine, especially if not running an exit. You didn't list your home country, though; I'm assuming United States. > Best, > -Gordon M. While I know you have vastly more knowledge and experience than me and often my observations or worries are doe to me mis-understanding something but about the comment above, I have experienced issues running a non-exit relay pretty soon after it going up and though I have no idea if there is a connection, I started to get more trouble after the doubling of connections at the end of July. I was blocked from a number of websites, Had many of my emails returned because of a flagged IP(the one listed was not my ip) Ended up on a several blacklists within a week of starting my relay, SORBS being the most eager to BL you it seems. a few other small but new issues/quirks that I don't know enough about to attribute to anything Tor other than the timing. anyway, just my .02 btc That Guy grep(a)gmx.us _________________________________________________________________________ GnuPG Fingerprint: 7770 D186 A06E A329 2217 3161 63EB F269 37B8 8644 _________________________________________________________________________ “If you’re doing nothing wrong, you have nothing to hide from the giant surveillance apparatus that the government’s been hiding.” – Stephen Colbert -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBAgAGBQJSPFjnAAoJEGPr8mk3uIZErgYQAJFXCfo0C0ekeY82Z6T2+hTO cWNL+S3swDU9Mr3IyT2bVYep3IDrBmJ4HtyixtMo2DzVQjYKsl1cNT6U07GILmdp bSUfOc5PEyn9phZ4bz1dR6dcXn2vMMAXMaiFfCcgbZnQyIZC/Xmkzq8jiwk/SEaU n/k3536nNj/2QToMhd5D702vDl5vJ1VOa174/w5/8LEgHgE7MBKAyFKYnZSVTBbl /BqF5UqucNPZBbOEL4dljawehENlWkBe2LRGmrXtHABgZtN49UQV3lIzPGg6mUOP BPlp5AkKNwRkS1PcH9oGBDFgTXo9ekumT2uxJs5g2fsskYcINXHc8LM18U9M5CLp Zab5AsSwOWnuNX8WNPSTN9Fv2jHgpalboE7ku2CfXQ52YvxytNJ6FS3QWVVJ058J jsXhvK9C/TizFImZssRlBzCoP2xLAtKFy9Z2dtIYXJ+nh9oOwvg9Ps+pX5c9yM6O hS+eG/rStIKNNEunMgM7h9ikBEjjP4ywUY+5Hbqrx5NMqZtHLhU06v0BivR97Gfi Yfg5tKRrgrBLb9kP/7M0RGPcTtVxwMcRTDt4lGR5IoW2VkfUsLhCMoMyMvOaD6bf fFbvkVjB//4l2SMBghppDpUIelw0OhrOKi8ZXOwejzQITtEXgWXOIAuZPqF+OU0f jMtxNs5m1uvZVNyxreTK =8PY+ -----END PGP SIGNATURE-----

6 7

State of the art in NAT busting?
by Gordon Morehouse 20 Sep '13

20 Sep '13

I have a question which relates to my ongoing groundwork to build a Raspberry Pi (and hopefully Beagle and Cubie) friendly set of Debian packaged programs which can turn one of these small, low-power machines into a plug n' forget Tor relay. What is the start of the art in NAT hole punching if one does not have a UPnP or (other-standard-mumble) compliant router? If I'm behind such a router, what's the best I can do to help the Tor network if, for any reason, the user is unable to port forward? Sub-questions: 1. What's the best I can do without any outside help? 2. What's the best I can do with minimal outside help, e.g. STUN+ICE, TURN, etc? Does Tor itself support any of those? Could a Tor relay or bridge + not-yet-written scripts make use of those? 3. Are there any options I'm forgetting to consider, other than wholesale relaying of traffic (eg IP_A:portN -> hole-punched NATed Tor instance where IP_A is another machine handling some or all of the NATed relay's traffic)? Best, -Gordon M.

1 0

Re: [tor-relays] Reimbursement of Exit Operators
by tor＠t-3.net 20 Sep '13

20 Sep '13

Think bigger, say what? Certain of the world's biggest and most well-funded intelligence agencies hate personal privacy on the internet so much that they've been going to extreme efforts to destroy it. They are packet sniffing the NAPs and fiber backbones to pull out everything they can, they hacked/broke HTTPS, they are backdoored into the big content providers, they hacked the banking system, they are apparently 'in' some hardware crypto chips - the list goes on - They infiltrated the tech groups which were designing software and hardware and sabotaged their work, making their crypto be weaker/breakable and their systems easier to hack into. They use the vulnerabilities they created to their own ends. As of today, Tor appears to provide privacy, at least as far as the .onion sites goes. Maybe it even works for it's entire function of providing anonymous internet browsing. 'They' would definitely want to be IN this thing, because they either want to compromise it, or if that doesn't work well enough, destroy it. 'They' are known to infiltrate and be influential in getting what they want. Literally, they are professionals at this. 'Getting to know' the exit relay operators and identifying their bank accounts would help facilitate things when it came time for them to make their move. In the context of September 2013, this whole thing is scary. It was perhaps not scary in September of 2012, when we didn't know anything. Also. It makes me wonder things when, for example, you say "Think bigger" while pointing to a couple of potential dollars in someone's pocket. Safeguarding the operators of the exit relays is a bigger deal than chump change. I'm not making an honest accusation but, to the people who are the most vocal in approving of this - you don't work for the NSA, right? :) On Wednesday 18/09/2013 at 6:08 pm, Roger Dingledine wrote: > On Wed, Sep 18, 2013 at 08:10:25AM -0400, tor(a)t-3.net wrote: >> >> The Wau Holland Foundation can currently only >> reimburse via wire transfer. >> >> This seems to be end-of-story in terms of who, in the end, is >> ultimately getting liability/risk, and points to practically no >> chance at anonymity > > Think bigger --

8 9

Re: [tor-relays] Reimbursement of Exit Operators
by tor＠t-3.net 20 Sep '13

20 Sep '13

The OP I saw said: The Wau Holland Foundation can currently only reimburse via wire transfer. This seems to be end-of-story in terms of who, in the end, is ultimately getting liability/risk, and points to practically no chance at anonymity within our currently hacked banking system. It's not related to taxation or what organization may or may not be trusted. It's about what information is being gathered from the system by 3rd parties for possible use tomorrow. There's another perspective to this as well. Speaking objectively and without knowledge of the organization involved, and nothing personal intended. It may be worth noting that certain presumably-Tor-hostile and well-funded agencies are known to infiltrate the tech organizations/efforts which they wish to weaken, and influence them from the inside. In this context, seeing Tor's exit node operators being offered cash via bank transfer is waist-deep into creepy. On Wednesday 18/09/2013 at 7:38 am, Tom Ritter wrote: > create or work with a trusted organization who is willing to shoulder > liability, risk, and expense of investigating the legality and tax > consequences, and then actually executing, reimbursing people through > anonymous means.It's not easy. May not even be possible. But there is > a rigid but not inflexible framework of tax law that must be worked > within. > IMO, this is net gain. Excited to see it happen, and congrats to all > whose hard work has brought it here. > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >

5 4

Re: [tor-relays] 0.2.4.17-rc on Pi, a couple weeks on
by Joshua Datko 20 Sep '13

20 Sep '13

Just for comparison sake, I'm running a relay on the BeagleBone Black, running Ubuntu (raring), and Tor 0.2.4.17-rc with the following log entries: Sep 19 16:16:40.000 [notice] Circuit handshake stats since last time: 16771/16781 TAP, 13/13 NTor. Sep 19 17:16:40.000 [notice] Circuit handshake stats since last time: 17229/17240 TAP, 14/14 NTor. Sep 19 18:16:40.000 [notice] Circuit handshake stats since last time: 17371/17385 TAP, 13/13 NTor. Sep 19 19:16:40.000 [notice] Circuit handshake stats since last time: 17084/17099 TAP, 17/17 NTor. Sep 19 20:16:40.000 [notice] Circuit handshake stats since last time: 16694/16702 TAP, 13/13 NTor. Sep 19 21:16:40.000 [notice] Circuit handshake stats since last time: 17380/17382 TAP, 20/20 NTor. Sep 19 21:16:45.000 [notice] Heartbeat: Tor's uptime is 11 days 18:00 hours, with 715 circuits open. I've sent 221.93 GB and received 225.81 GB. Sep 19 21:16:45.000 [notice] Average packaged cell fullness: 87.388% Sep 19 21:16:45.000 [notice] TLS write overhead: 8% I currently have the Fast, Guard, Named, Running, Stable and Valid flags. I initially had a "your computer is too slow" message and then I set MaxAdvertisedBandwidth to 200KB and it's be better since. CPU usage is about 70%. The BBB actually has an AES crypto accelerator, but I don't think it's being used and I'm trying to work through that at the moment. Lastly (an somewhat related), I submitted a workshop proposal to 30C3 called "Using the BeagleBone for Fun and Privacy" to talk about BeagleBone hacking and running Tor. I won't find out if it's accepted until November... Josh

1 0

0.2.4.17-rc on Pi, a couple weeks on
by Gordon Morehouse 20 Sep '13

20 Sep '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hey folks, Here are my reports. First the good news: it's WAY more stable. Then the bad news: it still gets OOM-killed once in a while, possibly preventably. THE GOOD (notes from September 14): Here's my Pi relay since compilation of 0.2.4.17-rc: Sep 14 11:50:59.000 [notice] Circuit handshake stats since last time: 13308/13324 TAP, 22/22 NTor. Sep 14 11:51:51.000 [notice] Heartbeat: Tor's uptime is 7 days 18:00 hours, with 434 circuits open. I've sent 42.85 GB and received 34.05 GB. Sep 14 11:51:51.000 [notice] Average packaged cell fullness: 98.369% Sep 14 11:51:51.000 [notice] TLS write overhead: 9% That low NTor number is depressing. That high TAP number is scary. TAP is the old way and the way the botnet is using. NTor is post-0.2.4.8, I think. The replay has settled into a fairly steady state (after losing its flags except Named) of sending 5-10KB more per sec than it gets. I have a feeling this is literally due to the TAP replies being bigger than the TAP requests. It's handling tens of thousands every 6 hours. Load average is steadyish at 0.7. Unlike its predecessor, though, it's not yet crashed under the new network conditions. ...By last night (18 Sept) it had settled in to no Stable flag, but forwarding an essentially random amount of traffic that looked similar minute-to-minute. Load was between 0.9 and 1.1 with tor, top, and nload being really the only active processes. There is still room for tuning with the Pi given that this load was attained relaying about 2Mbps when I looked. THE BAD: This morning: Sep 18 04:50:59.000 [notice] Circuit handshake stats since last time: 34818/41100 TAP, 50/52 NTor. Sep 18 05:30:43.000 [warn] Your system clock just jumped 101 seconds forward; assuming established circuits no longer work. The system clock thing is a Pi thing. I'm pretty sure I need to get much more aggressive with ntpd. (Pis have no battery backup and tend to have pretty bad clock drift.) But then, 2 minutes later: Sep 18 05:32:20 tulameen kernel: [2188444.188460] Out of memory: Kill process 7544 (tor) score 148 or sacrifice child Sep 18 05:32:20 tulameen kernel: [2188444.188475] Killed process 7544 (tor) total-vm:153352kB, anon-rss:115156kB, file-rss:36712kB Coincidence? Bug? Smells like the latter. Shouldn't Tor be shedding memory if it closes all its circuits, not acquiring more? Best, - -Gordon M. -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJSOa+yAAoJED/jpRoe7/ujs4UH/iXK4+hAAk06nYUptKChGRyx boZxDxpNum4uEzkJNZlUdvUILuVLX2DXytN7kNJUKDYKGzwCwBhhcQ7tOyBFucz+ muVcbwgyjM8zDhMFexWX8wVh7lauJRpjcNxzE+5hVRkzMFrbGy7FLXZbTiNGT5Ez cSfZAziu0Au3OKhxLQMUdYiZtfi/b/ReMIx72Xz4pBX4hPiagORG5NPgKpNzeBij C+khy5up1WuE7qxGX8+zG1T6K0whAW6MFYKdIT63GlwVWzYAP7tZDbbQd3kB46Yd e5I+ySBGL7VnOzH6CQl+2l1enu87JDyZ1Hw6zkZp3GQ6u8ThiHQQvmNQx9N3rxQ= =sx6s -----END PGP SIGNATURE-----

4 8

Tor Relay getting "Failed to terminate process with PID" messages
by Michael Gorbach 19 Sep '13

19 Sep '13

Hi, I started up a Tor relay several days ago, and the usage seems to be ramping up nicely. However, I am seeing some unexpected messages like this, in ARM and in the tor log files: 17:21:56 [NOTICE] Failed to terminate process with PID ‘29778' They seem to be showing up, reliably, every 5 minutes or so. Each has a different PID. What’s strange is that these PIDs don’t exist by the time I see the message, i.e. I guess whatever process had that PID is now dead. Anyone know what could be causing this? Should I be concerned, or is this some kind of artifact of my setup or software? The machine is a modern Gentoo linux install running a 3.10 kernel and Tor 0.2.3.25 (running inside VMWare). Thanks in advance for your help. Yours, ~ M.

2 4

Too little traffic on my #2 non-exit relay
by Christian Dietrich 19 Sep '13

19 Sep '13

Hey there, I'm currently running two tor (non-exit) relays on one host machine. "000000000000myTOR1" and "000000000000myTOR2". Now my problem is that tor relay #2 generates almost no traffic. https://atlas.torproject.org/#search/000000000000myTOR Log Relay #1: Circuit handshake stats since last time: 1566234/14743525 TAP, 10428/10433 NTor. Heartbeat: Tor's uptime is 7 days 6:00 hours, with 56008 circuits open. I've sent 2167.46 GB and received 1567.97 GB. Log Relay #2: Circuit handshake stats since last time: 63/63 TAP, 1/1 NTor. Heartbeat: Tor's uptime is 7 days 6:00 hours, with 4 circuits open. I've sent 1.58 GB and received 844.66 MB. Both have the same binary and configuration (except incoming/outgoing IPv4). I've also tried to switch from "fully self compiled debian, with custom kernel, and own tor binary" to "Out of the Box Ubuntu LTS, with torproject tor package" .. without any improvement. Both relays works as expected. OT: for my opinion avg 150 mbit/s (99% done by node #1) is too less for an Ivy-Bridge Based Xeon Quad Core (/w HT) on an unshared gigabit line. Apart from the fact that multithread support is really missing. Can anyone give me a hint, or am i just too stupid? Thanks ;)

4 8

Re: [tor-relays] Reimbursement of Exit Operators
by tor＠t-3.net 18 Sep '13

18 Sep '13

It's a little old. Posted July 24, 2012 We knew a lot less on that date. On Wednesday 18/09/2013 at 3:08 pm, Andrew Lewman wrote: > On Wed, 18 Sep 2013 13:36:39 -0400 > Rick <rerushg(a)gmail.com> wrote: > >> >> Nope, I don't think so. Perhaps it's the timing. In this post-Snowden >> period most everything is a little bit creepy. There's plenty of FUD >> to go around. A position paper from Torproject on this and other >> recent issues would be handy about now. > > Does this qualify as a position paper? > https://blog.torproject.org/blog/turning-funding-more-exit-relays > > -- > Andrew > http://tpo.is/contact > pgp 0x6B4D6475 > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

1 0

Reimbursement of Exit Operators
by Moritz Bartl 18 Sep '13

18 Sep '13

Hi, tl;dr: We want to start reimbursing exit operators end of this month. Partner orgs, please sign the contract! Everyone else, consider becoming a partner. --- In July last year, Roger announced that BBG was interested in funding fast exits. [1] The initial discussion on the mailing list continued into August. If you're interested, you should consult the archive for the various points raised. Since then, we've been discussing that topic on and off. It matched with my plans to turn torservers.net into a platform for many organizations, instead of just one single entity that runs too many exit relays, so I agreed to take the lead. I posted a status report of some sort on this list in April this year. [2] The Wau Holland Foundation agreed to be one of the organizations willing to handle the money and pass it on to other entities, be it single operators or organizations. Both Torproject and Wau Holland Foundation checked with their lawyers to see if this turns into a problem about liability, and it looks like it does not. We're open for more organizations to join in to manage the reimbursement process, but this is what we've got for now. In parallel, we've seen a growing number of organizations that were created to turn donations into exit bandwidth. [3] Two issues with reimbursements, that were also mentioned in Roger's initial posting, are that (1) you don't want to drive away all the volunteers, and (2) you don't want to become dependent on (a single or a handful of) sponsors. These are difficult issues, and I want to strongly encourage everyone to keep contributing to the network. We really need you, and we need more of you! The second issue, dependence on funders, is on the one hand a harder one, but on the other hand (in my opinion) a less relevant one. If structures die and nodes have to be shut down because a funder backs off, so be it. We hopefully don't change the picture too much in comparison to the "unfunded times of today". The reimbursement process does not guarantee a money stream, and the amounts are set on a month-to-month basis, to encourage recipients to plan only short-term, and only make contracts based on the money they have, disregarding what they may or may not receive in the future. The current "bucket" is the one-time BBG money, and it currently does not look like they will restock it. It might sound scary, but to satisfy the tax authorities (and to show that it is a [hopefully] fair and transparent process), the Wau Holland Foundation needs to have partners sign a contract. The contract does not limit the partners abilities or restrict what they do, it only defines the reimbursement process. The way we want to start doing it now is not set in stone, and hopefully now that we finally start handing out money it will encourage further discussion around it. We want to refine the process over time, but it looks like we just have to try with what we have now and learn from our mistakes. Please don't be too hard with your criticism or you will emotionally hurt me. I'm all ears. :-) We want to reimburse based on the throughput per exit relay and organization. To strengthen network diversity, we came up with the plan to also factor in the location of the relays. There is a maximum amount any entity can receive so we hopefully don't grow big monsters. The contract [4] specifies that there is a monthly amount, currently set to $3500, split amongst all recipients (whom I started calling "torservers partners"). The recipient share is calculated from the throughput per relay * country factor, and the maximum amount per month per partner is 500 Euro. The Wau Holland Foundation can currently only reimburse via wire transfer. The country factors can change over time, and are currently derived from the total exit probability of that country. We can and should refine this. Changes of these factors do not require new contracts. Note that since the total amount of $3500 will be handed out every month, as long as we have less than 6 entities signing the contract, each entity will receive their maximum share of 500 Euro. I don't really like the idea of a fixed monthly total handed out like that, but that's what the lawyers and tax authorities signed off for Wau Holland Foundation. It seems to be costly to re-evaluate such contracts, so this is what we will stick to for now via WHF. Technically, the monthly shares and the country factors are calculated using a tool written by Lunar^^ (big thanks!). [5] You can find an example report at [6] (not the correct numbers, but you'll get the idea). This monthly report will be sent to all partners, and once they signed the contract they will simply get their monthly share. As stated at the top, we want to start reimbursing this month. Please let me know if you have any questions. We have a mailing list that is public and read-only where we send important announcements, and require every participant to be on and actually read. We have another mailing list that is also read-only for the public, but people of the participating organizations can post and discuss everything around Torservers.net and reimbursements. [7] The process to become a "partner" for now requires that I "know you". So, if you're interested in becoming a partner, start social interaction with me. I see that as a bad bottleneck, and I hope we can somehow get rid of it in the future. I generally prefer "organizations" over single persons, because (1) in most countries it seems to be really inexpensive and easy to set up organizations and (2) the process of setting up such entities includes that you gather enough people around you, so chances are you will continue even if one of you drops out. If you want to discuss, I prefer the tor-relays mailing list and our IRC channel, #torservers on irc.oftc.net. I also explicitly want to invite every partner to join that channel. --Moritz [1] https://lists.torproject.org/pipermail/tor-relays/2012-July/001433.html [2] https://lists.torproject.org/pipermail/tor-relays/2013-April/001996.html [3] http://www.torservers.net/partners.html [4] [fill out + send back via pgp-encrypted and signed mail to me] plain: https://www.torservers.net/misc/2013-07-19_TorExit_en.txt fancy: https://www.torservers.net/misc/2013-07-19_TorExit_en.ott german: https://www.torservers.net/misc/2013-07-19_TorExit_de.ott [5] git clone https://people.torproject.org/~lunar/exit-funding.git [6] https://www.torservers.net/misc/reimburse-output-2013-07.txt (set encoding to Unicode) [7] https://lists.torproject.org/pipermail/tor-relays/2013-May/002138.html

6 6

Traffic shaping on exit nodes (appeasing automated network monitoring systems)
by Philip Paeps 17 Sep '13

17 Sep '13

I had a less-than-amusing conversation with my ISP this week about how my Tor exit node was performing "network scans". As far as I can tell, their definition of "network scan" comprises anything from "knocking on the same port on every machine in a /8" to "creating lots of legitimate connections to the same port in a /8". Obviously, their network monitoring system is too trigger-happy, but there is nothing I can do about that. Do other relay operators have traffic-shaping solutions that make legitimate (and not-so-legitimate) Tor traffic look less like network abuse? I've reconfigured my exit to be a non-exit for the time being. I'm more than happy to be an exit (and field genuine abuse complaints), but I'd prefer not to trigger automated network abuse monitoring systems (too often). Any tips? My node is running FreeBSD with ipfw and dummynet, if someone happens to have ready to copy/paste settings. ;-) Philip -- Philip Paeps Senior Reality Engineer Ministry of Information

1 0

Creating circuits to myself?
by Niles Rogoff 16 Sep '13

16 Sep '13

I was using arm when I noticed this line: 173.79.154.243 --> 173.79.154.243 (us) Purpose: Ags=is_internal,need_capacity, Circuit ID: 5 4.0m (CIRCUIT) That's my IP, and it showed the exit node as the same as my node. There are currently three circuits both originating *and* exiting at my node. I am using Tor 0.2.3.25 (recommended) on Windows 7. My fingerprint is 1E598CDB9BBC751D753146D880B326952886D73B

2 2

tor bridge
by 封添 15 Sep '13

15 Sep '13

i'm tian.please give me list of tor bridge .

2 1

Appropriate bandwidth limits for my home relay
by Nick 15 Sep '13

15 Sep '13

Hi all, After running my relay for a bit on my home connection I found that Tor would happily consume all the bandwidth available, which (coupled with the number of connections overwhelming my home router, I suspect) caused my internet connection to be unusable for other things. So I set the RelayBandwidthRate and RelayBandwidthBurst values to 20 KBytes, as 20KBytes/s is a reasonable amount of bandwidth I can spare (total upload bandwidth on the connection is around 50KBytes/s). However now atlas.torproject.org shows an average of only around 0.5 - 1.5 Kbytes/s usage, and says the advertised bandwidth is 10 Kbytes/s. Should I increase the RelayBandwidthRate value to more than I can comfortably provide, on the basis that it isn't likely to all be used? Or should I just relax and let the network use my relay as little as it likes? Sometime quite soon my home internet connection will get much faster; I'm aware the relay is of questionable value at present bandwidth levels, but they should increase in not too long. Thanks, Nick

2 2