- tor-relays - lists.torproject.org

Google Compute Engine rejected as relay?
by Greg 22 Aug '15

22 Aug '15

Hi, I tried to spin up a relay on GCE a few days ago, and I found that it was outright rejected with a message like "Authdir is rejecting routers in this range". I don't have the IP handy now, but I could easily get another ephemeral IP. I thought I came across a thread saying that there was an attack on the tor network originating from GCE, and that's why it got blacklisted. I'm not finding that thread now. But is GCE going to be removed from the blacklist? I realize it's not a very economical place to run a relay. -Greg

5 6

Re: [tor-relays] Calling for more Exit Relays
by spiros_spiros＠freemail.gr 21 Aug '15

21 Aug '15

Στις 21 του Αυγούστου 2015, 13:21, Sharif Olorin <sio(a)tesser.org> έγραψε: >Could you estimate the number of abuse complaints you receive, or the >amount of time you need to spend responding to them - and how many >exits for how long, for context? I am the operator of exit relays in Iceland, England and Czech republic (as well as some non-exit relays where the providers are less friendly to Tor/don’t understand Tor). The nodes have been built in the last six months (financial circumstance only permitted me to start contributing recently), and I hope to run them for many years to come. As such they are all Debian Linux based with administration via Chef, so I probably spend an hour per month on the admin for all of them in total. Abuse complaints generally come in the form of automated email from Webiron and similar services, via the hosting providers. In one case, the hosting provider is happy to change the PTR record and abuse email in the WHOIS to an address that I control, so that they don’t bother forwarding the mail. I get about 5 of these per month for all of the exits, and no action is necessary. In rare cases, the hosting company based in the Czech republic asks me what steps I have taken in response to the abuse report. In this case I respond quickly with a polite message with the actions I’ve taken (blocking the host in the firewall, temporarily restricting the port in question or agreeing with the complainant that they will block the host). I spend about an hour per month on this task as well. The most frustrating part of this is when one of the exit nodes attacks a honeypot or connects to a sinkholed DNS domain, and I have to query the NIDS to make sure it is legit Tor traffic and my boxe s aren’t compromised. The other category of abuse is far more rare but takes a lot of time, and that is legal threat from a company or state entity. I’ve been very lucky and so far only had two such cases, both of which required multiple emails to be sent and staff to be educated in the purpose and functionality of Tor to make the issue go away. These cases took a few hours of work and worrying each. All of my exits have a web page on port 80 explaining that they are a Tor exit and what that means. Hope this is helpful. Spiros

4 4

Are BWauths punishing 'bad' relays? (not publishing measurements)
by nusenu 18 Aug '15

18 Aug '15

Hi, this is actually a question to BWauth ops. even though the new onionoo measured flag data is not* yet completely rolled out (since it has to be deployed for > a week to assign the flag to all relays), I would have a question since the data says that all relays in the previously detected AWS family [1] are unmeasured. I'm wondering whether this is a pure coincidence or on purpose (by BWauths) or by some other yet to be found reason? thanks! [1] https://lists.torproject.org/pipermail/tor-talk/2015-July/038623.html The "spikes" in the following table brought me two that group again. The table shows unmeasured running relays by the month they joined the network (note this is based on preliminary onionoo data) The "spikes" are caused by relays mentioned in [1]. +-----------+---------+ | joinmonth | #relays | +-----------+---------+ | 2015-07 | 3 | | 2015-06 | 4 | | 2015-05 | 2 | | 2015-04 | 12 | <<< AWS family part II | 2015-03 | 4 | | 2015-02 | 35 | <<< AWS family part I | 2015-01 | 2 | | 2014-12 | 2 | | 2014-11 | 8 | | 2014-10 | 1 | | 2014-09 | 3 | | 2014-08 | 3 | | 2014-07 | 2 | | 2014-06 | 2 | | 2014-05 | 1 | | 2014-04 | 4 | | 2014-03 | 1 | | 2014-01 | 2 | | 2013-11 | 1 | | 2013-02 | 1 | | 2012-04 | 1 | | 2012-02 | 1 | +-----------+---------+ onionoo data from 2015-08-18 18:00:00 (thecthulhu instance)

2 2

No guard flag?
by Tor Tor 18 Aug '15

18 Aug '15

Hi, I'm running a relay node [1], and it's been up for a few days over 68 days. I was thinking it would get the guard flag around then. It has yet to get the flag or have non-zero guard probability. Any idea why that is? Or what I could do to get it to be a guard? 1) https://globe.torproject.org/#/relay/741488D89B860E59D6391ACA27A157E87EB533… Thanks, G

5 5

Guidelines for lifetime of a bridge?
by Tim Sammut 17 Aug '15

17 Aug '15

Hi. Is there a guideline for how long a bridge should exist on a particular IP address? For example, does it make sense to keep a bridge on one IP address forever? Or is it better to move a bridge to a new IP address periodically, perhaps every 120 days? I ask because I saw traffic to my bridge ramp-up fairly steadily, and then quickly drop-off to a low number of clients per day. Thanks! hope you are all well t -- Tim Sammut ~ @t1msammut ~ tim(a)teamsammut.com Ford-Mozilla Fellow at Amnesty International

5 5

urras? [was: tor network "loses" ~50 relays/day due to bw auth problem]
by coderman 17 Aug '15

17 Aug '15

On 5/31/15, Jannis Wiese <mail(a)janniswiese.com> wrote: > ... > At the moment I just see urras missing from the consensus... i would like to report a missing Tor-DA to the authorities. ;) best regards,

2 1

do not run Tor client and OR relay together!
by starlight.2015q3＠binnacle.cx 16 Aug '15

16 Aug '15

