tor-relays

tor-relays@lists.torproject.org

36 participants
4815 discussions

Re: [tor-relays] New relay on dynamic IP address
by John Csuti 27 Jan '20

27 Jan '20

The stable flag refers to your fingerprint being up for long lived circuits. Being on a dynamic up won’t change that. So in principle the stable flag means that the server is up and reach able for most of the time no matter what the address or IP may be. Thanks, John Csuti > On Jan 26, 2020, at 11:37 PM, Jonathan Marquardt <mail(a)parckwart.de> wrote: >

1 0

Tor activities - FOSDEM and OFFDEM 2020
by gus 24 Jan '20

24 Jan '20

Hello folks, Tor Project is running some activities during FOSDEM and OFFDEM this year. We look forward to seeing you there! cheers, Gus ::FOSDEM:: - Tor Meetup Track: BOFs (Track A) Room: J.1.106, Saturday, 14:00 - 15:00 - State of the Onion: The Road to Mainstream Adoption and Improved Censorship Circumvention (Track: Internet) Room: Janson, Saturday, 17:00 - 17:50 - An Introduction to the Tor Ecosystem for Developers DI&P devroom, Sunday, 13:30 - 14:00 ::OFFDEM:: - Saturday morning, Ask Tor Anything: https://ps.zoethical.org/t/ask-tor-anything/3212/3 ::More info:: https://blog.torproject.org/tor-fosdem-2020-brussels https://trac.torproject.org/projects/tor/wiki/org/meetings/2020Brussels

1 0

ContactInfo-Information-Sharing-Specification updates and final comments until 2020-02-02
by nusenu 23 Jan '20

23 Jan '20

Hi, I made some updates to the ContactInfo Information Sharing Specification draft. Most notably I added a new field 'verifyurl' that should allow the automatic verification of the operatorurl claim. Without it anyone could claim to be part of some operator without the possibility of automated verification. You can get the current version on github: https://github.com/nusenu/ContactInfo-Information-Sharing-Specification/blo… Please send me your comments before 2020-02-02. I'm planing to tag a v1.0 in February 2020. After that I hope it sees some adoption by major operators so I can use your ContactInfo strings for automated verification and as input for malicious relay detection. thanks, nusenu -- https://mastodon.social/@nusenu https://twitter.com/nusenu

4 8

New Relay by the Chaos Computer Club Vienna (C3W)
by MacLemon 23 Jan '20

23 Jan '20

Hi! I just wanted to convey some happy news: The Chaos Computer Club Vienna[0] (C3W, Vienna/Austria) just launched their second relay. We're still working on tweaking the bandwidth announcements. Of course feedback to our relay setup is highly welcome and if you have questions, I'm happy to answer them. Feel free to poke around the metrics[1]. Best regards MacLemon [0]:https://c3w.at/ "Chaos Computer Club Vienna" [1]:https://metrics.torproject.org/rs.html#search/C3W "C3W Relay Overview, Tor Metrics"

2 1

bwauths don't like one of my relays?
by trusting.mcnulty＠protonmail.com 21 Jan '20

21 Jan '20

