tor-relays

tor-relays@lists.torproject.org

36 participants
4815 discussions

Oniontip
by justaguy 30 Sep '14

30 Sep '14

So, https://oniontip.com is a great help for tor-relay runners We do need more donations imho Whoever made it, thank you - Justaguy

10 15

[warn] No unused circIDs found on channel without wide circID support
by tor-admin 29 Sep '14

29 Sep '14

Hi, since upgrading torland to 0.2.5.8-rc I see the below warnings. Is this something to worry about? Regards, torland -------------------------------------------------------------------------- Sep 28 16:07:24.000 [warn] No unused circIDs found on channel without wide circID support, with 0 inbound and 4 outbound circuits. Found 0 circuit IDs in use by circuits, and 64 with pending destroy cells. (0 of those were marked bogusly.) The ones with pending destroy cells have been marked unusable for an average of 7594 seconds and a maximum of 16137 seconds. This channel is 18469 seconds old. Failing a circuit. Sep 28 16:07:24.000 [warn] Circuitmux on this channel has 4 circuits, of which 4 are active. It says it has 29535 destroy cells queued. Sep 28 16:07:24.000 [warn] Channel 93320 (at 0x7fbff4579d90) with transport TLS channel (connection 3245390) is in state open (2) Sep 28 16:07:24.000 [warn] * Channel 93320 was created at 1411894775 (18469 seconds ago) and last active at 1411913240 (4 seconds ago) Sep 28 16:07:24.000 [warn] * Channel 93320 says it is connected to an OR with digest 4C733BAC82CC609ACC58AD95BFBFF04D5D06188C and no known nickname Sep 28 16:07:24.000 [warn] * Channel 93320 says its remote address is [scrubbed], and gives a canonical description of "[scrubbed]" and an actual description of "[scrubbed]" Sep 28 16:07:24.000 [warn] * Channel 93320 has these marks: !bad_for_new_circs canonical is_canonical_is_reliable !client !local outgoing Sep 28 16:07:24.000 [warn] * Channel 93320 has 0 queued incoming cells and 0 queued outgoing cells Sep 28 16:07:24.000 [warn] * Channel 93320 has 4 active circuits out of 4 in total Sep 28 16:07:24.000 [warn] * Channel 93320 was last used by a client at 0 (1411913244 seconds ago) Sep 28 16:07:24.000 [warn] * Channel 93320 was last drained at 1411913141 (103 seconds ago) Sep 28 16:07:24.000 [warn] * Channel 93320 last received a cell at 1411913240 (4 seconds ago) Sep 28 16:07:24.000 [warn] * Channel 93320 last transmitted a cell at 1411913141 (103 seconds ago) Sep 28 16:07:24.000 [warn] * Channel 93320 has received 234 cells and transmitted 2497 Sep 28 16:07:24.000 [warn] * Channel 93320 has averaged 78.927350 seconds between received cells Sep 28 16:07:24.000 [warn] * Channel 93320 has averaged 7.396476 seconds between transmitted cells Sep 28 16:07:24.000 [warn] failed to get unique circID

2 1

Oniontip
by Sebastian Urbach 28 Sep '14

28 Sep '14

Hi, Mike, your questions are all valid. Remember where this project is coming from. Donncha put this together at the Dublin Bitcoin Hackathon and it was designed to give back a little bit to the Relay Operators. I never expected anything in return for my relays but im glad that onintip exists and the approach seems to be to give everybody a little bit back based on the consensus. Exit operators can get a lot of legal trouble and i acknowledge that but without Middle Relays, Guards, Bridges etc. TOR would not be possible. It seems to be always about the Exit's. There are different organizations for Exit's and now they should be preferred on oniontip.com ? It is hard not to feel like a second class Relay operator when you don't run an Exit. Im happy that there is a possibility like oniontip and btw. there is nothing similar on the torproject website. You can donate to the torproject via bitcoin but there is no way to choose who should receive this donation like you can do on oniontip.com Im not sure if it is necessary for oniontip to provide the best possible distribution of the donations from the projects point of view (diversity etc.) It seems to be a different approach just to give back to everybody and it has a certain amount of charme. It is easy to use and it seems to be working and becoming more and more popular. I like it. -- Mit freundlichen Grüssen / Sincerely yours Sebastian Urbach ----------------------------------------- Definition of TOR: 10% luck, 20% skill, 15% concentrated power of will, 5% pleasure, 50% pain and 100% reason to remember the name! -----------------------------------------

3 2

(no subject)
by I 27 Sep '14

27 Sep '14

Hej, Reportedly Pirate Bay runs virtual machines in someone else's clouds dodging revealing their IPs because traffic is handled by a load balancer. Why couldn't Tor be run in China, for example, using that method as there are cloud companies there? Robert

1 0

HAProxy + tor
by list-tor-relays＠nosur.com 26 Sep '14

26 Sep '14

