September 2019 - tor-relays - lists.torproject.org

Operator straw poll: Reasons why you use Tor LTS versions?
by Mike Perry 21 Oct '19

21 Oct '19

Hello relay operators, Thanks for running relays, and thanks to those of you who are moving off of our old EOL Tor versions. Thanks especially to those of you who moved directly to Tor 0.4.1! We would like to transition the LTS Tor to be for use in edge/client/non-relay infrastructure only. We would like to minimize even that use. We need to update our network protocols to improve performance, security, and to add defenses against DoS attacks. Doing this while supporting LTS for relays is expensive, especially when large backports must be done to keep the network safe. It also slows down the uniform deployment of performance improvements, which contributes to the frustrating user experience of abysmal-but-rare performance edge cases. Unfortunately, we still have something like 2500 relays on either Tor 0.2.9-LTS or Tor 0.3.5-LTS. What are the reasons for this? My guess is the top 5 most common responses are: 1. "I didn't know that Debian's backports repo has latest-stable Tor!" 2. "I didn't see the Tor Project repos mentioned in Tor's Relay docs!" 3. "I'm running a distribution that Tor Project doesn't have repos for." 4. "I rolled my own custom Tor from git and forgot about it." 5. "My relay machine was not getting any updates at all. Oops." Does anyone have a reason that they think many other relay operators also share? How can we fix that for you, or at least, how can we make it easier to run the very latest stable series Tor on your relay? -- Mike Perry

10 17

Bridge Sees 100x Clients Starting 2019-08-31
by Porcelain Mouse 09 Oct '19

09 Oct '19

Tor Operators, It's been about a year since I switched my middle node to a bridge. Since then, usage on that node has increased and I have the bandwidth for it, so that's good. But, 16 days ago, this node started moving a lot more data, hitting the bandwidth limits, constantly. And its serving many more clients, more than 100 times the recent average. On this list, I see some messages regarding SSH abuse traffic using Tor. I also see a call from Phillip W. about more obfs4 bridges. 1) Can we be pretty sure the bulk of this sudden increase in users is abuse traffic? If not, is this a problem? 2) What should I do about it, if anything? 3) Would using obfuscation help this problem? Thanks, -- PMouse

4 6

Questions to ask exit node providers
by F67 Group 08 Oct '19

08 Oct '19

We are thinking of running a Tor Exit Node. Does anybody have a list of questions to ask before purchasing a VPS or colocation? I came up with some basic questions: - Do you allow a Tor exit node? [with explanation] - What are the policies for handling abuse complaints? - How much uplink bandwidth do you provide? Any other questions one should ask? Thanks.

17 49

No connections to bridge
by skarz 02 Oct '19

02 Oct '19