Hello, relatively new relay operator here. I originally started running a relay on a Scaleways/Online.net VPS that had extra capacity; saw the line in the Tor FAQ about how them+OVH+Hetzner own the vast majority of relay capacity; decided to hunt around for some other cheap VPS providers to give more capacity and diversity to the network. One of these relays, 'kima' (fingerprint 54A35E582F9E178542ECCFA48DBE14F401729969), is on ASN 11878, in a datacenter in Chicago, USA. It has plenty of bandwidth available to it -- iperf3 output between it, a public iperf3 server, and my two other relays is at the end of the mail. The summary is that I seem to have in excess of 100Mbps of bandwidth available. However the bwauths are consistently giving it poor scores, and as such I'm not seeing any traffic even after several days: faravahar: bw=88 moria1: bw=47 gabelmoo: bw=74 bastet: bw=2 longclaw: bw=1 The relay in question seems well-connected to the Internet, and is even relatively close to many of these bwauths: 7 hops and ~2ms away from faravahar, 12 hops and 25ms away from moria1, 10 hops and 52ms away from bastet... Is this a problem with my relay, or something fishy with the bwauth network? What can I do about this, if anything? Thanks! -Jimmy == iperf3 output: == Connecting to host iperf.he.net, port 5201 [ 5] local 107.152.35.167 port 44742 connected to 216.218.207.42 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 40.2 MBytes 337 Mbits/sec 0 5.80 MBytes [ 5] 1.00-2.00 sec 62.5 MBytes 524 Mbits/sec 0 5.80 MBytes [ 5] 2.00-3.00 sec 62.5 MBytes 524 Mbits/sec 0 5.80 MBytes [ 5] 3.00-4.00 sec 62.5 MBytes 524 Mbits/sec 0 5.80 MBytes [ 5] 4.00-5.00 sec 62.5 MBytes 524 Mbits/sec 0 5.80 MBytes [ 5] 5.00-6.00 sec 62.5 MBytes 524 Mbits/sec 0 5.80 MBytes [ 5] 6.00-7.00 sec 62.5 MBytes 524 Mbits/sec 0 5.80 MBytes [ 5] 7.00-8.00 sec 62.5 MBytes 524 Mbits/sec 0 5.80 MBytes [ 5] 8.00-9.00 sec 62.5 MBytes 524 Mbits/sec 0 5.80 MBytes [ 5] 9.00-10.00 sec 62.5 MBytes 524 Mbits/sec 0 5.80 MBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 603 MBytes 506 Mbits/sec 0 sender [ 5] 0.00-10.00 sec 603 MBytes 506 Mbits/sec receiver iperf Done. Connecting to host iperf.he.net, port 5201 Reverse mode, remote host iperf.he.net is sending [ 5] local 107.152.35.167 port 44746 connected to 216.218.207.42 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 16.8 MBytes 141 Mbits/sec [ 5] 1.00-2.00 sec 24.2 MBytes 203 Mbits/sec [ 5] 2.00-3.00 sec 26.9 MBytes 226 Mbits/sec [ 5] 3.00-4.00 sec 25.1 MBytes 210 Mbits/sec [ 5] 4.00-5.00 sec 21.3 MBytes 179 Mbits/sec [ 5] 5.00-6.00 sec 17.1 MBytes 144 Mbits/sec [ 5] 6.00-7.00 sec 17.0 MBytes 142 Mbits/sec [ 5] 7.00-8.00 sec 17.8 MBytes 149 Mbits/sec [ 5] 8.00-9.00 sec 18.4 MBytes 154 Mbits/sec [ 5] 9.00-10.00 sec 18.7 MBytes 157 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 210 MBytes 176 Mbits/sec 336 sender [ 5] 0.00-10.00 sec 203 MBytes 171 Mbits/sec receiver iperf Done. Connecting to host dangelo.nucleosynth.space, port 5201 [ 5] local 107.152.35.167 port 51112 connected to 185.234.72.43 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 6.80 MBytes 57.0 Mbits/sec 0 3.49 MBytes [ 5] 1.00-2.00 sec 28.8 MBytes 241 Mbits/sec 0 6.01 MBytes [ 5] 2.00-3.00 sec 27.5 MBytes 231 Mbits/sec 0 6.01 MBytes [ 5] 3.00-4.00 sec 28.8 MBytes 241 Mbits/sec 0 6.01 MBytes [ 5] 4.00-5.00 sec 28.8 MBytes 241 Mbits/sec 0 6.01 MBytes [ 5] 5.00-6.00 sec 27.5 MBytes 231 Mbits/sec 0 6.01 MBytes [ 5] 6.00-7.00 sec 27.5 MBytes 231 Mbits/sec 0 6.01 MBytes [ 5] 7.00-8.00 sec 30.0 MBytes 252 Mbits/sec 0 6.01 MBytes [ 5] 8.00-9.00 sec 27.5 MBytes 231 Mbits/sec 0 6.01 MBytes [ 5] 9.00-10.00 sec 27.5 MBytes 231 Mbits/sec 0 6.01 MBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 261 MBytes 219 Mbits/sec 0 sender [ 5] 0.00-10.11 sec 261 MBytes 216 Mbits/sec receiver iperf Done. Connecting to host dangelo.nucleosynth.space, port 5201 Reverse mode, remote host dangelo.nucleosynth.space is sending [ 5] local 107.152.35.167 port 51116 connected to 185.234.72.43 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 5.58 MBytes 46.8 Mbits/sec [ 5] 1.00-2.00 sec 17.6 MBytes 148 Mbits/sec [ 5] 2.00-3.00 sec 24.0 MBytes 202 Mbits/sec [ 5] 3.00-4.00 sec 29.2 MBytes 245 Mbits/sec [ 5] 4.00-5.00 sec 26.4 MBytes 222 Mbits/sec [ 5] 5.00-6.00 sec 29.1 MBytes 244 Mbits/sec [ 5] 6.00-7.00 sec 27.1 MBytes 227 Mbits/sec [ 5] 7.00-8.00 sec 28.2 MBytes 237 Mbits/sec [ 5] 8.00-9.00 sec 27.7 MBytes 233 Mbits/sec [ 5] 9.00-10.00 sec 27.8 MBytes 233 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.11 sec 246 MBytes 204 Mbits/sec 0 sender [ 5] 0.00-10.00 sec 243 MBytes 204 Mbits/sec receiver iperf Done. Connecting to host mcnulty.nucleosynth.space, port 5201 [ 5] local 107.152.35.167 port 48354 connected to 51.158.165.51 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 6.66 MBytes 55.8 Mbits/sec 0 3.54 MBytes [ 5] 1.00-2.00 sec 28.8 MBytes 241 Mbits/sec 0 6.03 MBytes [ 5] 2.00-3.00 sec 28.8 MBytes 241 Mbits/sec 0 6.03 MBytes [ 5] 3.00-4.00 sec 27.5 MBytes 231 Mbits/sec 0 6.03 MBytes [ 5] 4.00-5.00 sec 28.8 MBytes 241 Mbits/sec 0 6.03 MBytes [ 5] 5.00-6.00 sec 27.5 MBytes 231 Mbits/sec 0 6.03 MBytes [ 5] 6.00-7.00 sec 28.8 MBytes 241 Mbits/sec 0 6.03 MBytes [ 5] 7.00-8.00 sec 28.8 MBytes 241 Mbits/sec 0 6.03 MBytes [ 5] 8.00-9.00 sec 28.8 MBytes 241 Mbits/sec 0 6.03 MBytes [ 5] 9.00-10.00 sec 27.5 MBytes 231 Mbits/sec 0 6.03 MBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 262 MBytes 219 Mbits/sec 0 sender [ 5] 0.00-10.10 sec 261 MBytes 217 Mbits/sec receiver iperf Done. Connecting to host mcnulty.nucleosynth.space, port 5201 Reverse mode, remote host mcnulty.nucleosynth.space is sending [ 5] local 107.152.35.167 port 48358 connected to 51.158.165.51 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 5.25 MBytes 44.0 Mbits/sec [ 5] 1.00-2.00 sec 11.8 MBytes 98.6 Mbits/sec [ 5] 2.00-3.00 sec 13.2 MBytes 111 Mbits/sec [ 5] 3.00-4.00 sec 9.09 MBytes 76.3 Mbits/sec [ 5] 4.00-5.00 sec 7.99 MBytes 67.0 Mbits/sec [ 5] 5.00-6.00 sec 7.68 MBytes 64.5 Mbits/sec [ 5] 6.00-7.00 sec 8.18 MBytes 68.6 Mbits/sec [ 5] 7.00-8.00 sec 8.74 MBytes 73.3 Mbits/sec [ 5] 8.00-9.00 sec 8.22 MBytes 69.0 Mbits/sec [ 5] 9.00-10.00 sec 8.26 MBytes 69.3 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.10 sec 91.1 MBytes 75.6 Mbits/sec 633 sender [ 5] 0.00-10.00 sec 88.4 MBytes 74.1 Mbits/sec receiver iperf Done.

