- tor-relays - lists.torproject.org

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 22 Sep '14

22 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

Torservers.net relays not updated yet?
by Nusenu 19 Sep '14

19 Sep '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi torservers, since you haven't updated most of your relays to address [1] released on 2014-07-28 yet, I was wondering if everything is ok? collective vacation? Since you are operating a significant chunk of the tor network's bw - timely patching is appreciated. The tor network is currently at 64% of the bandwidth being served by relays running a recommended version according to torstatus.blutmagie.de. I updated a previous metrics feature request so we might see nice graphs about patching progress in the future [2]. [1] https://lists.torproject.org/pipermail/tor-announce/2014-July/000094.html [2] https://trac.torproject.org/projects/tor/ticket/6856#comment:2 -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJT7+R/AAoJEDcK3SCCSvoeevcP/06Jg2ubrbbD+SKe32necCd2 OCp4auBI3M8LjxVwJMaMi1aBW81Y513shnghYvAVLRe8NCFuem0mnWfeZq6fjrqd kKvksRhCUo2ERK7covRaoVJ8Aqs37MDJh7B48v/FYcbQYbeRIw6+OUmysC6qMPvP gi+ReWFL77kW4hAK+05z6VeaBq6FfKA8L2FRF12ahtGokCO9BnPM1DijHnA4kLJG Fh2YxbWegd5wVna3PJrubjyJ5ANHM0L5pS0dPZZNobat7Sdrux7dhLo2VdHqZFT5 etykHjc18iJhm7z0r4qjYo58gEAx9CebTqdq2w22TBQFnXPaEt9oPktpdG1Q+Ba+ wPiOOBODyngqSUICD6LRGFq3L9Xa+1RrxORD+d+XmsrGhire+83BLkxDZ/JqUB0Z ZY4NEc13tTQqxPfqB6yQyU/XjTPl45zYWsaAxBjzX/AqoXgkwAQkBwdpFrUeu0O3 UiHe4DLhYtcoeOJjisqfl8t7xbyi5TduKfFH10Erglr3WX/OJ/Pau1N/tDtNqey8 GbrZSXVtv0ch7T31Cp6hYrZwxYnucUBcotcOX01+k158zpI5wv87WCwpc9ncDO3t Oj8ORAL/MbgtYh0JaE1wIP0zSuhhWY2Y+qzdXnTwoYMbfDNnLUjcgZzbZNOhEu+E Y3LfuCsT+DI5TpwIp6tK =FZKz -----END PGP SIGNATURE-----

3 9

RELAY_EARLY tor network update status (CVE-2014-5117)
by Nusenu 18 Sep '14

18 Sep '14

(if you are on the CC list of this email you are probably one of the tor relay operators running one of the 10 fastest vulnerable [CVE-2014-5117] relays on the tor network. Please upgrade your tor relay) > The tor network is currently at 64% of the bandwidth being served by > relays running a recommended version according to torstatus.blutmagie.de. > I updated a previous metrics feature request so we might see nice > graphs about patching progress in the future [2]. Since we are seeing active RELAY_EARLY attacks again (or new buggy tor implemantations) I was wondering what the current update stats look like. ~85%* of the tor network's bandwidth is provided by patched relays. (~66% 0.2.4.23, ~11% 0.2.5.6-alpha, ~7% 0.2.5.7-rc) *) according to data from torstatus.blutmagie.de 10 fastest relays still running a vulnerable version: https://atlas.torproject.org/#details/EC98311F9EC02BEAA183651CE8402249CD036… https://atlas.torproject.org/#details/D1271A1E15C568DA709D3A1E68188EEAE8DDB… https://atlas.torproject.org/#details/12AD30E5D25AA67F519780E2111E611A455FD… https://atlas.torproject.org/#details/1B9FACF25E17D26E307EA7CFA7D455B144B03… https://atlas.torproject.org/#details/2F57987F3942BA0BBD706D623F1FF86A89684… https://atlas.torproject.org/#details/379FB450010D17078B3766C2273303C358C3A… https://atlas.torproject.org/#details/935BABE2564F82016C19AEF63C0C40B5753BA… https://atlas.torproject.org/#details/B83DC1558F0D34353BB992EF93AFEAFDB226A… https://atlas.torproject.org/#details/104A9453FD93BDBEAE9E2024898266AD2051A… https://atlas.torproject.org/#details/C11650E31F83E149C855D574B3171CC9CF9BE…

3 2

Re: [tor-relays] BBC and UK Lottery blocking ip addresses running relay
by Dan Hanley 18 Sep '14

18 Sep '14

