- tor-relays - lists.torproject.org

BEREC draft duidelines on the implementation of the open Internet regulation
by Vasilis 16 Nov '19

16 Nov '19

Hi, For those of you that operate or administer relays in EU networks, this may be important for you to follow or/and provide comments on the draft. The Body of European Regulators for Electronic Communications (BEREC) has started a public consultation on the draft of BEREC guidelines on the implementation of the open Internet regulation, you can find more info here: https://berec.europa.eu/eng/document_register/subject_matter/berec/public_c… The public consultation is open until: 28 November 2019 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 0

Migrating to CentOS8
by Totor be 08 Nov '19

08 Nov '19

Hi folks I'm considering migrating my relays from CentOS 7 to CentOS 8 and upgrading tor from 0.3.5.8 to 0.4.1.6 One small VM relay at home is running the C8/0.4 setup and seems to be ok According to bodhi, this is supposed to be stable https://bodhi.fedoraproject.org/updates/?packages=tor Before migrating the others, I prefer to cross-check: is there anyone aware of issues with C8 and tor 0.4.x?? Thanks! <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

3 2

"large number of connections to other relays" - What should I do?
by Akarin 08 Nov '19

08 Nov '19

Hi I'm running a new non-exit relay on my server which has a shared address, and I often see the following message in my log file: Your relay has a very large number of connections to other relays. Is your outbound address the same as your relay address? Do I have to worry about that? If the answer is yes, what should I do?

2 1

The Onion Box v19.2: Dashboard to monitor Tor node operations
by theonionbox＠gmx.com 08 Nov '19

08 Nov '19

2 3

Tor stop / reboot by itself + weird logs (hacking?)
by David Strappazon 07 Nov '19

07 Nov '19

Hello everyone, i'm running a bridge on a raspberry Pi 3B+ on Kali Linux. Everything looks fine but after checking the logs i noticed that the service rebooted by itself in the middle on the night: Nov 06 03:51:09.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Nov 06 03:51:10.000 [notice] Delaying directory fetches: We are hibernating or shutting down. Nov 06 03:51:39.000 [notice] Clean shutdown finished. Exiting. etc... Then after that, it works again (will check tonight /tomorrow if it reboots again). I'm trying to find why it is rebooting but without success. I checked all logs possible and also notice this in journalctl -xe: nov. 06 19:37:58 kali-pi sshd[15920]: Failed password for root from XXXXX port 37494 ssh2 nov. 06 19:38:03 kali-pi sshd[15920]: Failed password for root from XXXX port 37494 ssh2 nov. 06 19:38:08 kali-pi sshd[15920]: Failed password for root from XXXXX port 37494 ssh2 nov. 06 19:38:13 kali-pi sshd[15920]: Failed password for root from XXXXX port 37494 ssh2 nov. 06 19:38:18 kali-pi sshd[15920]: Failed password for root from XXXXX port 37494 ssh2 nov. 06 19:38:18 kali-pi sshd[15920]: error: maximum authentication attempts exceeded for root from 21> nov. 06 19:38:18 kali-pi sshd[15920]: Disconnecting authenticating user root 2XXXX port 37494: > nov. 06 19:38:18 kali-pi sshd[15920]: PAM 5 more authentication failures; logname= uid=0 euid=0 tty=ss> nov. 06 19:38:18 kali-pi sshd[15920]: PAM service(sshd) ignoring max retries; 6 > 3 nov. 06 19:38:21 kali-pi sshd[15950]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid> nov. 06 19:38:22 kali-pi sshd[15953]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid> nov. 06 19:38:23 kali-pi sshd[15950]: Failed password for root from XXXX port 64786 ssh2 nov. 06 19:38:23 kali-pi sshd[15953]: Failed password for root from XXXXX port 6739 ssh2 There's two different IP that i don't know. A whois says it's a Chinese provider... Should i consider that someone is trying to break into my home network? Sent with [ProtonMail](https://protonmail.com) Secure Email.

3 2

Tor stopped suddenly - clock/time issue
by David Strappazon 06 Nov '19

06 Nov '19

