- tor-relays - lists.torproject.org

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

26 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 24 Sep '19

24 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

Sudden bridge activity from Russia and Iran, strange?
by nottryingtobelame＠protonmail.com 18 Sep '19

18 Sep '19

Hello, my new bridge sat for a few weeks with 0 clients. I understand it takes time to begin seeing clients, but all of a sudden within the span of one 6-hour heartbeat period, I picked up 346 clients. Since then, it has been 20-50 every 6 hours. But when I pull the bridge-stats file, it shows 104 from Iran, and 64 from Russia. These two are the overwhelming majority of my clients; all the other countries each have 8. Is this normal, or suspicious?

2 1

SSH scanning on TOR Exit - Nerfing Rules
by AMuse 16 Sep '19

16 Sep '19

Hi all! I'm curious what y'all think of this situation. I have SSH open as an exit port on a TOR exit that my friends and I are maintaining - and of course it's the #1 offender by far in automated abuse notifications we get from our ISP, from peoples' fail2ban servers sending abuse emails. This all seems like a huge waste of time, but that's a separate issue. I'm wondering if nerfing outbound SSH to rate limit will be effective at getting the SSH scanning bots to stop using my exit in their circuit, while leaving SSH open for actual humans who need to SSH while using TOR. I've implemented, as a test, rate limiting outbound on the SSH port. What do you think the impact of this will be? No impact? Losing exit status because connections on SSH die? Something else entirely? Here's the pf rules in question: pass in on $ext_if proto {tcp udp} from any to any port 9000:9150 keep state pass in on $ext_if proto tcp from any to any port 22 keep state pass in on $ext_if proto tcp from any to any port 80 keep state pass out on $ext_if from any to any keep state pass out on $ext_if proto tcp from any to any port 22 keep state (max-src-conn 25, max-src-conn-rate 1/5 )

3 2

Re: [tor-relays] Short Research Survey
by entensaison＠use.startmail.com 13 Sep '19

13 Sep '19

Hi! Most online surveys ask the participants to confirm that their replies can be used after the last question of the survey. I would recommend you to do that, too. Sometimes people give random answers because they are curious about the survey's questions. ;-) > Dear Tor relay operators, > > We are a team of researchers at MIT, and we would like to ask Tor relay > operators to participate in a short and anonymous survey (no personal > information or IP address collected). This study is focused on the > importance of providing anonymity by volunteers in various contexts, > and will take no more than 5-10 minutes to finish. > > You can learn more and take the survey at this link: https://mit.co1.qualtrics.com/jfe/form/SV_6W3YXSCnqMVGPs1 > > Your input is very valuable to our study, and we look forward to your > feedback. > > Please feel free to email us at anon-research(a)mit.edu if you have any > questions. > > (Our survey platform unfortunately uses JavaScript. We apologize for > being unable to switch it off. We would be grateful for your > participation if you are comfortable taking the survey.)

1 0

Running on a Raspberry Pi
by William Denton 13 Sep '19

13 Sep '19

I'm reconfiguring things and decided to move a relay from an old laptop to a Raspberry Pi. I tried it on a Pi Zero W, which is very cheap but also pretty slow, and it just didn't work. Now I'm trying it on a Pi Four (which has four CPUs and two gigs of RAM) and so far it's working, though it's not moving as much traffic as on the laptop. There I was doing about 25 gigs a day, and so far now I'm doing about four or five with the same configuration. Anyone else running a relay on a Pi? It's cheap and pretty easy to set up, even if it turns out not to be an enormous contribution to the network. Bill -- William Denton :: Toronto, Canada --- Listening to Art: https://listeningtoart.org/ https://www.miskatonic.org/ --- GHG.EARTH: http://ghg.earth/ Caveat lector. --- STAPLR: http://staplr.org/

5 5

Re: [tor-relays] Running on a Raspberry Pi
by nottryingtobelame＠protonmail.com 13 Sep '19

13 Sep '19

If you're having any heat issues with the Pi 4, may I suggest the aluminum heatsink case from flirc.tv? It took my average temps down about 10°C. Beautiful case, great price for what it does. -------- Original Message -------- On Sep 13, 2019, 8:00 AM, wrote: > Send tor-relays mailing list submissions to > tor-relays(a)lists.torproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > or, via email, send a message with subject or body 'help' to > tor-relays-request(a)lists.torproject.org > > You can reach the person managing the list at > tor-relays-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-relays digest..." > > Today's Topics: > > 1. Re: Running on a Raspberry Pi (William Denton) > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 12 Sep 2019 19:50:22 -0400 (EDT) > From: William Denton <wtd(a)pobox.com> > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] Running on a Raspberry Pi > Message-ID: <alpine.DEB.2.02.1909121945030.14928(a)shell.miskatonic.org> > Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII > > On 10 September 2019, ronqtorrelays(a)risley.net wrote: > >> From what I have read about the Pi 4, heat is a big issue. If you're not doing >> something to cool it, your CPU speed is likely being throttled due to >> overheating. > > I'm not doing any cooling except for not having it in case. I'm in Canada, and > with winter coming I can leave it hanging inside a window, and that'll cool it > down some. > > The speed on the relay has picked up to about a quarter of what it was (so about > six gigs a day), and I'll wait and see if it continues to increase, and then > maybe fiddle with the config. > > So, if a Pi is cheap to buy and easy to use and maintain, I'm happy to use it > for a relay, even if it's not a major contributor to the network. > > Bill > -- > William Denton :: Toronto, Canada --- Listening to Art: https://listeningtoart.org/ > https://www.miskatonic.org/ --- GHG.EARTH: http://ghg.earth/ > Caveat lector. --- STAPLR: http://staplr.org/ > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > ------------------------------ > > End of tor-relays Digest, Vol 104, Issue 15 > *******************************************

1 0

ORPort
by Anonforpeace 12 Sep '19

12 Sep '19

Hello: Hope someone can help me. I'm trying to configure a bridge and I've followed all the instructions and I've chosen several ports and none of them are reachable. I've used the test site that Tor lists on its site. "Your server has not managed to confirm that your its ORPort is reachable." Each port I list on the test site says unreachable. What am I missing? The instructions are pretty straightforward. Thanks

4 6