> > > I have just received a slightly more positive reply: "At present, our GeoIP data provider classes Tor nodes as proxies, regardless of whether or not they're an exit node. We understand that there is room for improvement in this model, since non-exit relays do not present traffic on behalf of other users. We have asked our provider to give us a way of differentiating Tor exit nodes from non-exit relays, to allow us to block exit nodes only." So perhaps they will make a change... certainly reporting the issue seems to raise its importance :-) atb Dan > 5. Re: BBC and UK Lottery blocking ip addresses running relay > nodes (Chris Whittleston) > ---------- Forwarded message ---------- > From: Chris Whittleston <csw34(a)cam.ac.uk> > To: tor-relays(a)lists.torproject.org > Cc: > Date: Thu, 18 Sep 2014 01:40:31 +0100 > Subject: Re: [tor-relays] BBC and UK Lottery blocking ip addresses running > relay nodes > Yeah ouch - maybe I just got someone a bit more helpful. I'm with Matt > though, it seems like they still don't get the difference between using Tor > as a client and running a relay, so this isn't the end of the road there. > You are going to have to rely on them wanting to actually think about it > though. > > If all else fails, you could always try to simply report the issue again > using the form I linked before, but this time just don't mention Tor at all > and see if you get a different customer service person... > > http://iplayerhelp.external.bbc.co.uk/tv/incorrect_location_may2014 > > I suspect you'll end up having to explain that you're running a relay in > the end anyway, but you never know. > > Chris > > On 17 September 2014 21:48, Matt Puckey <matt(a)puckey.org> wrote: > >> Stephen Mollett: >> > [...] >> > "Thank you for contacting the BBC iPlayer support team. >> > >> > "I understand you’re experiencing problems accessing BBC iPlayer as >> > you’re told that you are outside of the UK. >> > >> > "Please note that if you run TOR, then I’m afraid as per our development >> > team’s confirmation you’ll not be able to access BBC iPlayer. If you >> > continue to use TOR then your IP address may be blacklisted against UK >> > only services across bbc.co.uk." >> > >> > I made a point of stating explicitly in my original case filing that I >> > run a middle relay and that no traffic exits from my node to the BBC's >> > website or to anywhere else, along with a link to my node's stats on >> > blutmagie confirming the (non-)exit policy. >> > [...] >> >> Hi Stephen, >> >> I'm not sure whether I'm surprised at the BBC or not! >> >> It is a shame if they seem to be doing blanket blocking of Tor relay IP >> addresses. I suppose this >> ( >> https://blog.torproject.org/blog/call-arms-helping-internet-services-accept… >> ) >> has /some/ relevance. >> >> The problem is obviously convincing a organisation like the BBC to treat >> individual IP addresses different from other Tor relay IP addresses (and >> whether they should be doing that at all). Although it seems Chris >> Whittleston obviously managed it! Maybe you simply got 'the wrong person >> at the other end'. Personally, I would continue to pursue this with them! >> >> --Matt >> >> >> >> _______________________________________________ >> tor-relays mailing list >> tor-relays(a)lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> > > > > -- > *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 > > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > >

3 2

Where to report relay warnings
by Sebastian Urbach 18 Sep '14

18 Sep '14

Hi, I also found a lot of the mentioned log entries. The comment from Arma within the ticket is just right "Bonus points for using the name in the NSA document" Rofl :-) -- 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

Where to report relay warnings
by Jens Müller 18 Sep '14

18 Sep '14

Hi there My relay logged the following warning this morning: Sep 18 04:52:58.387 [Warning] Received an inbound RELAY_EARLY cell on circuit 2147511747. Closing circuit. Please report this event, along with the following message. Sep 18 04:52:58.388 [Warning] upstream=85.159.214.57:9003 Now, I have checked the FAQs but didn't found any information where to report this, so I hope you can help me out. Thank you already and kind regards Jens

2 1

Bridge Offer
by Sebastian Urbach 18 Sep '14

18 Sep '14

Hi, If there is still not enough bridge capacity available after a few people already offered their help, i would be able to help with 400 Mbit (no traffic limit). -- 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

Fwd: Call for a big fast bridge (to be the meek backend)
by Mike Perry 18 Sep '14

18 Sep '14

Forwarded from tor-dev to here, in case any relay operators missed this: ----- Forwarded message from David Fifield <david(a)bamsoftware.com> ----- Date: Mon, 15 Sep 2014 19:12:23 -0700 From: David Fifield <david(a)bamsoftware.com> To: tor-dev(a)lists.torproject.org Subject: [tor-dev] Call for a big fast bridge (to be the meek backend) User-Agent: Mutt/1.5.23 (2014-03-12) 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… Since meek works differently than obfs3, for example, it doesn't help us to have hundreds of medium-fast bridges. We need one (or maybe two or three) big fat fast relays, because all the traffic that is bounced through App Engine or Amazon will be pointed at it. My PGP key is at https://www.bamsoftware.com/david/david.asc if you want to talk about it. David Fifield _______________________________________________ tor-dev mailing list tor-dev(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev ----- End forwarded message ----- -- Mike Perry

3 2

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

18 Sep '14

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

3 2

BBC and UK Lottery blocking ip addresses running relay nodes
by Dan Hanley 17 Sep '14

17 Sep '14