2 2

TCP CCA for Tor Relays (and especially Bridges)
by Matt Corallo 20 Jan '20

20 Jan '20

I’m sure this exists somewhere so this is more of a request-for-links, but what’s the current thinking on TCP CCA selection for Tor relays? While it has fairness issues (and reported long-tail issues for higher-latency links, though I can’t find good in-practice analysis of this), BBA should handle random packet loss much better than, eg, Cubic. This is likely less of an issue for western users, but many other parts of the world (especially China) see much higher packet loss due to regularly-overloaded links. I presume it is not good practice to change the default CCA for relays/bridges, but it seems BBA/BBAv2 would be a worthwhile experiment to see if it improves the browsing experience for non-western tor users. Matt

5 7

Relay with odd behavior
by Clément Février 15 Jan '20

15 Jan '20

Hi, I am running a tor relay on Ubuntu 18.04 in a LXD container. After upgrading form tor version 0.4.2.5-1~bionic+1 over 0.4.1.6-1~bionic+1, my relay is having an odd behavior. My relay is running for 9 days and the number of connections dropped from from ~5000 with 0.4.1.6-1 to 9 or less with 0.4.2.5-1. In addition, my relay does not appear anymore on https://metrics.torproject.org The fingerprint is 33D88F331408141F2A2CC563239E54E48F7A211B IPs are 151.127.52.79 and 2001:41d0:fecf:8900:216:3eff:fe8a:e4a6 Regards, Clément

