tor-relays

tor-relays@lists.torproject.org

42 participants
4821 discussions

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

Advices about Tor Network in general...
by Hugo Claude 08 Jan '20

08 Jan '20

Hello everyone, I've became recently engaged agaisnt Mass surveillance program. So I'm currently running my RPi 3B+ as a Tor Relay on my home network and i wanted to know multiple things which was unclear for me. 1. Is it possible to choose my relay as my guard relay while i'm using Tor Network ? 2. Why my relay is running on 4.1.5 while some are 4.2.5 ect... ? 3. How can i make a kind of proxy to make my entire traffic passing through Tor (like Orbot on mobile phone). 4. What kind of low-budget servers (-100€), i can buy for running ≈12MB/s Relays ? Sincerely Yours, Hugo.

3 2

%include in torrc
by ylms 08 Jan '20

08 Jan '20

Hello Is arm supposed to complain about the line with the %include as "The torrc differs from what tor's using. You can issue a sighup to reload the torrc values....". It also complains, that the ExitPolicy, which is now in an %include file, is missing. So that seems to be bogus. Tor 0.4.2.5 in this particular case. Thanks yl

4 4

Tor Organizations Meetup during 36c3 in Leipzig (Germany)
by ml-torrelays＠artikel5ev.de 07 Jan '20

07 Jan '20

Hello everyone, during the 36c3 we organized a Tor Assembly, same as in 2017/2018. The 36c3 is the annual congress of the Germany CCC (Chaos Computer Club), which is a gathering of 17.000 people of the hacking community. I has grown a lot and people from all over the world are attending. We also had two sessions, one was a relay operator meetup with FAQ and a presentation [1] of "Foundation of Applied Privacy" about their Exits. The other session was a Tor organizations meetup. During the organizations meetup some notes were taken and it was agreed to share those afterwards. [1] https://appliedprivacy.net/presentations/ The following topics were discussed: + Concentration of Tor exit capacity in unique entities, how much of the Tor (exit) capacity should be in control of one group or person? ++ This is a recurring discussion, various people have suggested limits between 5% and 10% exit probability. ++ Frënn vun der Ënn are working on a "Tor Organization Code of Conduct" including such a self-limitation - This was only mentioned by some participants and is not first hand information. + Professionalization of operation and administration, challenges in finding/keeping volunteers. ++ One organization is running on "grown" infrastructure that is administrated by Perl scripts, which new volunteers are having difficulties working with. ++ Sharing documentation/code used by various organizations might be a solution, this has also been asked for at the Tor Relay Operator Meetup. + Why are people scared of abuse? What problem does a hosting provider face if abuse happens/is not stopped? ++ At least for most servers rented from ISPs, if you don't react to abuse email in a timely manner, they will disconnect you. ++ On a higher level, there seems to be a risk for ASNs with too much unchecked abuse. + Procurement of hardware ++ One organization mentioned CPU load issues if they allow port 22 exit traffic. Better hardware might help them. ++ If you can donate relatively modern server hardware to Tor organization, please consider mentioning this on tor-relays mailing list. + Handing over the administration of Torservers.net has not progressed very much. ++ Original post: https://lists.torproject.org/pipermail/tor-relays/2019-May/017269.html ++ One problem could be a lack of information about the type and amount of work that needs to be done. ++ Handling press inquiries has been taken over by a group of other organizations, seems to be working well. + IPv6 ++ Some major Tor exit operator might loose their IPv4 space within the next 2-3 years, which makes progress in the IPv6 area crucial for them to continue contributing to the network. ++ The Tor Project got IPv6 funding from RIPE NCC, but in addition to the software portion (Tor Project responsibility) also operators need to take action and ensure they have IPv6 connectivity enabled on their systems. + BGP Routing Security ++ BGPalerter is an easy to use tool to monitor your ASN for hijacking attempts and visibility issues nitor your ASN for hijacking attempts and visibility issues https://github.com/nttgin/BGPalerter + Future meetings ++ Some organizations wish to be invited to the Tor meetings. People of some organizations attend the meetings aready through other means. The meetup took 90 minutes, in the end it was decided to organize a meetup like this each year. Quarterly mumble meetings are to be held. Some of the organizations present (in alphabetical order) were: Artikel10 - https://artikel10.org/ Artikel 5 e.V. - https://www.artikel5ev.de/ Digitalcourage - https://digitalcourage.de/en Digitale Gesellschaft - https://www.digitale-gesellschaft.ch/ Emerald Onion - https://emeraldonion.org/meraldonion.org/meraldonion.org/meraldonion.org/me… F3 Netze - https://f3netze.de/ Foundation for Applied Privacy - https://applied-privacy.net/ Nos Oignons - https://nos-oignons.net/ Zwiebelfreunde - https://www.zwiebelfreunde.de/ This text was composed in a pad by various people, the license of the text is CC-BY-SA 3.0, original text can be found here: https://cryptpad.fr/pad/#/2/pad/edit/eMjLydN6sIQSMbHwNwzIUHDL/ // End of protocol I hope there is no information missing, I shared the pad and some people were working on the text in the last 3 days, please feel free to discuss the topics mentioned and also feel free to add information missing. -- utzer Twitter: @utzer mailto:info@artikel5ev.de

6 9

tor crash on HUP only when SANDBOX is 1
by tor-relay＠riseup.net 06 Jan '20

06 Jan '20

Hi, I'm running an exit relay on a Debian Buster. I installed libseccomp and I've built tor 0.4.2.5 using debuild, like the wiki says. Today I noticed that tor crashes on HUP signal, only when the Sandbox option is on. I never had this problem. This is what my log says: an 05 08:23:10.000 [notice] Received reload signal (hup). Reloading config and resetting internal state. Jan 05 08:23:10.000 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc". Jan 05 08:23:10.000 [notice] Read configuration file "/etc/tor/torrc". Jan 05 08:23:10.000 [notice] Tor 0.4.2.5 opening log file. ============================================================ T= 1578205390 (Sandbox) Caught a bad syscall attempt (syscall dup) /usr/bin/tor(+0x1fc9fa)[0x561d896b29fa] /lib/x86_64-linux-gnu/libc.so.6(dup+0x7)[0x7f0bebf4bbc7] /lib/x86_64-linux-gnu/libc.so.6(dup+0x7)[0x7f0bebf4bbc7] /usr/bin/tor(tor_log_update_sigsafe_err_fds+0x18b)[0x561d896c699b] /usr/bin/tor(set_options+0x3c0)[0x561d89642f80] /usr/bin/tor(options_init_from_string+0x17d)[0x561d896453dd] /usr/bin/tor(options_init_from_torrc+0x404)[0x561d89645a74] /usr/bin/tor(+0x5f961)[0x561d89515961] /usr/lib/x86_64-linux-gnu/libevent-2.1.so.6(+0x22a6c)[0x7f0bec5a3a6c] /usr/lib/x86_64-linux-gnu/libevent-2.1.so.6(event_base_loop+0x5a7)[0x7f0bec5a4537] /usr/bin/tor(do_main_loop+0xff)[0x561d8952a3af] /usr/bin/tor(tor_run_main+0x1105)[0x561d89517d55] /usr/bin/tor(tor_main+0x3a)[0x561d8951523a] /usr/bin/tor(main+0x19)[0x561d89514df9] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb)[0x7f0bebe8509b] /usr/bin/tor(_start+0x2a)[0x561d89514e4a] I'm telling you because i think it could be a bug, but I'm not sure that It's not caused by something else. At the moment I've disabled Sandbox. Please, let me know if I can fix this in some way, thanks.

4 5

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-relays