tor-relays September 2016

tor-relays@lists.torproject.org

78 participants
60 discussions

Monitoring multiple relays
by Xza 01 Nov '17

01 Nov '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello, I have a couple relays / exits running. Now my question is : how do you manage them is there any dashboard or CLI tools to manage them ( statistics, ect.. ) I know the cli tool specially for Tor "arm" Thanks alot. - -- PGP : 29A4CE52 -----BEGIN PGP SIGNATURE----- iQI4BAEBCgAiGxxEbyA8eWFuZGVyZXNvbkByaXNldXAubmV0PgUCV0SJlwAKCRBI of/XNyszSvv/D/9VtjI+bmiqK53v//StUbmpYjgQjYheYvwktFld+2XDURh52dmU sbk3lab2RS1eQJxjV0BVXMF9O2JUAlp4NA2UMpj8ZJlCk0h1S6p2o4/sAlsrHr8Z nb67HiaRIyEvi9cQiXFtDtK/onAkEuKskolyvh3ysJRRUubHSX1z8WuNJIc4xyGH ZpSLPGUOO6qI7mM8ztS0muEy1khmkHgtlyHi2l4K/NsW3I90cV3w6Db2AEnV6v1c tsfehqLExsHUdEo0U3hHU7yY1p2fzD5Z+C0tgVKTnP5Zus/Vr9OH/zFwxneo0E7a 5FHdnCZnNIG9W32uQgjDdmBEv/YFEd0um/vMWFGUehFANSt+DIps7E+AjwiJwm2i ov97JJurQkrSMX7ZchTEsy720Ju272olp2eDiHaXXTK2TkxcEq+d1gZfj7CXycPW 6mCrj6L6URJAZ34GJQfFFjv8QbFmKkAvGhxl/O8KXRbXxedbLH7PY73jmFjJcmxO +KnSeyqMe1KbzazYyFydP+VmgI2k1IlO89l8Jq1Gq9f2KOPY9UKFZjGDKLS0xGZW EnqU/KUINcrGejYFT8nYNxA+OFTd/ZGIX5qP4Vo5NsZ/pDLZjdxIcvHx1jjZbER+ 5Ku2bihm2KTNAGoYDqB3LGCm+QdEFG/p573xQCcXPk92GyhMJDi9EMPDgA== =mTa0 -----END PGP SIGNATURE-----

8 8

Please enable IPv6 on your relay!
by Moritz Bartl 28 Jan '17

28 Jan '17

Hi! We still have a depressingly low number of relays that support IPv6 (currently only ~120 of ~1900 relays). If your host supports IPv6, please enable it, especially if you run an exit! This has to be done explicitly. https://trac.torproject.org/projects/tor/wiki/doc/IPv6RelayHowto In short, you add: ORPort [IPv6::address]:port IPv6Exit 1 ExitPolicy reject6 *:* (or a more open exit policy respectively) Thanks! -- Moritz Bartl https://www.torservers.net/

30 42

Netflix overblocking non-exit Tor relays
by Gero Kuehn 16 Dec '16

16 Dec '16

tl;dr: Even paying customers sharing IPs with non-exit Tor relays are now blocked from accessing Netflix Hello everyone ! After two very fruitless attempts to get the issue silently resolved through proper Netflix support channels, the time has come to make this public. As some of you have probably already read in the news, Netflix recently announced a crackdown on what they call "VPN Pirates" and what I call "paying customers using the same benefits of globalization that global companies like Netflix (ab)use for their taxes". They have now obviously changed their strategy regarding the Tor network. I am operating (among others) a middle-relay on a German residential fixed-ip VDSL-50 line (dc6jgk1/486740353B905AA4731F82C0B4CC25821A62C6E3) behind a NAT. Until 2 days ago, none of the devices sharing the same external IP address had any problem connecting to Netflix and there never was a Tor exit relay on that IP as far as I can tell. It is also obviously not possible for users of the Tor network to connect to Netflix through middle relays. As a consequence they should not be classifying such IP addresses as VPNs/Proxies and they should not be blocking them. This has been escalated and explained twice to "technical supervisors" in their callcenters. They did however not leave the impression that they a) care or b) intend to fix this at some point by parsing the Tor network information properly instead of using whatever cheap&wrong hack they use now. The official response from Netflix is that you now need to make a choice between operating that Tor relay (of any type) and the ability to watch Netflix. They also strictly refuse to refund any remaining credit in the customer account. My personal choice with regards to that blackmailing is as clear my next steps (conditional cancellation, 14 day deadline for refund and a legal challenge of their German AGB with regards to this issue). I am allergic to being blackmailed like that and being called a pirate by a service I legitimately paid for. For those of you who just would like to contribute to the Tor network without having trouble like that, please do not let this nonsense stop you. A more diversified Tor network is a more healthy network and I would really like to see more normal users operating tor relays operating in as many different locations as possible - including DSL lines "that are there anyways". If you do not want to be put into a position where you have to choose between your contribution to the network and some legal and paid-for entertainment, you might want to operate only a bridge until the issue has been resolved. If you already have the same problem, make it as expensive for Netflix as possible and spread the word about why this block (and geoblocking in general) is wrong. Thanks ! Kind regards, Gero / dc6jgk

14 21

Rampup speed of Exit relay
by D.S. Ljungmark 27 Oct '16

27 Oct '16