2 1

Can anyone help with this issue?
by John Csuti 15 Jan '20

15 Jan '20

$ sudo apt update Hit:1 http://us.archive.ubuntu.com/ubuntu xenial InRelease Hit:2 http://us.archive.ubuntu.com/ubuntu xenial-updates InRelease Hit:3 http://us.archive.ubuntu.com/ubuntu xenial-backports InRelease Hit:4 http://security.ubuntu.com/ubuntu xenial-security InRelease Ign:5 http://download.webmin.com/download/repository sarge InRelease Ign:6 https://deb.torproject.org/torproject.org xenial InRelease Hit:7 http://download.webmin.com/download/repository sarge Release Err:8 https://deb.torproject.org/torproject.org xenial Release server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none Reading package lists... Done E: The repository 'https://deb.torproject.org/torproject.org xenial Release' does not have a Release file. N: Updating from such a repository can't be done securely, and is therefore disabled by default. N: See apt-secure(8) manpage for repository creation and user configuration details. $ date Mon Jan 6 04:32:36 EST 2020 I have fixed this before but I am not sure how I did it :( --John

6 7

[Event] Tor relays operators meetup, 08/11/2019 @ Mundo B, Brussels
by Vasilis 15 Jan '20

15 Jan '20

Dear Tor friends and relay operators, On Friday 8th of November 2019, a Tor relay operators meetup will take place at Mundo B in Belgium. When: Friday, November 8th, 2019 Time: 18:00 (6:00 PM) Where: Mundo B, Rue d'Edimbourg 26, Brussels, Belgium (in a room upstairs) OSM: https://www.openstreetmap.org/way/139078492#map=17/50.83787/4.36425 Event link: https://blog.torproject.org/events/tor-meetup-brussels Hope to see many of you there. Cheers, ~Vasilis -- Fingerprint: 8FD5 CF5F 39FC 03EB B382 7470 5FBF 70B1 D126 0162 Public key: https://keys.openpgp.org/vks/v1/by-fingerprint/8FD5CF5F39FC03EBB38274705FBF…

1 1

Fallback Relay address Changed :-(
by jan＠wth.in 15 Jan '20

15 Jan '20

Hi Guys, I moved my two relays to a new location and was not able to keep them on the same IP address. Which is quite unfortunate, since on of the was a fallback relay. https://metrics.torproject.org/rs.html#details/50586E25BE067FD1F739998550ED… https://metrics.torproject.org/rs.html#details/40C773D9F2B16143CDB2ADB661DD… I am not planing to move again within the next decade. So feel free to add the new address to the fallback list. Old address 212.51.134.123 new address 212.51.149.23. Have a nice day, Jan

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-relays