- tor-relays - lists.torproject.org

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

Help collect hidden service usage stats?
by Roger Dingledine 24 Sep '14

24 Sep '14

Hi folks, If you are comfortable compiling Tor from git, and you want to help investigate what fraction of Tor network load comes from hidden service use, I have a shiny new git branch called hs-stats that will collect per-thirty-minute statistics about number of circuits and number of cells your relay sees that have to do with exiting, with hidden services, with circuits where you're not the final hop, and a fourth none-of-the-above category. https://trac.torproject.org/projects/tor/ticket/13192 It skips all circuits and cells that come from non-relays, which should help make sure the stats aren't useful for hurting anonymity. It doesn't automatically send the output anywhere -- it just writes it to its notice-level log for now. So you'll need to either send me the log lines, or add them to the trac ticket like I did here: https://trac.torproject.org/projects/tor/ticket/13192#comment:2 Preliminary results are that load from hidden services is actually a tiny fraction of overall load. A bonus use from these statistics would be to learn what fraction of load comes from exit connections vs middle connections, for relays with various consensus flags. And of course, it's possible there are bugs in how I'm doing the counting. I'll keep investigating to make sure I'm doing it right. Thanks! --Roger

1 0

How about a TWN entry about hosting locations?
by Jens Kubieziel 24 Sep '14

24 Sep '14

Hi, it seems quite much work for a person to collect information about hosting locations. So what do you think about putting a section into next TWN which links to a wiki page where everyone can share information about costs in different regions? -- Jens Kubieziel http://www.kubieziel.de Es genügt nicht, keine Gedanken zu haben. Man muß auch unfähig sein, sie auszudrücken. Karl Kraus

3 3

Alternative Nobel Prize
by Sebastian Urbach 24 Sep '14

24 Sep '14

Hi, The german magazine "der Spiegel" reports that Edward Snowden will receive the Alternative Nobel Prize. Congratulations Edward ! -- 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! -----------------------------------------

2 1

A friendly reminder for all ScrambleSuit bridge operators.
by Yawning Angel 24 Sep '14

24 Sep '14

Hello all, This is a friendly reminder to all ScrambleSuit bridge operators that unless you are running tor-0.2.5.x, you should not be running a ScrambleSuit bridge. This is because the method for propagating the ScrambleSuit password (or any other future pluggable transport server side argument) for inclusion in the Bridge line served from BridgeDB was implemented in 0.2.5.x, and is not present in 0.2.4.x, and to make matters worse, 0.2.4.x has a bug that will allow this configuration to run instead of failing with an error[0]. If you are running a ScrambleSuit bridge with tor-0.2.4.x, it is useless. Users that happen to be served your ScrambleSuit bridge will not be able to connect, because the password is missing. Approximately 1/7th of the ScrambleSuit bridges in BridgeDB exhibit this behavior and we will most likely start filtering them on the BridgeDB side. Please see https://trac.torproject.org/projects/tor/ticket/13202 if you wish to know more about this. Best Regards, -- Yawning Angel [0]: Apparently this is not worth patching 0.2.4.x for, which I personally view as unfortunate.

1 0

Re: [tor-relays] Estimating the value and cost of the Tor network
by Tim 24 Sep '14

24 Sep '14

