- tor-relays - lists.torproject.org

Tor 0.3.1.7 - bug report
by diffusae 21 Oct '17

21 Oct '17

This instance is running forward. Oct 21 00:44:20.989 [notice] Tor 0.3.1.7 (git-6babd3d9ba9318b3) running on FreeBSD with Libevent 2.1.8-stable, OpenSSL 1.0.2j-freebsd, Zlib 1.2.8, Liblzma 5.2.2, and Libzstd 1.3.2. Oct 21 01:08:34.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. Oct 21 01:08:47.000 [notice] Performing bandwidth self-test...done. Oct 21 01:09:10.000 [warn] tor_bug_occurred_: Bug: src/common/compress.c:576: tor_compress_process: Non-fatal assertion !((rv == TOR_COMPRESS_OK) && *in_len == in_len_orig && *out_len == out_len_orig) failed. (on Tor 0.3.1.7 6babd3d9ba9318b3) Oct 21 01:09:10.000 [warn] Bug: Non-fatal assertion !((rv == TOR_COMPRESS_OK) && *in_len == in_len_orig && *out_len == out_len_orig) failed in tor_compress_process at src/common/compress.c:576. Stack trace: (on Tor 0.3.1.7 6babd3d9ba9318b3) Oct 21 01:09:10.000 [warn] Bug: Unable to generate backtrace. (on Tor 0.3.1.7 6babd3d9ba9318b3) Regards, --

2 2

"Removed 1565259696 bytes by killing 1 circuits"
by tor 21 Oct '17

21 Oct '17

In a relay's logs: Oct 20 10:31:47 XXXXX Tor[YYYY]: We're low on memory. Killing circuits with over-long queues. (This behavior is controlled by MaxMemInQueues.) Oct 20 10:32:11 XXXXX Tor[YYYY]: Removed 1565259696 bytes by killing 1 circuits; 40008 circuits remain alive. Also killed 0 non-linked directory connections. Tor removed ~ 1565 MB by killing 1 circuit? Seems like that can't be right? Earlier in the log I see "Based on detected system memory, MaxMemInQueues is set to 1500 MB." So either it's dumping the entire queue here, or the output is misleading. Or perhaps I don't understand how it works. It doesn't seem to be impactful; I'm just curious what's going on.

3 4

AccountingMax 48 GBytes is not working
by Artur Pędziwilk 20 Oct '17

20 Oct '17

Hi Tor operators, I have relay with AccountingMax 48 GBytes AccountingStart day 09:00 MaxMemInQueues 512 ServerTransportPlugin obfs4 exec /usr/local/bin/obfs4proxy managed The accounting seems stopped working since upgrade to tor-0.3.0.10 or enabling obfs4proxy. I am not fully sure, what do you think? https://atlas.torproject.org/#details/DFBF5EA4F70DC6639156BB71593F2A2E8FDA8… Oct 16 09:00:00 venator Tor[3519]: Configured hibernation. This interval began at 2017-10-16 09:00:00; the scheduled wake-up time was 2017-10-16 09:00:00; we expect to exhaust our quota for this interval around 2017-10-17 09:00:00; the next interval begins at 2017-10-17 09:00:00 (all times local) Oct 16 09:00:00 venator Tor[3519]: Hibernation period ended. Resuming normal activity. Oct 16 09:00:00 venator Tor[3519]: Opening Directory listener on 45.76.39.74:8080 Oct 16 09:00:00 venator Tor[3519]: Opening OR listener on 45.76.39.74:9090 Oct 16 09:00:00 venator Tor[3519]: Opening Extended OR listener on 45.76.39.74:46396 Oct 16 09:46:11 venator Tor[3519]: Heartbeat: Tor's uptime is 0:46 hours, with 11 circuits open. I've sent 192.00 GB and received 192.01 GB. Oct 16 09:46:11 venator Tor[3519]: Heartbeat: Accounting enabled. Sent: 5.42 MB, Received: 6.82 MB, Used: 6.90 MB / 48.00 GB, Rule: max. The current accounting interval ends on 2017-10-17 09:00:00, in 23:13 hours. Oct 16 09:46:11 venator Tor[3519]: Average packaged cell fullness: 12.851%. TLS write overhead: 2% Oct 16 09:46:11 venator Tor[3519]: Circuit handshake stats since last time: 12/12 TAP, 66/66 NTor. Oct 16 09:46:11 venator Tor[3519]: Since startup, we have initiated 0 v1 connections, 0 v2 connections, 0 v3 connections, and 35405 v4 connections; and received 16 v1 connections, 17 v2 connections, 1 v3 connections, and 29675 v4 connections. Oct 16 14:45:03 venator Tor[3519]: Bandwidth soft limit reached; commencing hibernation. No new connections will be accepted Oct 16 14:45:07 venator Tor[3519]: Going dormant. Blowing away remaining connections. Oct 16 15:46:11 venator Tor[3519]: Heartbeat: Tor's uptime is 6:46 hours, with 0 circuits open. I've sent 239.99 GB and received 239.98 GB. We are currently hibernating. Oct 16 15:46:11 venator Tor[3519]: Circuit handshake stats since last time: 27077/27077 TAP, 747536/747536 NTor. Oct 16 15:46:11 venator Tor[3519]: Since startup, we have initiated 0 v1 connections, 0 v2 connections, 0 v3 connections, and 44017 v4 connections; and received 17 v1 connections, 22 v2 connections, 2 v3 connections, and 37042 v4 connections.