Hi, while checking my (new)or not this is what i saw in notices.log Nov 05 05:18:57.000 [notice] Heartbeat: In the last 6 hours, I have seen 0 unique clients. Nov 05 10:44:17.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Nov 05 10:44:18.000 [notice] Delaying directory fetches: We are hibernating or shutting down. Nov 05 10:44:47.000 [notice] Clean shutdown finished. Exiting. Apr 11 18:28:44.000 [notice] Tor 0.4.1.6 opening log file. Apr 11 18:28:44.103 [notice] Tor 0.4.1.6 running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1d, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd 1.4.3. Apr 11 18:28:44.103 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning Apr 11 18:28:44.103 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc". Apr 11 18:28:44.103 [notice] Read configuration file "/etc/tor/torrc". Apr 11 18:28:44.125 [notice] Based on detected system memory, MaxMemInQueues is set to 694 MB. You can override this by setting MaxMemInQueues by hand. Apr 11 18:28:44.128 [notice] Opening Socks listener on 127.0.0.1:9050 Apr 11 18:28:44.128 [notice] Opened Socks listener on 127.0.0.1:9050 Apr 11 18:28:44.128 [notice] Opening OR listener on 0.0.0.0:4433 Apr 11 18:28:44.128 [notice] Opened OR listener on 0.0.0.0:4433 Apr 11 18:28:44.128 [notice] Opening Extended OR listener on 127.0.0.1:0 Apr 11 18:28:44.128 [notice] Extended OR listener listening on port 40247. Apr 11 18:28:44.128 [notice] Opened Extended OR listener on 127.0.0.1:40247 Apr 11 18:28:44.000 [notice] Bootstrapped 0% (starting): Starting Apr 11 18:28:44.000 [warn] Received local state file with skewed time (/var/lib/tor/state): It seems that our clock is behind by 207 days, 17 hours, 16 minutes, or that theirs is ahead. Tor requires an accurate clock to work: please check your time, timezone, and date settings. Apr 11 18:28:44.000 [warn] Problem bootstrapping. Stuck at 0% (starting): Starting. (Clock skew -17946963 in local state file from /var/lib/tor/state; CLOCK_SKEW; count 1; recommendation warn; host ? at ?) Nov 05 10:45:34.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip. Nov 05 10:45:35.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6. Nov 05 10:45:35.000 [notice] Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now. Nov 05 10:45:43.000 [notice] Your Tor server's identity key fingerprint is 'citizenfour B839503CA8F877D0263A38103DAF47EF302FBCF7' Nov 05 10:45:43.000 [notice] Your Tor bridge's hashed identity key fingerprint is 'citizenfour 9D1CCBE7EEF99FCCA6F767838FA08B23DDFABB3A' Nov 05 10:45:44.000 [warn] Our clock is 207 days, 16 hours, 31 minutes behind the time published in the consensus network status document (2019-11-05 09:00:00 UTC). Tor needs an accurate clock to work correctly. Please check your time and date settings! Nov 05 10:45:44.000 [warn] Received ns flavor consensus with skewed time (CONSENSUS): It seems that our clock is behind by 207 days, 16 hours, 31 minutes, or that theirs is ahead. Tor requires an accurate clock to work: please check your time, timezone, and date settings. Nov 05 10:45:44.000 [warn] Problem bootstrapping. Stuck at 0% (starting): Starting. (Clock skew -17944276 in ns flavor consensus from CONSENSUS; CLOCK_SKEW; count 2; recommendation warn; host ? at ?) Nov 05 10:45:45.000 [warn] Our clock is 207 days, 15 hours, 31 minutes behind the time published in the consensus network status document (2019-11-05 08:00:00 UTC). Tor needs an accurate clock to work correctly. Please check your time and date settings! Nov 05 10:45:45.000 [warn] Received microdesc flavor consensus with skewed time (CONSENSUS): It seems that our clock is behind by 207 days, 15 hours, 31 minutes, or that theirs is ahead. Tor requires an accurate clock to work: please check your time, timezone, and date settings. Nov 05 10:45:45.000 [warn] Problem bootstrapping. Stuck at 0% (starting): Starting. (Clock skew -17940676 in microdesc flavor consensus from CONSENSUS; CLOCK_SKEW; count 3; recommendation warn; host ? at ?) Nov 05 10:47:44.000 [notice] Starting with guard context "default" Nov 05 10:47:44.000 [notice] Signaled readiness to systemd Nov 05 10:47:44.000 [notice] Registered server transport 'obfs4' at '[::]:1234' Nov 05 10:47:45.000 [notice] Bootstrapped 5% (conn): Connecting to a relay Nov 05 10:47:45.000 [notice] Opening Socks listener on /run/tor/socks Nov 05 10:47:45.000 [notice] Opened Socks listener on /run/tor/socks Nov 05 10:47:45.000 [notice] Opening Control listener on /run/tor/control Nov 05 10:47:45.000 [notice] Opened Control listener on /run/tor/control Nov 05 10:47:45.000 [notice] Bootstrapped 10% (conn_done): Connected to a relay Nov 05 10:47:47.000 [notice] Bootstrapped 14% (handshake): Handshaking with a relay Nov 05 10:47:48.000 [notice] Bootstrapped 15% (handshake_done): Handshake with a relay done Nov 05 10:47:48.000 [notice] Bootstrapped 75% (enough_dirinfo): Loaded enough directory info to build circuits Nov 05 10:47:48.000 [notice] Bootstrapped 89% (ap_handshake): Finishing handshake with a relay to build circuits Nov 05 10:47:48.000 [notice] Bootstrapped 90% (ap_handshake_done): Handshake finished with a relay to build circuits Nov 05 10:47:48.000 [notice] Bootstrapped 95% (circuit_create): Establishing a Tor circuit Nov 05 10:47:48.000 [notice] Guessed our IP address as 78.224.250.217 (source: 213.220.220.60). Nov 05 10:47:51.000 [notice] Bootstrapped 100% (done): Done Nov 05 10:47:51.000 [notice] Now checking whether ORPort 78.224.250.217:4433 is reachable... (this may take up to 20 minutes -- look for log messages indicating success) Nov 05 10:47:51.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. Nov 05 10:47:53.000 [notice] Performing bandwidth self-test...done. Nov 05 13:12:01.000 [notice] New control connection opened. root@kali-pi:/var/log/tor# When i type date, everything look fine but when i first set up my raspberry Pi3b+ (os: Kali linux) i had a hard time getting the right time /timezone. It looks like at boot it takes like 30s to get the right time. Any idea how to fix this and avoid futur issue? Sent with [ProtonMail](https://protonmail.com) Secure Email.