On 24 Sep 2014, at 13:38 , tor-relays-request(a)lists.torproject.org wrote: > Date: Wed, 24 Sep 2014 05:40:00 +0200 > From: Moritz Bartl <moritz(a)torservers.net> > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] Estimating the value and cost of the Tor > network > > Hi, > > Prices vary widely across different countries. We pay between $400 and > $1500 per Gbit/s per month in "popular and cheap locations". In a > scenario where we want to grow the network and at least keep the current > geographical diversity (or even grow it), we'd have to at least equally > strengthen less fortunate locations. > > The list of the top 20 countries [0] contains countries such as Russia, > Poland, Norway and Hungary, where international bandwidth is quite > expensive. Hopefully someone from this list can help us compile or find > estimates for pricing per country. It would be interesting to learn the > prices even for mid-size (~50-100Mbit/s+) relays in any country outside > of the top five countries, even more so for crazy places that don't make > the top 20. > > Another factor that we should not ignore is that, while it may be > possible to find a set of ISPs that allow mid-size exit relays, it gets > harder the more traffic you push, because of the additional workload > (and scariness) for the ISP from complaints. > > [0] https://compass.torproject.org/ > > -- > Moritz Bartl > https://www.torservers.net/ Mike, Moritz, Re: crazy places that don't make the top 20 I've noticed that most of the Tor network is concentrated in the northern hemisphere, particularly Europe and North America. I assume the distribution of authorities is similar. Apart from China, no Asia-Pacific country makes the top 20 in Tor compass.[1] And no southern hemisphere country makes the top 20 at all. The first Asia-Pacific countries after China are Japan at #29, then Singapore at #37. And unless I've missed something, the first southern hemisphere country is Australia at #42. Details aside, I'd love to see more routers and exits in countries other than the top 4 (Germany, France, Netherlands, United States). This helps spread failure risk, sovereign risk, and the risk from 3 letter agencies and the like. And it would make Tor faster for those in the southern hemisphere, Africa, and the Asia-pacific. But I don't know how much hope there is for this - I've tried to find pricing in Australia, and the figures I've found are: $8000 per month for 100Mbps.[2] $1500 per month for 25Mbps.[3] $800 per month for 10Mbps.[4] That seems ridiculously pricey… I'd rather wait for the National Broadband Network and run one on 100Mbps fibre at 1% of the price.[5] (Except bandwidth would not be guaranteed on a "home"-style plan.) Time to find a sympathetic university? Tim [1]: https://compass.torproject.org/?family=&ases=&exits=all_relays&by_country=T… [2]: http://www.intervolve.com.au/datacentre/ [3]: http://www.exetel.com.au/corporate/ip-transit-colocation [4]: https://www.xhostsolutions.com.au/services/dedicated-server-unmetered.cfm [5]: http://delimiter.com.au/2014/04/03/unlimited-100mbps-89-99-tpg-equals-top-n…

2 1

Good/Bad ISPs
by obx 23 Sep '14

23 Sep '14

I've updated the list of good/bad ISPs. It shows relay [ ] exit [ ] in front of every good ISP. Please verify that information is accurate. Special information, like anonymous hosting, would be appreciated. Thanks

1 0

printfection - tor shop
by Sebastian Urbach 23 Sep '14

23 Sep '14

Hi, Is it just temporary or is the tor-shop at printfection permanently deactivated ? -- 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! -----------------------------------------

1 0

Correctly setting up arm
by Chris Whittleston 23 Sep '14

23 Sep '14

Dear all, Previously, I've run arm using 'sudo -u debian-tor arm'. As was mentioned here previously, this is not how you should run it - in fact there is a bit of documentation to suggest how it should be done. Unfortunately I'm having some issues getting arm working correctly as described here in step 14: https://www.torproject.org/docs/tor-relay-debian.html.en#after Having added my user (pi) to the debian-tor group, I try to run 'arm' and get the following: Failed to read authentication cookie (permission denied): /var/run/tor/control.authcookie I've tried reinstalling arm, relogged and checked that I'm in the right group still using 'groups' (which I am) - no joy. I've checked my torrc and found the following lines: ## If you enable the controlport, be sure to enable one of these ## authentication methods, to prevent attackers from accessing it. #HashedControlPassword 16:872860B76453A77D60CA2BB8C1A7042072093276A3D701AD684053EC4C #CookieAuthentication 1 CookieAuthentication wasn't initially enabled, turning it on makes no difference, I get the same error. I am able to get it working when setting up HashedControlPassword by generating a has using tor --hash-password <password> and editing torrc accordingly. Am I missing something when it comes to setting up CookieAuthentication? I guess I must be...although it seems strange that I was getting that error even with CookieAuthentication disabled. Any insight appreciated :) Chris -- *Dr Chris Whittleston 栗主* Department of Chemistry University of Cambridge Lensfield Road, Cambridge, CB2 1EW Email: csw34(a)cam.ac.uk Tel: +44 (0)1223 336423

4 5

help with getting CentOS 5
by I 23 Sep '14

23 Sep '14

Hej, Following the installation on CentOS instructions on https://www.torproject.org/docs/rpms.html.en it appears there is no package for CentOS 5 only 6 and 7. "http://deb-master.torproject.org/torproject.org/rpm/el/5/i386/repodatarepom…: [Errno 4] IOError: <urlopen error (110, '\xe8\xbf\x9e\xe6\x8e\xa5\xe8\xb6\x85\xe6\x97\xb6')> " Could someone tell me whether CentOS 6 version can be used on CentOS 5? Robert

1 0

Mac OS X configuration problem(s)
by Surf Norway 23 Sep '14

23 Sep '14

I've installed the tor package via homebrew, and cofigured /usr/local/etc/tor/torrc according to the documentation. My problem is that every time I try to use launchctl I get an error, both as an admin user and via sudo. As an admin user: Could not open job overrides database at: /private/var/db/launchd.db/com.apple.launchd.peruser.502/overrides.plist: 13: Permission denied launch_msg(): Socket is not connected When run via sudo it complains about "dubious owbership on file" and says "nothing found to load". I followed whatever documentation I could find. The torrc config is on torproject.org under "configuring a relay graphically" (I know this isn't graphically), the homebrew info is linked to in the same article and looks to be from a mailing list discussion. I wanted to set up a simple relay to run automatically when the (OS X) machine boots. It's a home server on a 30MB/sec symmetrical fiber line. Since I run the machine as a file server anyway, I figured I could allocate some bandwidth and help support the community. Thanks, Surf Norway