5 7

my relay 'alnsn' died
by Alexander Nasonov 19 Oct '17

19 Oct '17

B9A41AD7AE8B2A4E6DE96EE77E3C8C04BADA8AC0 is currently down because harware died this morning. I will either reinstall it or move to a different AS. In any case, it won't happen tomorrow. I hope to have it up and running on the weekend. Master key is safe because it's on a different machine. Alex

2 1

atlas.cogentco.com Is blocking
by Paul Templeton 19 Oct '17

19 Oct '17

Has anyone come across a scenario where a carrier blocks IP traffic? atlas.cogentco.com is the point which drops any packet to 95.130.9.210 The server is up and running internal monitoring says its OK. The ISP doesn't provide an interface to the Server so I can not log on to do any other validating. Trace routes to any IP with the ISP (active or not)terminates in the ISP's network. Trace route from any point on the planet times out as soon as you hit atlas.cogentco.com Any thoughts... **IPonU could you ping from one of your servers at Digicube please and let me know. Paul

3 4

Is AboveClouds still active?
by Ralph Seichter 19 Oct '17

19 Oct '17

Does anybody here know if AboveClouds https://aboveclouds.co.uk is still in business? Emails sent to their support address have been unanswered for a month now. -Ralph

1 0

"Bug: Duplicate call to circuit_mark_for_close"
by tor 19 Oct '17

19 Oct '17

Hi, I'm troubleshooting a Linux relay where the Tor service is having problems. External monitoring alerts indicate both the ORPort and DirPort are unreachable (TCP connection timeout). I can ssh in and the Tor service is still running. The node seems to have increased memory usage at this point but there's no evidence of OOM. I restart the Tor service, monitoring says all is good again, and things seem fine for a bit, until the cycle repeats hours later. I'm still investigating, but one thing I immediately noticed was hundreds of these lines in the logs: [warn] circuit_mark_for_close_(): Bug: Duplicate call to circuit_mark_for_close at ../src/or/onion.c:238 (first at ../src/or/command.c:579) (on Tor 0.2.9.11 ) I found https://trac.torproject.org/projects/tor/ticket/20059 but it's marked as fixed with a backport to 0.2.9. Any thoughts?

4 9

vsif.ca relays: MyFamily configuration
by nusenu 18 Oct '17

18 Oct '17

Hello Vancouver Society for Internet Freedom, thanks for running tor relays. Unfortunately you are in a position that can potentially harm tor users if you do not set MyFamily (torrc) on all your relays. Please have a look at your MyFamily configuration. https://nusenu.github.io/OrNetStats/endtoend-correlation-groups#vsif-suppor… You are also running an outdated version of tor that is no longer recommended: https://atlas.torproject.org/#search/vsif%20version:0.2.9.10 some more background: https://hackernoon.com/some-tor-relays-you-might-want-to-avoid-5901597ad821 Let us know if you need help with configuring MyFamily. thanks, nusenu -- https://mastodon.social/@nusenu twitter: @nusenu_

1 0

Used TLS implementations by relays
by nusenu 15 Oct '17

15 Oct '17

Hi, are there any TLS libraries other than - openssl - libressl that are actively used by current tor relays? https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations#Overview thanks, nusenu -- https://mastodon.social/@nusenu twitter: @nusenu_

1 0

Hashed password behaviour
by Geoff Down 15 Oct '17

15 Oct '17

Hello all, what sort of crazy bug would make Tor give different hashes for the same password? $ tor --hash-password hello 16:735E6FA5355D4146606AFE25B61B411DF419878C99705164D038FC99BC $ tor --hash-password hello 16:8201E7D35BB8CACB60BF8947B49A3480BA1A17E77EDA8BE45790746884 $ tor --version Tor version 0.3.1.7 (git-6babd3d9ba9318b3). (on OSX 10.4). GD

3 5