Anyone who has configured a Tor SOCKS5 client to run in a 'tor' instance that also operates as an OR relay should isolate the client to a separate client-only process. The client function disturbs relay traffic forwarding in a manner that lends itself to confirmation analysis. See bug 16585, particularly comment 5 and onward: https://trac.torproject.org/projects/tor/ticket/16585#comment:5 Perhaps read comment 10 first.

7 8

Multicore, bandwidth, relays, capacity, location
by grarpamp 13 Aug '15

13 Aug '15

On Wed, Aug 12, 2015 at 9:16 AM, Thomas White <thomaswhite(a)riseup.net> wrote: > For relays, being able to make more use of available bandwidth would > vastly increase the network speed, furthermore make home clients see > an improvement in their daily Tor usage. It also benefits hidden > service people as they can then run their Tor processes on more than > one core and thus handle higher volumes of traffic. Tor appears maybe operating at 50% of bandwidth capacity... https://metrics.torproject.org/bandwidth-flags.html https://metrics.torproject.org/bandwidth.html https://metrics.torproject.org/bwhist-flags.html If that's true, more bandwidth won't have any end user affect. So for the moment it might be worthwhile to study reducing node based latency by ensuring relay CPU's have similar free capacity available for circuit negotiation, interrupt processing, and other tor functions. And to consider not dropping more bandwidth weight into already saturated jurisdictions, but dropping some into the Southern Arc and Eastern Zones in an effort to avoid Orion's Belt... https://metrics.torproject.org/uncharted-data-flow.html [Yes I broke the thread because "no subject" and gmail are even lamer than I].

2 1

IPv6 vs IPv4 exit policies
by spriver 12 Aug '15

12 Aug '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, I just activated IPv6 support for my two exit relays today, but I do not unterstand/misconfigured the exit policies. I just want to open certain ports at IPv4 (the common known reduced exit policy) and open all Ports at IPv6 except 25. How do I configure such a thing? Current sample config is: [snip] IPv6Exit 1 ExitPolicy accept6 *:* ExitPolicy reject6 *:25 [full reduced exitpolicies snipped out] ExitPolicy accept *:50002 # Electrum Bitcoin SSL ExitPolicy accept *:64738 # Mumble ExitPolicy reject *:* But at Globe only this is visible: https://globe.torproject.org/#/relay/F5B1FC9038A5A65FF16D6729AAB2AEDD67F D2F2A https://globe.torproject.org/#/relay/D9D7A9C203C99945D0DCBD545A20C0CB936 7C742 Can someone help me out there? Cheers! spriver -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVyNfsAAoJEMkUf8VoejgPiEEP/jS0fkncI8EWdnNm6mWvOB2Z GybS2ZpzKMYzXTx277gp5AXsySBYsMjVDpxKLsWnfhejbKiv5SxgOYipnfROLoyd uTiqP+Ha+SB83DLM9/x9/OWOImT5qdEhKHVZVrW5UeQQJ9kZPO2R7eQ5w2aQfpVd wJ5nv8iSOuL79LPDVidNcAbFrqZ07R1DW/XUMXdlgdWjNd3ToJEBxussIQFMkQLH l6mQf8lF44Hau+udwiOvmKW6xjkMMPcg16jd/hHmimcQ1pgYV0sVS3XKxJifjKKQ VLIGa1oR1rV6rJEpE+F+6f+8HGJsoilda+eDMdgLzkD0Mi+/kHNbKEokyhAEqmxd fTyY5tt10ypXprYr75F6KEvBEP9h0qHY1NRt38YbLW2J4UCGDcW9ZB3xggFCa2iz 14twdT7qnyu8QuFUzox4DaxEyzeTeZXkKpjHsNABAPlGgenDhDkNldeuQnv4n3xc mBGhoobtDKRsi9aKg+9n1qgePOk7kJVUzEyi1Vwk8RdXwu8AyucejVoC7m7cgakW bFWGyNumezGlY2jMz+ARAEDJfG0LrgpEalJ06qZovUibLBCcOludI0Xdp7Y04vH0 PnWotybn7YZjOa69oJ7HGxiAHEoNgT4SeRM/NIvVWTOdgLPbE1Nr2o1drYpmMyjR aoSklTseBiKF+b1bex1L =Bo5q -----END PGP SIGNATURE-----

3 2

Re: [tor-relays] Guard flag flapping
by torrry＠Safe-mail.net 10 Aug '15

10 Aug '15

> So we now have the bandwidth, IP, and dirport of the fastest exits. With this list in hand, I just needed to form a proper URL, wget each one, and grep out the transfer speed: > > http://37.130.227.133:80/tor/server/all 1.17 MB/s > http://176.126.252.11:443/tor/server/all 4.54 MB/s > http://176.126.252.12:21/tor/server/all 666 KB/s > http://77.247.181.164:80/tor/server/all 111 KB/s > http://77.247.181.166:80/tor/server/all 330 KB/s > http://195.154.56.44:80/tor/server/all 3.65 MB/s > http://77.109.141.138:80/tor/server/all 2.20 MB/s > http://96.44.189.100:80/tor/server/all 13.4 MB/s > http://197.231.221.211:1080/tor/server/all 347 KB/s > http://89.234.157.254:80/tor/server/all 295 KB/s > > I'm not seeing anything immediately, although I need to run it on a larger set. There's no smoking gun so far though. Some of the speeds are a bit slow, but nothing low enough to explain the extremely low measured bandwidth these relays are getting. The current BW auth measurement results are around 1.0MBit/s for greendream848. I had a couple of measurements in the 300-500KBit/s range. So, if the auths heavily weight towards low individual measurements, things might make sense. Maybe one of the BW auth guys can comment on how the total measurement result is cooked up!?

2 1