All I can see there was a previous thread related to this in June, but thought I'd add what I'm seeing to the discussion. After the *Data Retention and Investigatory Powers Bill (DRIP) *was rushed through parliament I decided to do my bit for the privacy cause and run a couple of Tor relays. I run one from my laptop at home and one from my desktop at work. Since doing this I have suffered deliberate disruption in service from the BBC and the National Lottery. A Tor relay is a node on The Onion Router network that traffic gets router through to anonymise where it originated from. ( https://www.eff.org/torchallenge/what-is-tor.html) Note that I am running middle relays, not exit relays, so the connection to the destination site will never come directly from one of my relay nodes. Neither have I used the Tor browser to access either site. *The BBC* Within 48 hours the http://bbc.co.uk website started redirecting me to the http://bbc.com international version. They seem to think I am no longer a licence payer, or perhaps conspiring to allow non licence payers to access their UK service. The redirect is based on my homes IP address, so all devices, laptop, phone, ipad etc get redirected. The redirect seems to trigger via Javascript, I can access http://www.bbc.co.uk with Javascript disabled. The international site recognises that my ip address is in the UK and refuses to let me access international content. The net result is that I and my family can no longer access either UK or international BBC content. *The National Lottery* The Lottery allows me to connect and browse their site but as soon as I try to make a purchase I get blocked: *Why is this odd:* Any of the popular IP checking sites/tools show that my address is located in the UK: e.g www.whatsmyip.com or https://who.is I am using two different ISPs (Zen and VirginMedia) neither can explain the behaviour. Contacting the lottery they blame the ISP, I have been unable to get a response from the BBC. Assuming I can believe the look up services and the ISPs that my IP addresses are still located in the UK, the only explanation I can come up with is that the BBC and the lottery are deliberately blocking ip addresses that are registered on the Tor network. Whether they do this independently or avail of a common third party is unknown. So the cost of trying to maintain privacy seems to be the loss of BBC and Lottery – which seems unfair. Regards Dan

4 4

help force Centos to update Tor
by I 17 Sep '14

17 Sep '14

Hej, (With very little knowledge) I can not get Centos 6 VPS to update to the newer version of Tor. Would someone please help me to do that? off list of on Robert

1 0

Multithreading
by Sebastian Urbach 17 Sep '14

17 Sep '14

Hi, Is someone able to provide a timetable for the multithreading implementation into the alpha branch ? I'll take anything ;-) Thanks -- 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! -----------------------------------------

4 4

Port-Based Best-Fit Circuit Selection
by Paritesh Boyeyoko 16 Sep '14

16 Sep '14

Hello -- First of all, let me apologise if this has been covered before on this list. A couple years ago I took more than a passing interest in Tor and decided to run a non-exit relay on a VPS, which lasted until an upstream provider complained. I've recently set up another one, and while it settles into the network, it got me thinking about utilization. Much has been made of the fact that Tor is circuit-based rather than packet-based, and also of the fact that faster relays attract more traffic. 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? In other words, cause deliberate selection of a "slow" path based on the protocol intended to be used. So for example, HTTP would favour faster circuits, while the likes of email (POP, IMAP, SMTP), XMPP and IRC would favour slower circuits (being mostly text-based). Perhaps the entrance policies could be maintained on-network (perhaps with "authority servers", with clients downloading the policies when they start up, rather than having them hard coded or configured client-side? Just some ideas. :) Best, -- Paritesh Boyeyoko parity.boy(a)gmail.com

2 2

Understanding Reduced Exit Policies..?
by Jeremy Olexa 13 Sep '14

13 Sep '14

Hello, I've setup a non-exit node so that I can contribute and understand the TOR network somewhat better. I've only had my node (jolexarelay1) up for a few weeks so it is still becoming a part of the network at guard status. So, as I understand my ISP, I can run an exit node if I "handle" abuse complaints to their standards. Now, since I have more idle bandwidth than idle time to "handle" complaints, I've often wondered about the reduced exit node strategy as seen at https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy - I'd like to allow ports in a methodical fashion such that I can test to see if a port generates complaints easily/quickly. My question: If I want to "try" being an exit node and add allowed exit ports slowly, does that help the network or not? For example, month 1: allow port 22, month 2: allow IRC ports, and so-on. How does the client path selection work in this case - is it smart enough to pick my exit when needed? Thanks for any insight, Jeremy

3 3

request at Hetzner
by Toralf Förster 13 Sep '14

13 Sep '14

3 things: 1. ========= This is what I get few days ago from Hetzer Support: >Guten Tag Herr Förster, > >laut Deutschem Recht sind Tor Server im Moment nicht verboten. >Aus diesem Grund sind Tor Server bei uns auch nicht verboten. >Aus Erfahrung raten wir jedoch vom Betrieb eines Tor Exit Node ab. >Leider wird oft ueber Tor Server Content verbreitet welcher laut >Deutschem Recht >nicht erlaubt ist. Dies kann Ermittlungen von Behoerden nach sich >ziehen. Maybe worth to update https://trac.torproject.org/projects/tor/wiki/doc/GoodBadISPs ? 2. ========= I'm planning to setup there a dedicated server now soon (with Gentoo Linux if possible) within next days - or are there too much servers already at the ISP Hetzner ? 3. ========= And for the following days I do want put the line "ExitPolicy reject *:*" before all subsequent liens like "ExitPolicy accept *:20-23 # FTP, SSH, telnet" of the reduced exit policy to just look how the system behaves as a simply relay. Worth or superflous ? Am I right, that later just commenting out that reject line enhance the Tor server from relay to "relay + exit node" ? Or does this mean that -- Toralf pgp key: 0076 E94E

6 9

What to change for v0.2.5.x?
by Steve Snyder 12 Sep '14

12 Sep '14

So now Tor v0.2.5.x Release Candidates are available. Can someone give an overview of what's new for those who don't follow the development process? What can/or should be changed in a working v0.2.4.x relay config to accommodate the changes made in the new code? Are there particular areas (IPv6, multi-threading, etc.) that one should be aware of when moving from v0.2.4 to v0.2.5? The changelogs do a great job of describing the changes between point releases but are somewhat overwhelming when attempting to determine the differences between major releases. If would be great if someone could give a brief(-ish) description of those changes. Thanks.

3 3

IPv6 - status
by Marcin Gondek 12 Sep '14

12 Sep '14

Hi, What is the current state of IPv6? ==cut== Relays to relays Relays talk to other relays. The work with relays talking to other relays over IPv6 has not been started. ==cut== Is there any plans to start? How I can help? ==cut== Directory authorities on IPv6 Clients and relays talk to directory authorities. The work with making directory authorities reachable over IPv6 has not been started. This work will be tracked in #6027. ==cut== Same as above? Clue is when it will be possible to run pure IPv6 relay/guard. Regards, -- Marcin Gondek / Drixter http://fido.e-utp.net/ AS56662

3 4

Re: [tor-relays] boost CPU on a Tor relay
by Harold Naparst 09 Sep '14

09 Sep '14

I'll just throw in my datapoint on this subject because it might be of interest. My relay (torpoint) is currently advertising a bandwidth of 58 MB/s according to Globe. Arm reports that it is pushing 50 MB/s and has 12,500 open clients. It has a Xeon E3/1220 with 8 GB ram. The load average is 0.75, and the four cores are at about 20-25% each. About 2GB of ram is being used. On the whole, this relay is probably bandwidth constrained. The ISP guarantees 150 Mbps, but I sometimes get more, like now.

1 0

Gentoo overlay
by Harold Naparst 09 Sep '14

09 Sep '14

Sorry Jeremy, I didn't realize you were a Gentoo dev. I have added the comment to the Gentoo bug discussion per your wishes.

1 0

Re: [tor-relays] enable-ec_nistp_64_gcc_128
by Harold Naparst 09 Sep '14

09 Sep '14

I thought about this also, but I decided not to do it. Gentoo has clearly decided not to include the Elliptic Curve algorithms until they can get confirmation that it works on all archs. Funtoo has taken the opposite position. >From the looks of the Gentoo thread, they should add the flag in the near future, and I think it would be more diplomatic to just let the process play out. My hope is that a Google search would lead most people to this post. I just created the ebuild in my overlay because I wanted it now and I thought some other enthusiasts would also want it now. I hope it works for you, and would be interested if it makes a difference. > Thanks for your contribution, can you also add some note to the > underlying bug report https://bugs.gentoo.org/469976 so others may see > it easier? > -Jeremy > On Mon, Sep 8, 2014 at 2:52 PM, Harold Naparst <harold(a)alum.mit.edu> wrote: >> If you want a version of openssl compiled with the >> enable-ec_nistp_64_gcc_128 option and you are using Gentoo Linux, >> you can grab it from my overlay:

1 0

enable-ec_nistp_64_gcc_128
by Harold Naparst 09 Sep '14

09 Sep '14

If you want a version of openssl compiled with the enable-ec_nistp_64_gcc_128 option and you are using Gentoo Linux, you can grab it from my overlay: layman -f layman -a hnaparst emerge openssl The new flag "nist" is turned on by default. I have 1.0.1i and 1.0.2_beta2 in the overlay. Hope it helps.

2 1

TTTT
by Sebastian Urbach 08 Sep '14

08 Sep '14

Dear list members, Just a quick update regarding TTTT: Currently we are working on a technical paper based on the so far collected data. ETA is roughly 4 weeks from now on. The paper is going to hit this list asap. -- Mit freundlichen Grüssen / Sincerely yours Sebastian Urbach ---------------------------------------------- Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. ---------------------------------------------- Benjamin Franklin (1706 - 1790), Inventor, journalist, printer, diplomat and statesman

1 0

Handshake flood now on NTor
by Jobiwan Kenobi 08 Sep '14

08 Sep '14

Hi, For about 15 hours straight, my relay was being hammered by connections/handshakes. I see lots of these: Sep 02 01:03:02.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. [70638 similar message(s) suppressed in last 60 seconds] Numbers vary between 30000 and 80000 per 60 seconds. Also the occasional clock jump message and other performance related messages, and of course, _lots_ of unsuccessful handshakes: Sep 01 22:31:26.000 [notice] Circuit handshake stats since last time: 5038/5038 TAP, 17771/17773 NTor. Sep 02 04:31:26.000 [notice] Circuit handshake stats since last time: 3100/3484 TAP, 465565/5417818 NTor. Sep 02 10:31:26.000 [notice] Circuit handshake stats since last time: 3139/4249 TAP, 679872/8244698 NTor. Sep 02 16:31:26.000 [notice] Circuit handshake stats since last time: 3884/5294 TAP, 502835/10443735 NTor. It is a low spec machine. I've been through episodes like this before, but this time it's different: - They are NTor handshakes, where before they would be TAP handshakes. - The amount of up and down traffic is pretty balanced, where before I would get much more down than up during these floods. - In case it matters: I am now running 0.2.4.23, before I was on 0.2.4.18-RC It stopped about 4 hours ago. Running normal now. -Job

3 3

fingerprint info propogation
by jason＠icetor.is 07 Sep '14

07 Sep '14

Sorry if asked before, made a stupid oversight restarting one of my exits yesterday, had duplicated the fingerprint file from another node. Changed the file to the correct nickname today (I know nicknames are depreciated now) and reset tor, how long will it take this change to propogate to the network? -Jason

4 4

TOR exit notice (not USA)
by Christian Gagneraud 06 Sep '14

06 Sep '14

Hi there, I've just installed the tor-exit-notice.html (from contrib/) on my exit node, and read it carefully. I think this is great to have such a text, but 2 paragraphs are USA specific, the one about ECPA and the following one about DMCA. I would like to know if anyone knows about equivalent text for the European Union, Germany, France and New Zealand (I'm French, I'm a New Zealand resident and I run a TOR exit node on a server located in Germany) Thanks, Chris

4 4

Time information
by Marcin Gondek 05 Sep '14

05 Sep '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I just looking on the logs and see: ==cut== Sep 02 21:03:54.000 [info] channel_tls_process_netinfo_cell(): Received NETINFO cell with skewed time from server at x.x.x.x:443. It seems that our clock is behind by 1 hours, 24 minutes, or that theirs is ahead. Tor requires an accurate clock to work: please check your time and date settings. Sep 02 21:06:04.000 [info] channel_tls_process_netinfo_cell(): Received NETINFO cell with skewed time from server at x.x.x.x:9001. It seems that our clock is ahead by 1 hours, 4 minutes, or that theirs is behind. Tor requires an accurate clock to work: please check your time and date settings. Sep 02 21:06:08.000 [info] channel_tls_process_netinfo_cell(): Received NETINFO cell with skewed time from server at x.x.x.x:9001. It seems that our clock is ahead by 3 hours, 35 minutes, or that theirs is behind. Tor requires an accurate clock to work: please check your time and date settings. Sep 02 21:06:58.000 [info] channel_tls_process_netinfo_cell(): Received NETINFO cell with skewed time from server at x.x.x.x:9001. It seems that our clock is behind by 5 hours, 58 minutes, or that theirs is ahead. Tor requires an accurate clock to work: please check your time and date settings. Sep 02 21:08:53.000 [info] channel_tls_process_netinfo_cell(): Received NETINFO cell with skewed time from server at x.x.x.x:9001. It seems that our clock is behind by 1 hours, 54 minutes, or that theirs is ahead. Tor requires an accurate clock to work: please check your time and date settings. Sep 02 21:10:49.000 [info] channel_tls_process_netinfo_cell(): Received NETINFO cell with skewed time from server at x.x.x.x:9001. It seems that our clock is behind by 5 hours, 55 minutes, or that theirs is ahead. Tor requires an accurate clock to work: please check your time and date settings. Sep 02 21:11:51.000 [info] channel_tls_process_netinfo_cell(): Received NETINFO cell with skewed time from server at x.x.x.x:8443. It seems that our clock is ahead by 1 hours, 26 minutes, or that theirs is behind. Tor requires an accurate clock to work: please check your time and date settings. Sep 02 21:11:52.000 [info] channel_tls_process_netinfo_cell(): Received NETINFO cell with skewed time from server at x.x.x.x:449. It seems that our clock is ahead by 1 hours, 19 minutes, or that theirs is behind. Tor requires an accurate clock to work: please check your time and date settings. ==cut== Should I worry about it? Logs seems to little strange and looks that other servers provide it's local time without any timezone. [root@fido tor]# ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== +x.x.x.x .PPS. 1 u 11 64 377 15.026 2.142 3.279 +x.x.x.x .PPS. 1 u 26 64 377 8.315 2.734 4.281 +x.x.x.x .PPS. 1 u 2 64 377 6.511 0.973 3.214 *x.x.x.x .PPS. 1 u 60 64 377 6.395 2.162 1.869 oGPS_NMEA(0) .GPS. 0 l 15 16 377 0.000 0.014 0.009 And server is a part of ntppool - valid. Regards, - -- Marcin Gondek / Drixter http://fido.e-utp.net/ AS56662 -----BEGIN PGP SIGNATURE----- Version: Outlook Privacy Plugin iGkEARECACkFAlQGGCoiHE1hcmNpbiBHb25kZWsgPGRyaXh0ZXJAZS11dHAubmV0 PgAKCRCBZoxYcbpnGhhSAJ0RENGRgehGCb/9m/P2lTHR/2k+kACgwOIXsUNHS6FW 1AOwVQoeTwSPCO0= =OYl2 -----END PGP SIGNATURE-----

6 8

ORCONN
by Yannick Krueck 03 Sep '14

03 Sep '14

Hello, I provide a Tor-Relay Server. I have a questions regarding the Tor control protocol. If i use "setevents orconn", i get a lot of Connections. Mostly i get first a "New/Launched" message, then a "Connected" message and then a "Failed/Closed" message. But sometimes i get only a "New"-message, and a "Connected" message, but I never receive a "Failed" or "Closed" message. In this case, i only get the IP Adress, but no LongName. For example: 650 ORCONN 81.219.94.108:1976 NEW 650 ORCONN 81.219.94.108:1976 CONNECTED => Never Receive a Closed oder Failed Message Additional i can not find the IP-Adress 81.219.94.108 on https://onionoo.torproject.org/details . The question: What or Who is 81.219.94.108? Another relay? A Bridge? A normal User (Entry Guard)? 81.219.94.108 is only an example, their are many more Nodes with the similar procedure. Thank you for answering my question Y. Krueck (Germany)

1 0

oniontip.com
by Sebastian Urbach 01 Sep '14

01 Sep '14

Hi, I like to suggest adding oniontip.com to the "Donate" section on the tor website. It's a nice possibility to help the Relay-Oerators. Have a nice day. -- Mit freundlichen Grüssen / Sincerely yours Sebastian Urbach ---------------------------------------------- Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. ---------------------------------------------- Benjamin Franklin (1706 - 1790), Inventor, journalist, printer, diplomat and statesman -- Mit freundlichen Grüssen / Sincerely yours Sebastian Urbach ---------------------------------------------- Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. ---------------------------------------------- Benjamin Franklin (1706 - 1790), Inventor, journalist, printer, diplomat and statesman

4 4

is a KVM fine for a first quick test to setup a tor exit node
by Toralf Förster 01 Sep '14

01 Sep '14

I do have here a Gentoo Linux and a KVM (Gentoo too) - now I'm wondering if I can just emerge the Gentoo Tor package here in the KVM and play with it or should I prepare few things before to avoid that it will be used by the Tor network immediately ? -- Toralf pgp key: 0076 E94E

2 1

Expired Key
by Sebastian Urbach 30 Aug '14

30 Aug '14

Hi, The key from deb.torproject.org archive is expired, a new one would be nice. The installation information in the docu should be updated to the new key id as well. Thanks -- Mit freundlichen Grüssen / Sincerely yours Sebastian Urbach ---------------------------------------------- Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. ---------------------------------------------- Benjamin Franklin (1706 - 1790), Inventor, journalist, printer, diplomat and statesman

2 1

Authdir is rejecting routers in this range
by Davíð Steinn Geirsson 29 Aug '14

29 Aug '14

Hi all, I rented a dedicated server to run a tor relay (100Mbit/s) to contribute to the network. On this machine, tor gives messages like these on startup: http status 400 ("Authdir is rejecting routers in this range.") response from dirserver '<...>'. Please correct. The server is hosted with https://fdcservers.net/. Did I just get unlucky in picking a provider? Is there a way to check these things before spending money on setup + monthly fees? Best regards, Davíð

4 5

Key expired problem - Ubuntu 12.04 LTS
by kingqueen 29 Aug '14

29 Aug '14

I'm experiencing difficulties running apt-get update as it complaints that the repository's key is out of date. Here's the error: W: A error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://deb.torproject.org precise Release: The following signatures were invalid: KEYEXPIRED 1409325681 KEYEXPIRED 1409325681 KEYEXPIRED 1409325681 KEYEXPIRED 1409325681 W: Failed to fetch http://deb.torproject.org/torproject.org/dists/precise/Release W: Some index files failed to download. They have been ignored, or old ones used instead. When I set the relay up, I used Option Two on this page https://www.torproject.org/docs/debian to install tor and deb.torproject.org-keyring . Updates worked for 10 weeks or so and now don't. I've tried going through the same processes again, to no avail. Any assistance very gratefully received.

2 1

Centos 7
by obx 28 Aug '14

28 Aug '14

There are no packages for centos 7 yet. Is there an ETA? Is there anything we can do/contribute?

3 2

Re: [tor-relays] Advantage in more exits in the same /8?
by Jesse Victors 27 Aug '14

27 Aug '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA384 On 08/27/2014 04:03 PM, tor-relays-request(a)lists.torproject.org wrote: > Not to drift too far off course, but I think you have your masking > back wards or confused at least. > > a /8 is 16M addresses 18.0.0.0/8 for example, so not a small block, > and a /16 has 64K. > > two consecutive /16's say 128.30.0.0/16 and 128.31.0.0/16 make a /15 > (120.30.0.0/15) > > the real concern is administrative control not addressing. for exmaple > both the /8 and /15 mentioned above and some other smaller patches of > addressing are all on MIT campus and part of the same administrative > domain in the sense that all traffic passes through a small set of > routers at some point. Being a university it doesn't imediately imply > root access to all servers. this isn't true of all (or even most) > /8's, nor does even a /24 with 256 addresses need to be in a single > geographic or andministrative zone. > > -Jon Thanks Jon, You're right, I had my ranges weird, even in my title, thanks for the correction. To clarify, because the nodes are physically close to one another, they are in the same /24, namely x.x.x.x - x.x.x.y. Yes, the real issues is the traffic concentration to a specific set of routers, which is why I'm asking. I'm trying to get a sense of where to draw the line, but from the responses so far it looks like I've got room to spare. - -- Jesse V. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQF8BAEBCQBmBQJT/lfPXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxMjgyMjhENjEyODQ1OTU1NzBCMjgwRkFB RDk3MzY0RkMyMEJFQzgwAAoJEK2XNk/CC+yAYCwH/i6Ci/SS6dpXr703mlajr31C fXX2WOKVWoGGTkPDXkQJM18+uI0DGRaieahmQ99VAGwA8+PAFhq9QsISLZ/Bby9g rZCOkY9E9xel2uu80hiMlP99h4WkjJtbgeX1cGXXOoJq1d+MLHIzQqgzZvmVry2+ piIUsXRO693r+TiU6BzZjnpBm+Omo6BzvOuJmUq34/XztdrGWSfoCvpwlesbMJZc sNGN1N5wQ3U1FcQTkwJc2wVyTpQNyu+tgvZyqwusIwAlH7J9cN/zg+eNZ+3ZpPUv 7DjiKhwQCQUqv/LHC5sK7FmQNELLwXPGvTaflvjfhF9uSBWCAX9JVEBNsHrB1M0= =77pe -----END PGP SIGNATURE-----

1 0

Re: [tor-relays] Advantage in more exits in the same /8?
by Jesse Victors 27 Aug '14

27 Aug '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA384 > Message: 5 > Date: Tue, 26 Aug 2014 19:50:21 +0200 > From: Anders Andersson <pipatron(a)gmail.com> > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] Advantage in more exits in the same /8? > Message-ID: > <CAKkunMYKgXKT1OEbV5Lft9edqLhvAJsbxv7QkHQn6dCbpuj36Q(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On Tue, Aug 26, 2014 at 3:47 PM, Jesse Victors > <jvictors(a)jessevictors.com> wrote: > >> I run some relays and an exit in a university setting. The nodes are in the same /8 block and are physically close to one another as well. Is there any advantage in turning one of the relays into another exit? This is something that my ISP would be agreeable to, but I'm also pondering the effects on the Tor network as a whole. > Just want to be clear here: Do you really mean /8 and not /24? There's > only one university I can find with a /8 block. Anders, no I literally mean the same /8. The university has its own /16 and recently required another /16, but since my nodes are physically close to one another they are in the same /8. My concern is that too many nodes in a small block can result in a large concentration of Tor circuits in that block. No circuit should use any two nodes from the same /16 unless forced to, so my question really revolved around how many is too many Tor circuits and how much is too much traffic through the same /8 or /16 in people's opinion. - -- Jesse V. On 08/27/2014 06:00 AM, tor-relays-request(a)lists.torproject.org wrote: > Message: 2 > Date: Tue, 26 Aug 2014 16:24:42 +0200 > From: Moritz Bartl <moritz(a)torservers.net> > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] Advantage in more exits in the same /8? > Message-ID: <53FC98AA.2000607(a)torservers.net> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi Jesse, > > On 08/26/2014 03:47 PM, Jesse Victors wrote: >> > It seems to me that too many nodes under the same ISP is >> > problematic because it concentrates too much traffic in >> > the same AS, but on the other hand, Tor could use more exits. >> > More importantly, how many is too many nodes in the same /8, >> > or in the same /16? Where would you draw the line? > Very good question. Ideally, the Tor client would be AS-aware, and you > would not have to worry about it. For the interested reader, see for > example [1]. Until then, my thinking is that I compare to other > locations. https://compass.torproject.org/ is very helpful for that: For > example, if you group by AS, the largest AS right now (i3d, NL) in > regards to exit capacity has 11%, and OVH tops the overall network at > 10% consensus weight. > > As a rough rule, I'd avoid to push more than 1-2Gbit/s of traffic at one > ISP. On the plus side, as long as you don't top the list, you're > weighing down other locations. And universities are a preferred location. > > Make sure to use the MyFamily statement correctly: Unless relays are on > the same /16, Tor might pick multiple of them for a circuit. Also, if > you want to push more than ~100 Mbit/s on a single machine, you need > AES-NI or run multiple relays, for more than 400 Mbit/s you need to run > multiple relays in any case. The multi-relay initscript can be quite > helpful for that. > > [1] http://freehaven.net/anonbib/#ccs2013-usersrouted > [2] https://www.torservers.net/wiki/setup/server#multiple_tor_processes > > -- Moritz Bartl https://www.torservers.net/ Thanks Moritz, Ok, so I think 1-2 Gbit/s is a good number, that just seems like an awful lot of data to me and I'd rather see that spread out more diversely of course. I'm aware that no circuit should contain two nodes from the same /16 unless forced to, and the MyFamily value further helps with that. My concern was not with a single circuit using multiple nodes there, but rather many circuits preferring that AS. Diversity helps security. That being said, by your advice I'm nowhere near that threshold, so I could keep going. Thanks for the tips on the multiple Tor instances and the optimization tips. - -- Jesse V. /CS, Network Security / -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQF8BAEBCQBmBQJT/e7iXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxMjgyMjhENjEyODQ1OTU1NzBCMjgwRkFB RDk3MzY0RkMyMEJFQzgwAAoJEK2XNk/CC+yAu0wIAK3rn17vEWQZTZy5KVBgOnUI TstJAkqO9Wjkfxf++E/5h8OMRdU1f3rV2mArJgGbgc344ttueM8iPntneaK4jI9W 4FrEqiMf7X6boYZXyeG81gYaGT6nf8ePSK5+1xY3pGR+2R3gXbDt/AU/LIZFsL2w r+9znukltzWBudfM76Fzd7jJcrwC+2giguHKU1/oxpKDh1xWuQC4maOYxZexGSLw JFz/O9Ca/CIDH/5Pbm6uJFe3Ec1zzm6z8cgsfBmGY8GHj3xBM8bNttP+a+fW7J5Z W01uoYss6tuw3jhVAp/+LKm4GcXsdtUjJIAX56yvEURCa6L9CbuTYha4cBI4zFw= =OHSc -----END PGP SIGNATURE-----