I set up a bridge at home on my Raspberry Pi (Raspbian Buster) using [these instructions](https://community.torproject.org/relay/setup/bridge/), and I believe everything is configured correctly... But there is no activity in or out of my bridge. Here's some messages I am seeing: > 16:31:26 [NOTICE] Heartbeat: In the last 6 hours, I have seen 0 unique clients. [2 duplicates hidden] > 16:31:26 [NOTICE] Heartbeat: Tor's uptime is 17:59 hours, with 0 circuits open. I've sent 6.18 MB and received 25.58 MB. [2 duplicates hidden] > 16:04:28 [NOTICE] Performing bandwidth self-test...done. > 13:10:43 [NOTICE] No circuits are opened. Relaxed timeout for circuit 408 (a Testing circuit 3-hop circuit in state doing handshakes with channel state open) to 60000ms. However, it appears the circuit has timed out I know bridges don't see as much activity but is this abnormal?

3 2

Re: [tor-relays] Bridge - how to configure obfs4 both: on IPv4 AND IPv6?
by Roger Dingledine 29 Sep '19

29 Sep '19

On Sat, Sep 28, 2019 at 08:12:43PM +0200, tschador(a)posteo.de wrote: > But with: > > ServerTransportListenAddr obfs4 <ipv4-addr>:<port> > ServerTransportListenAddr obfs4 [<ipv6-addr>]:<port> > > obfs4proxy is only listening on the IPv4 address! It looks like you are encountering https://bugs.torproject.org/11211 Alas, I suggest sticking to ipv4 for now -- I think if you got ipv6 working on your obfs4, you would next run into the problem that bridgedb doesn't currently give out ipv6 obfs4 addresses. There's a lot of work waiting for somebody who wants to make ipv6 more of a proper citizen in the Tor world. There's a mention by Sarah of a recent funding proposal which could get that restarted again: https://lists.torproject.org/pipermail/tor-project/2019-September/002479.ht… Thanks for running a bridge! --Roger

2 1

Re: [tor-relays] My relay is listed offline, but it isn't!
by niftybunny 26 Sep '19

26 Sep '19

$ traceroute6 2a01:4f8:1c0c:45f7::1 connect: No route to host > On 25. Sep 2019, at 17:24, tschador(a)posteo.de wrote: > > Hi, > > after upgrading to Tor version 0.4.1.6-1~d9.stretch+1 and kernel > 4.9.0-11-amd64 on Debian GNU/Linux 9 my relay ist listed as offline. [1] > > I restarted Tor several times, but no change. The log shows (CEST): > --- > Sep 25 13:10:29.000 [notice] Tor 0.4.1.6 opening log file. > Sep 25 13:10:29.432 [notice] Tor 0.4.1.6 running on Linux with Libevent > 2.0.21-stable, OpenSSL 1.1.0k, Zlib 1.2.8, Liblzma 5.2.2, and Libzstd 1.1.2. > … > Sep 25 13:10:33.000 [notice] Self-testing indicates your ORPort is > reachable from the outside. Excellent. > … > Sep 25 13:11:35.000 [notice] Self-testing indicates your DirPort is > reachable from the outside. Excellent. Publishing server descriptor. > Sep 25 13:11:35.000 [notice] Performing bandwidth self-test...done. > --- > > There are still 150 connects in the moment, slowly decreasing. > > Only two of the authorities show the 'running'-flag for my relay. What's > going on there? > > Regards > > [1] > https://metrics.torproject.org/rs.html#details/6A7551EEE18F78A9813096E82BF8… > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

2 1

Re: [tor-relays] My relay is listed offline, but it isn't!
by Roger Dingledine 25 Sep '19

25 Sep '19

On Wed, Sep 25, 2019 at 05:24:55PM +0200, tschador(a)posteo.de wrote: > after upgrading to Tor version 0.4.1.6-1~d9.stretch+1 and kernel > 4.9.0-11-amd64 on Debian GNU/Linux 9 my relay ist listed as offline. [1] > > Only two of the authorities show the 'running'-flag for my relay. What's > going on there? > > [1] > https://metrics.torproject.org/rs.html#details/6A7551EEE18F78A9813096E82BF8… My guess is that your ipv4 ORPort is reachable, but that your ipv6 ORPort is not reachable. So you're getting Running votes from the dir auths that don't test ipv6, and the ones that do test ipv6 are declaring you down. For those following at home, if you're in this situation, another useful tool is to go to the search box at the bottom of https://consensus-health.torproject.org/#relayinfo and paste in your fingerprint, to learn more about the individual votes from each directory authority about your relay. Thanks! --Roger

1 0

Measuring the Accuracy of Tor Relays' Advertised Bandwidths
by Rob Jansen 23 Sep '19

23 Sep '19

Hello relay operators! I am planning on performing an experiment on the Tor network to try to gauge the accuracy of the advertised bandwidths that relays report in their server descriptors. Briefly, the experiment involves running a speed test on every relay for a short time (about 20 seconds). Details follow. I plan to run the experiment in about 1 week. Relay operators can opt-out of the speed test by replying on this thread, and we will remove you from the list of relays to scan. Peace, love, and positivity, Rob --- Measuring the Accuracy of Tor Relays' Advertised Bandwidths Motivation ---------- The capacity of Tor relays (maximum available goodput) is an important metric. Combined with mean goodput, it allows us to compute the bandwidth utilization of individual relays as well as the entire network in aggregate. Generally, capacity is used to help balance client load across relays, and relay utilization rates help Tor make informed decisions about how to allocate resources and prioritize performance and scalability improvements. Problem ------- Currently, Tor uses a heuristic measure of unknown accuracy to estimate Tor relay capacity. Each relay keeps track of the maximum goodput it has achieved over any 10 second window in a 24 hour period. This is called the "observed bandwidth". Relays take the minimum of their "observed bandwidth" and their bandwidth rate-limiting configuration and reports the result as the "advertised bandwidth" in their server descriptors. We do not know how well the advertised bandwidth estimates the true relay capacity, but we do know that it represents a lower bound on capacity. Hypothesis ---------- The advertised bandwidth significantly underestimates the true capacity of Tor relays. On average, relays with higher true capacities will be more strongly correlated with capacity underestimation (because it will be less likely that fast relays will have sustained their full capacity over a 10 second period). Experiment ---------- A relay reports its advertised bandwidth in its server descriptor. To test how well these reported numbers represent the true capacity of a relay, we can manually perform a speed test on the relay by initiating the simultaneous download of several large data streams for a period that exceeds 10 seconds. In the report following our test, the relay will report its advertised bandwidth in its server descriptor and the results will be collected and reported by metrics.torproject.org. The experiment involves two steps: running the speed test on a relay under our control, and running the speed test on all relays in Tor network. We will first run the speed test on at least one relay that we control, in order to test that the method is effective and that we can in fact observe a change in the advertised bandwidth reported on metrics.torproject.org. Once we have confidence that our speed test is functioning correctly, and that the metrics pipeline will allow us to gather the results, we will repeat it on all relays in the network. We will conduct the speed tests while minimizing network overhead. We will use a custom client that builds 2-relay circuits. The first relay will be the target relay we are speed testing, and the second relay will be a fast exit relay that we control. We will initiate data streams between a speedtest client and server running on the same machine as our exit relay. The setup will look like: speedtest-client <--> tor-client <--> target-relay <--> exit-relay <--> speedtest-server All components will run on the same machine that we control except for the target-relay, which will rotate as we test different relays in the network. For each target relay, we plan to run the speedtest for 20 seconds in order to increase the probability that the 10 second mean goodput will reach the true capacity. We will measure each relay over a few days to ensure that our speedtest effects are reported by every relay. Although we believe that the overhead of this speed test is in line with regular usage, relay operators can opt-out of the speed test by replying on this thread. Those that opt out will be removed from our list of relays to scan. Analysis -------- Following our speedtest, we will analyze the data collected and reported by Tor metrics. We will compared the advertised bandwidth that each relay reports before our experiment to those reported during our experiment. This will help us test our hypothesis that relays' advertised bandwidth underestimates the true capacity of relays. We will run a statistical correlation analysis on the data to test the strength of the correlation between the previously reported (estimated) relay capacity and relay capacity underestimation. We will report our results to the Tor community. We expect that the results of our experiment will help Tor decide how to allocate resources and will help them plan and prioritize performance improvements. It will also provide insight into the operation of the current load balancing system, which uses advertised bandwidth to produce consensus weights.

12 37

Bridge stats always in multiples of 8
by nottryingtobelame＠protonmail.com 23 Sep '19

23 Sep '19

I'm just curious as to why, in the bridge stats, all the country codes show a multiple of 8. Thanks for your time!

2 1

tor
by armik900＠gmail.com 18 Sep '19

18 Sep '19

hi,what are these relay operators with the same nickname (snap269) but from different countries the vast majority of relays are outdated and do not work С уважением, Станислав

3 2