3 2

Multithreading progress
by Sebastian Urbach 22 Sep '14

22 Sep '14

Dear list members, I asked Mikhail Belous for a quick status update regarding the multithread feature for the tor-daemon. Here's what he said: Good news: My version of multi-thread tor passes the test and doesn't shows mem racing problems. Bad news: 1)Processing channel is only big enough operation to be paralysed. Tor daemon uses a lot of global variables that should be locked. I have already done this for some resources. 2) Multithread branch is behind master for over 1000 commits. What should be done before release: 1) Merge master in better_workqueue branch. 2) Find all global resources, that are available from command_proccess_cells. I already sent you a list, but it should be checked. 3) Lock all global resources. 4) Code review 5) Compare performance of one thread and multi-thread daemons. -- 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! -----------------------------------------

1 0

exit relay not receiving flag
by jason＠icetor.is 22 Sep '14

22 Sep '14

Hey All, I'm a bit embarassed here but I don't see what I'm doing wrong. I've recently inherited a VPS donation from an anonymous donor. I've configured it up like the rest of Icetor's exit relays but it never receives the exit flag. The exit in question is loki4: https://atlas.torproject.org/#details/44DB05F3AEDA5DA34BC713201DD0394418C7D… An external Nmap scan of the IP shows the DirPort and ORPort open and accessible, so what gives? -Jason

3 3

Re: [tor-relays] Mac OS X configuration problem(s)
by Tim 21 Sep '14

21 Sep '14

On 21 Sep 2014, at 22:00 , Surf Norway <surfnorway(a)gmail.com> wrote: > > I've installed the tor package via homebrew, and cofigured > /usr/local/etc/tor/torrc according to the documentation. > > My problem is that every time I try to use launchctl I get an error, > both as an admin user and via sudo. > > As an admin user: > > Could not open job overrides database at: > /private/var/db/launchd.db/com.apple.launchd.peruser.502/overrides.plist: > 13: Permission denied > launch_msg(): Socket is not connected > > When run via sudo it complains about "dubious owbership on file" and > says "nothing found to load". > > I followed whatever documentation I could find. The torrc config is on > torproject.org under "configuring a relay graphically" (I know this > isn't graphically), the homebrew info is linked to in the same article > and looks to be from a mailing list discussion. > > I wanted to set up a simple relay to run automatically when the (OS X) > machine boots. It's a home server on a 30MB/sec symmetrical fiber > line. Since I run the machine as a file server anyway, I figured I > could allocate some bandwidth and help support the community. > > Thanks, > Surf Norway Hi Surf, A few pointers: 1. On OS X, launchctl has to be run as root/superuser in order to start system-wide services. You can do this using sudo. 2. launchd plist files can't be writable by anyone other than the superuser. If you've installed the tor launchd plist file as your admin user, it will have permissions based on your user, not root. You have a few options here: A. Disk Utility's "Fix Permissions" might automatically fix ownership for you, but it might also leave the file alone because it wasn't installed by the OS X Installer. B. You could try (re-)installing the launchd plist file as root using "sudo". This will make sure the owner is "root". C. Or you could use the "ls -l", "chown" and/or "chmod" commands in the Terminal to investigate and fix the ownership and permissions yourself. 3. It's hard to tell what torrc instructions you're following, but instructions for other platforms will require modifications. OS X launchd works differently to both Linux/BSD and Windows services. For example, you can't use "RunAsDaemon 1" on OS X, or launchd will think tor has crashed. A. You might want to try the OS X-specific instructions at: https://trac.torproject.org/projects/tor/wiki/doc/MacRunOnBoot By the way, if this is your first tor relay, and since it's at home, you probably want to run a relay with no exit ports open. And if you have multiple IPs, on its own IP. This is a much safer option than running an exit on a shared IP. If you're still having problems, can you please include URL(s) of the instructions you're following, copies of your torrc and launchd plist files, and the exact output from the launchctl and tor programs? This really helps us help you, because then we can see exactly what you're seeing. A final question: can you manually launch tor without using launchd? It sounds like you're not even getting to the point where launchd tries to run tor. But it can be helpful to make sure that tor will run without the added intermediary of launchd. T

1 0

obfs3 not recognised by tor 0.2.5.7-rc ?
by Nick Sheppard 20 Sep '14