Hello, My tor exit has been building up reputation for months but still fails to saturate a 100 Mbps line while barely using any CPU. Therefore, I recently decided to start a second tor process on the same server which is now slowly building up reputation. I gave the second process a different ORport in order not to affect the first process. Should that not be enough to saturate the line, I might even have to add a third process at yet other ports. I wondered whether the following is also possible: 1. Run tor process #1 on ORPort 8000, but advertise port 443 2. Run tor process #2 on ORPort 8001, but advertise port 443 3. Run tor process #3 on ORPort 8002, but advertise port 443 3. Run HAProxy on port 443; load-balancing between the three tor processes Obviously, this would require HAProxy to always route a circuit to the same tor process, since that tor process keeps track of the state of that specific circuit. Source IP stickiness ("balance source; hash-type consistent") would do that. Would such a setup work? Thanks, Bram

2 1

VPS in China
by I 26 Sep '14

26 Sep '14

Hej, Does anyone have an idea what might be done with a VPS in China? Robert

3 3

Estimating the value and cost of the Tor network
by Mike Perry 25 Sep '14

25 Sep '14

Hello everyone, I would like to put together some estimates on bounds of the current value and cost of the capacity of the Tor network as it is, and use that to generate some rough guestimates on what it would cost to grow it (assuming we solved all the complicated problems with respect to maintaining diversity and operator incentives). In order to make these estimates, I need some people to tell me: 1. Your node identity fingerprints. 2. How these fingerprints map to hardware, CPU cores, and uplink. 3. How much you are paying for this uplink per month. If you are paying less than market rate because of a friendly ISP, ideally you would also tell me what the standard market rate is at that ISP. If you have multiple nodes at multiple datacenters, please break these costs and fingerprints out individually rather than telling me aggregate information. I'd most like to hear from people who are doing the recommended best-practice of running one Tor process instance per CPU core, are paying for dedicated uplink at around 100Mbit/sec or higher at a datacenter, and who are not CPU bound on any of their Tor processes. If this does not apply to you, I'd still like to hear from you, but please tell me these details of your setup. Exit node data is most useful, but I am happy to hear about non-exits too. I suspect they may be much cheaper on average, and getting some data on this is also important. Unfortunately, bridges are not that useful at this time. You do not need to send this information publicly to the list. I am happy to receive it privately via GPG. My GPG key id is 0x29846B3C683686CC, and that key signs all of my mail to all torproject lists. You can get it here: https://pgp.mit.edu/pks/lookup?op=get&search=0x29846B3C683686CC -- Mike Perry

8 10

Bandwidth and weight fractions
by jchase 25 Sep '14

25 Sep '14

Dear Digest, If I take a look at my relay at atlas.torproject.org with the OR address of 83.163.171.103:9001 then I see on a 3 month graph that both my advertised bandwidth fraction and my consensus weight fraction are slowly declining. Concerning bandwidth fraction I assume this is a good thing, because if my bandwidth is stable then total bandwidth is going up (and my fraction is going down). Is the same true of my consensus weight fraction? If I'm going down, the total is going up? Thanks, JChase

1 0

Good hosting location for exit relay
by DerTor Steher 25 Sep '14

25 Sep '14

Hey, for a few days now I'm looking for an appropriate ISP for my new exit relay. There are a few problem I am facing now: 1.) Since I'm living in germany it isn't the very best to host an exit relay in germany, so I need to know which country is (law related) the best country I could host my VPS. 2.) The choice of a hoster. It's not easy to find a good and reliable and (if possible) cheap hoster which allows tor exit relays so I need to crawl to whole Good/Bad ISPs list for such providers. If I had the cash I would rent a server at Cyberbunker but it's to expensive to only run a relay there. I would appreciate if you could help me or at least give me some tips with finding the best country and provider. Thanks. :)

7 8

Re: [tor-relays] Call for a big fast bridge (to be the meek backend)
by David Fifield 25 Sep '14

25 Sep '14

On Mon, Sep 15, 2014 at 07:12:23PM -0700, David Fifield wrote: > The meek pluggable transport is currently running on the bridge I run, > which also happens to be the backend bridge for flash proxy. I'd like to > move it to a fast relay run by an experienced operator. I want to do > this both to diffuse trust, so that I don't run all the infrastructure, > and because my bridge is not especially fast and I'm not especially > adept at performance tuning. > > All you will need to do is run the meek-server program, add some lines > to your torrc, and update the software when I ask you to. The more CPU, > memory, and bandwidth you have, the better, though at this point usage > is low enough that you won't even notice it if you are already running a > fast relay. I think it will help if your bridge is located in the U.S., > because that reduces latency from Google App Engine. > > The meek-server plugin is basically just a little web server: > https://gitweb.torproject.org/pluggable-transports/meek.git/tree/HEAD:/meek… A couple of other requirements have shown themselves in helping set up a meek-server relay. The first is that it has to be a 0.2.5.x version of tor. This is so that the ExtORPort option will be supported. The ExtORPort option is needed in order to collect statistics on pluggable transports (see #4773). One of the lines you will have to add to torrc is: ExtORPort auto If your tor does not support the option, you will see in the log: [warn] Failed to parse/validate config: Unknown option 'ExtORPort'. Failing. The second requirement is that the relay needs to have either BridgeRelay or DirPort set. If neither of these options is set, the relay will not be a directory cache, and clients will not be able to bootstrap past "20%: Asking for networkstatus consensus." As I understand it, #12538 will make it so that every relay is a directory cache, but it is not committed yet. I'll check back privately with the people who offered to run a relay and check if setting these options is okay. David Fifield

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-relays