2 1

Ongoing scan from FDCServers block
by linenoiz＠Safe-mail.net 27 Aug '14

27 Aug '14

For the past week or so I've been seeing unsolicited echo replies coming from FDC servers block and one that looks like it is owned by China(?) Most of the entries are from 67.159.54.101 and I am seeing around one per minute. I verified by running tcpdump for a couple minutes (no longer, I'm not an illegal wiretapper!) that I'm not sending echo requests. IPTables is configured to drop and log this invalid traffic. Any idea what they are trying to accomplish? Some convoluted way of pinging me because they don't get an ICMP unreachable back? And why every minute? DENY IN=eth0 OUT= MAC=xxx SRC=67.159.54.101 DST=yyy LEN=40 TOS=0x08 PREC=0x20 TTL=55 ID=61817 PROTO=ICMP TYPE=0 CODE=0 ID=10249 SEQ=0 DENY IN=eth0 OUT= MAC=xxx SRC=67.159.54.101 DST=yyy LEN=40 TOS=0x08 PREC=0x20 TTL=55 ID=61817 PROTO=ICMP TYPE=0 CODE=0 ID=58375 SEQ=0 DENY IN=eth0 OUT= MAC=xxx SRC=67.159.54.102 DST=yyy LEN=40 TOS=0x08 PREC=0x20 TTL=55 ID=39417 PROTO=ICMP TYPE=0 CODE=0 ID=62498 SEQ=0 DENY IN=eth0 OUT= MAC=xxx SRC=50.117.112.42 DST=yyy LEN=40 TOS=0x00 PREC=0x00 TTL=56 ID=28340 PROTO=ICMP TYPE=0 CODE=0 ID=30728 SEQ=0 DENY IN=eth0 OUT= MAC=xxx SRC=50.117.112.42 DST=yyy LEN=40 TOS=0x00 PREC=0x00 TTL=56 ID=28334 PROTO=ICMP TYPE=0 CODE=0 ID=30728 SEQ=0 DENY IN=eth0 OUT= MAC=xxx SRC=50.117.112.42 DST=yyy LEN=40 TOS=0x00 PREC=0x00 TTL=56 ID=28335 PROTO=ICMP TYPE=0 CODE=0 ID=54277 SEQ=0