20 Sep '14

I'm running tor 0.2.5.7-rc and obfsproxy 0.2.6, and everything seems to work perfectly with these PT lines in torrc: ServerTransportPlugin obfs2 exec /usr/bin/obfsproxy managed ExtORPort auto However, if I try to use obfs3 as well: ServerTransportPlugin obfs2, obfs3 exec /usr/bin/obfsproxy managed then on tor start I get: [warn] Strange ServerTransportPlugin type 'obfs3' [warn] Failed to parse/validate config: Invalid server transport line. I thought my versions would be recent enough to handle obfs3? Is this a bug, or am I missing something obvious? Nick Sheppard

2 3

Re: [tor-relays] Port-Based Best-Fit Circuit Selection
by Tim 20 Sep '14

20 Sep '14

[Edit: Convert to end-posting & fix quote levels] On 18 Sep 2014, at 10:40 , Paritesh Boyeyoko <parity.boy(a)gmail.com> wrote: > On Wednesday 17 Sep 2014 22:40:36 Tim wrote: > >> On 17 Sep 2014, at 22:00, Paritesh Boyeyoko <parity.boy(a)gmail.com> wrote: >> >>> On Tuesday 16 Sep 2014 17:36:41 Toralf F?rster wrote: >>> >>> On 09/16/2014 03:35 AM, Paritesh Boyeyoko wrote: >>> >>>> Hello -- >>>> So, I was thinking that in the same way that Tor relays have port-based exit policies, could they not >>>> also have port-based entrance policies? I >>>> >>>> >>>> Beside the general answer (probably "NO") - you mean something, which cannot be handled by a firewall ? >>>> >>> >>> >>> @Toralf Correct, this has nothing to do with firewalls. This is more about better utilisation of slow circuits/relays by deliberately choosing to push relatively lightweight traffic across them. IRC and XMPP do not need 10Mbit/s circuits, not even close. I'm not sure how Tor clients choose the relays they use to build a circuit, and I do realise that a) there are probably more slow relays than fast ones b) attempting to pre-build both a "fast circuit" and a "slow circuit" will reduce the number of candidates for each. I'm just looking for ways to drive more traffic across slow relays. :) >> >> >> >> Paritesh, >> >> >> I think it might help to make a distinction between latency (delay) and throughput (capacity), both of which are affected by router speed: >> >> >> IRC, XMMP and SSH need low latency circuits, which are mostly correlated with high bandwidth relays. >> >> >> Web Browsing (HTTP/S) and similar generally need both low-ish latency and high throughput, also correlated with high bandwidth relays. >> >> >> File Downloads (HTTP/S, BitTorrent) can cope with high latency as long as the throughput is high (and the reliability is sufficient, but that's another matter). >> >> >> But I can't actually see much need for high latency, low throughput relays - are there many protocols that would find that useful? (SMTP is the only one that comes to mind.) >> >> >> T > > > Hi Tim -- > > Very good points, and yes most likely the mail protocols would be candidates for "slow", high > latency circuits. > > However, there may be another class of relays that's overlooked - many VPS providers sell VPSes > with low data caps, even on fast connections (100Mbit/s). There are two ways to address this: > > a) traffic accounting: the relay hibernates until the next reset > b) throttling so that the data cap for the month isn't prematurely reached. > > I'd imagine that most relay operators with such VPS packages will choose to throttle and keep the > relay up and running continuously rather than having it hibernate (I know I've had to do this in the past). > The actual connection is fast enough to not suffer real latency issues, it's just the relay doing the throttling > - do you think throttling to 0.5Mbit/s or 1Mbit/s will create issues of high latency? > > I'm about to go and read the Conflux paper: > > "In this paper, we present Conflux, a dynamic traffic-splitting approach that assigns traffic to an overlay path > based on its measured latency. Because it enhances the load-balancing properties of the network, Conflux > considerably increases performance for clients using low-bandwidth bridges." > > This would obviously create better utilisation of circuits as a whole, so it may well make my idea totally redundant. :) > > Cheers, > > -- > Paritesh Boyeyoko Paritesh, For fast Tor relays with low data caps, the general advice is I've heard is two-fold: * enable AccountingMax, which will hibernate the router when the bandwidth is used up, and * disable directory caching to save (upload) bandwidth (AccountingMax does this automatically when it's configured) This means that the network has many fast routers each covering some of the day/week/month, rather than many slow routers for the entire month. (It also uses the entire bandwidth quota more efficiently - what if the calculated bandwidth limit is too low?) Tor seems to need more fast routers to reduce latency, because there is a long tail of slower routers which can provide significant capacity when needed. T

3 2