- tor-relays - lists.torproject.org

tor-relays
by top mail 01 Oct '14

01 Oct '14

tor-relays

1 0

Loki1 and Loki2 closed
by jason＠icetor.is 30 Sep '14

30 Sep '14

Hey fellow ops, Just an FYI today that Icetor lost two of it's fastest two exits that were hosted with Greenqloud here in Iceland, obviously would not recommend them as an ISP in the future regarding exit hosting. About two weeks ago we got notification that abuse notices were breaking their EULA and would be the reason for the termination. Today they shut down the nodes about 5 hours earlier than indicated, no ability to do data migration or save keys. Needless to say I'm not very happy with the entire situation and how it was handled. We'll soldier on with our remaining two exits and ifanyone is thinking of spinning up an exit in the future Icetor is still able to handle abuse contact for the relay. -Jason

1 0

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