2 1

managing bandwidth quotum
by Kees Goossens 26 Aug '14

26 Aug '14

Dear all, A question on how to manage a bandwidth quotum of my internet provider. I run a non-exit relay on a hosted server with 1000 GB bandwidth per month. In essence, should I A- only set the AccountingMax, and let the relay figure out the RelayBandwidthRate & RelayBandwidthBurst by itself B- set the AccountingMax, and set RelayBandwidthBurst to whatever the provider will allow (much higher than the average rate) C- set the AccountingMax, and set RelayBandwidthRate to the average rate (quotum/31 days), and optionally set RelayBandwidthBurst D- only set the RelayBandwidthRate to the average rate, and hope that I don’t go too much over my quotum This could perhaps be rephrased as: - is it better to offer a high bandwidth for part of the month and then hibernate, or - should I offer a lower average bandwidth for the whole month? Details: I’ve set “AccountingMax 450 GB” with the appropriate accounting start (conservative, since I log in occasionally too). 450 GB / 31 days => 168 KB / sec average Setting “BandwidthRate 168 KB” seems to severely underutilise the relay. Setting “BandwidthRate 1000 KB”, to force usage of the relay, uses the relay bandwidth at a much larger rate (2670 KB/s consensus weight), and will cause hibernation after ~25 days. Thanks. Kees