3 3

Minimum traffic for a relay to be helpful to the network
by Keifer Bly 05 Nov '19

05 Nov '19

Hello list, So a while back, I was attempting to run a relay via Google Cloud, but had trouble finding an appropriate speed without having to spend a huge amount of money on outbound traffic. I am wondering what would be a good amount to dedicate to the relay while keeping it inexpensive to run: Here is Google Clouds pricing plans https://cloud.google.com/network-tiers/pricing It appears they charge a few cents a gigabyte, thx. --Keifer

3 2

Backup the Fingerprint
by Kolja Sagorski 04 Nov '19

04 Nov '19

Hello, can anyone help me to backup the fingerprint on debian10?

2 1

First time configuring a bridge - no log - doesnt work
by David Strappazon 03 Nov '19

03 Nov '19

Hi, I want to configure a tor obfs4 bridge on a raspberry pi 3B+. My system is Kali Linux. I followed this documentation: https://community.torproject.org/relay/setup/bridge/debian-ubuntu/ Actually, when i want to check the log in /var/log/tor, the folder is empty. TOr is running but nothing happens. here's my torrc file : RunAsDaemon 1 BridgeRelay 1 Log notice file /var/log/tor/notices.log Log debug file /var/log/tor/debug.log Log notice syslog Log debug stderr # Replace "TODO1" with a Tor port of your choice. This port must be externally # reachable. Avoid port 9001 because it's commonly associated with Tor and # censors may be scanning the Internet for this port. ORPort 4433 ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy # Replace "TODO2" with an obfs4 port of your choice. This port must be # externally reachable and must be different from the one specified for ORPort. # Avoid port 9001 because it's commonly associated with # Tor and censors may be scanning the Internet for this port. ServerTransportListenAddr obfs4 0.0.0.0:1234 # Local communication port between Tor and obfs4. Always set this to "auto". # "Ext" means "extended", not "external". Don't try to set a specific port number, nor listen on 0.0.0.0. ExtORPort auto # Replace "<address(a)email.com>" with your email address so we can contact you if there are problems with your bridge. # This is optional but encouraged. ContactInfo ################# # Pick a nickname that you like for your bridge. This is optional. Nickname RageAgainstTheMachine ExitPolicy reject *:* I've tried to check everything but i can't find why it doesn't work. Any help / advice would be appreciated. Sent with [ProtonMail](https://protonmail.com) Secure Email.

2 2

jumps of the amount of network connections
by Toralf Förster 03 Nov '19

03 Nov '19

I'm curious how to interpret the curves as seen in the attachment. The measurment were made at a stable fast relay in the past. -- Toralf

1 0