Hi all, I'm looking at some traffic patterns for my Exit relay, and I'm frankly a bit disappointed with the utilization. Currently it's running at a load average of 0.3-0.5, and CPU idle at 70-80%. We're not limited on Bandwidth (tests show that our max cap is more than safe to produce), yet, we're barely reaching 20% of our potential allocated traffic. We've reached "fast" and "guard", and got the "stable" flag as well, so in theory we ought to see traffic move a bit higher than currently. So, how do we get tor to move past 100-200Mbit? Is it just a waiting game? //D.S. -- 8362 CB14 98AD 11EF CEB6 FA81 FCC3 7674 449E 3CFC

10 21

relay lost most of its consensus weight
by jensm1 19 Oct '16

19 Oct '16

Hi, I just realised that my relay 'itwasntme' lost most of its consensus weight yesterday morning. The relay is only three weeks old, but it was finally picking up some traffic, which now is gone again. What could be the cause for this? Is there a problem with my relay or configuration? Thanks for your help! https://atlas.torproject.org/#details/F46C312E279185364F46EA06C58F792528091…

4 11

Running tor on OpenBSD with hardware acceleration
by Farid Joubbi 12 Oct '16

12 Oct '16

Hello, I have a relay running on OpenBSD. LibreSSL that comes with OpenBSD does not have support for hardware acceleration. I get this when I start tor: "[notice] We were built to run on a 64-bit CPU, with OpenSSL 1.0.1 or later, but with a version of OpenSSL that apparently lacks accelerated support for the NIST P-224 and P-256 groups. Building openssl with such support (using the enable-ec_nistp_64_gcc_128 option when configuring it) would make ECDH much faster." How do I enable support for hardware acceleration? My guess is that I have to compile and install OpenSSL, then compile Tor to use the new OpenSSL. Does anyone here have any experience with this on OpenBSD? Anything that I have missed and should be aware of? Thanks.

3 3

Moving multiple instances to another VPS
by pa011 12 Oct '16

12 Oct '16

I have to move a multiple instances Exit from one VPS to another. Apart from creating the same instances on the new machine with **tor-instance-create** I would then just copy the whole directory /var/lib/tor/keys to the new VPS - or should I copy all /var/lib/tor/ to not miss anything from the original one? Am I miss anything else? Thanks Paul

4 5

The Onion Box v3.0: Web Interface for your Tor relay
by Ralph Wetzel 04 Oct '16

04 Oct '16

5 10

Re: [tor-relays] help #3
by teor 02 Oct '16

02 Oct '16

> On 30 Sep 2016, at 14:37, Markus Koch <niftybunny(a)googlemail.com> wrote: > > Installed with apt-get and started simply as a demon aka service tor start > Thank you for helping Have you tried: >>> sudo su debian-tor --shell /bin/bash --command "ulimit -Sn" >>> sudo su debian-tor --shell /bin/bash --command "ulimit -Hn" What are the file descriptor limits set to? How much RAM does the system have? What are the TCP buffer limits in the kernel? Here's some background: In Tor, there are the 4 C/Linux error return values that can trigger that message: EMFILE ENFILE ENOBUFS ENOMEM On my system, "man 2 intro" lists them as: Too many open files...the limit on the number of open files per process... Too many open files in system. Maximum number of file descrip- tors allowable on the system has been reached... No buffer space available. An operation on a socket or pipe was not performed because the system lacked sufficient buffer space or because a queue was full. Cannot allocate memory. The new process image required more memory than was allowed by the hardware or by system-imposed mem- ory management constraints… T > > Markus > > > > > > > 2016-09-30 23:33 GMT+02:00 teor <teor2345(a)gmail.com>: >> >>> On 30 Sep 2016, at 14:01, Green Dream <greendream848(a)gmail.com> wrote: >>> >>> Have you double-checked the ulimit was applied correctly? Including >>> making sure it's applied to the user account running Tor? Here's how I >>> do that on Ubuntu/Debian, assuming the user account is "debian-tor": >>> >>> sudo su debian-tor --shell /bin/bash --command "ulimit -Sn" >>> sudo su debian-tor --shell /bin/bash --command "ulimit -Hn" >>> >>> Those should return the actual hard and soft limits being applied to >>> the debian-tor user. In my case it returns 64000, but you'll just want >>> to make sure it's what you're expecting. >>> >>>> nothing works and now I am running out of ideas >>> >>> It would be easier for people to help if you elaborate a bit -- >>> perhaps the exact commands you've already tried and the log messages >>> (if there are any other error or warning messages besides the one you >>> already listed). >> >> The debian packages should set the appropriate file descriptors for you. >> How are you launching your tor services? >> >> T >> >> -- >> Tim Wilson-Brown (teor) >> >> teor2345 at gmail dot com >> PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B >> ricochet:ekmygaiu4rzgsk6n >> xmpp: teor at torproject dot org >> >> >> >> >> >> >> T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org

2 1

help #3
by Markus Koch 30 Sep '16

30 Sep '16

me again ... I need the knowledge of the almighty tor operators. I set up three new and shiny tor exists and got a not so shiny error message: [WARN]Failing because we have 4063 connections already. Please read doc/TUNING for guidance It was already in this mailing list: http://archives.seul.org/tor/relays/Feb-2016/msg00060.html I "tuned" it with ulimit https://gitweb.torproject.org/tor.git/tree/doc/TUNING/ and nothing works and now I am running out of ideas and getting pissed. They exits are running a Debian 7 x64 minimal install with the newest tor version. Any ideas how to fix it? Markus

4 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-relays September 2016