3 2

Advantage in more exits in the same /8?
by Jesse Victors 26 Aug '14

26 Aug '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA384 Hey everyone, I run some relays and an exit in a university setting. The nodes are in the same /8 block and are physically close to one another as well. Is there any advantage in turning one of the relays into another exit? This is something that my ISP would be agreeable to, but I'm also pondering the effects on the Tor network as a whole. It seems to me that too many nodes under the same ISP is problematic because it concentrates too much traffic in the same AS, but on the other hand, Tor could use more exits. More importantly, how many is too many nodes in the same /8, or in the same /16? Where would you draw the line? - -- Jesse V. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQF8BAEBCQBmBQJT/JACXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxMjgyMjhENjEyODQ1OTU1NzBCMjgwRkFB RDk3MzY0RkMyMEJFQzgwAAoJEK2XNk/CC+yAc30H/itZHxdCndyXrynjhCI9N3Y/ jtdQ4V2UVWGe0YdsHBrSibexvZxj9EGtNHAuBNuf9ZPrTV5BXV4/Q0RXRZSp+AZ7 NVCp0/7wv/R/n+1qJqWfD2F0D27pyQoaHTMHSJKWXeVN71F5uM4+ScG5qyGsgsG7 Op9s3K5tYTr4m2WcPoAQke4Gj7Bn4nBIbJP8djPZeQ5ACKIDfBJjlgy6Q7fJE+E7 62GYvRknYVHjWAM6gsYSuHnoBCGPAcYkSWMOyPBf+rt8+J0HCMBja/yvzBMwMiNu jEGK/pFka6j+CKYZuEXIbfBV4MLnbZqaah5e58640rUvwqz5eFvf2pliONpVGY4= =aTsa -----END PGP SIGNATURE-----

3 2

how long till the axe falls on little guard relays?
by starlight.2014q3＠binnacle.cx 25 Aug '14

25 Aug '14

The guard status of the relay here is hanging on by a thread (consensus 5-in-favor 4-against) and this had me wondering until I read [tor-relays] don't worry (to much) if your relay is loosing the guard flag https://lists.torproject.org/pipermail/tor-relays/2014-July/005043.html Looking at the Consensus Health page it's clear that about 1000 other relays are also separated from Guard Oblivion by a single vote. I'm curious if anyone knows roughly when the next authority will upgrade to a version with the new criteria and the little guards get the chop.

5 5

Relay "kingqueen" lost Named attribute
by kingqueen 22 Aug '14

22 Aug '14

hi, Does anybody know why my relay "kingqueen" has lost its Named attribute? https://atlas.torproject.org/#details/7B48192A59A903F914ECF73ADBC3711F3E8EA… Thank you KQ

3 3

Re: [tor-relays] OnionTip.com distributes Bitcoin donations to all BTC addresses set in ContactInfo
by Tim 21 Aug '14

21 Aug '14

On 14 Aug 2014, at 22:00, Alexander wrote: >> On 2014-08-14 10:25, Mike Cardwell wrote: >> >> On the other hand. It costs you nothing to stick a bitcoin >> address in a config file to find out. > > Not being a lawyer, does accepting money for running a Tor relay make it > a commercial operation (in some countries) and put you in a different > legal position? > > Best regards, > Alexander Also not being a lawyer, if BTC isn't legal tender in your country (if such a concept exists), are you really accepting "money"? Tim

3 3