September 2017 - tor-relays - lists.torproject.org

No Gaurd
by Kurt Besig 29 Sep '17

29 Sep '17

https://atlas.torproject.org/#details/E65D300F11E1DB12C534B0146BDAB6972F1A8… Relay looks pretty stable to me, I'm re-visiting the lack of guard status... ideas?

4 3

MaxMemInQueues defends against 375000 circuits in 9 secs
by Felix 29 Sep '17

29 Sep '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi everybody Another circuit storm, right ? - ---- MaxMemInQueues 2 GB - ---- 2017-09-26_17-55-00: PID JID USERNAME THR PRI NICE SIZE RES STATE C TIME CPU COMMAND 84847 2 256 6 20 0 484M 427M uwait 0 907:02 11.77% tor 2017-09-26_18-59-00: PID JID USERNAME THR PRI NICE SIZE RES STATE C TIME CPU COMMAND 84847 2 256 6 20 0 2437M 2380M uwait 0 917:03 18.26% tor - ---- On Tor 0.3.2.1-alpha 290274dbb5428bc5 Sep 26 18:24:37.000 [notice] Heartbeat: Tor's uptime is 4 days 18:59 hours, with 13714 circuits open. I've sent 2459.48 GB and received 2422.58 GB. Sep 26 18:24:37.000 [notice] Circuit handshake stats since last time: 4635/4635 TAP, 113271/113271 NTor. Sep 26 18:24:37.000 [notice] Since startup, we have initiated 0 v1 connections, 0 v2 connections, 3 v3 connections, and 214559 v4 connections; and received 886 v1 connections, 24624 v2 connections, 60722 v3 connections, and 354411 v4 connections. Sep 26 18:59:28.000 [notice] We're low on memory. Killing circuits with over-long queues. (This behavior is controlled by MaxMemInQueues.) Sep 26 18:59:28.000 [notice] Removed 106528 bytes by killing 14408 circuits; 0 circuits remain alive. Also killed 0 non-linked directory connections. Sep 26 18:59:28.000 [notice] We're low on memory. Killing circuits with over-long queues. (This behavior is controlled by MaxMemInQueues.) Sep 26 18:59:28.000 [notice] Removed 528 bytes by killing 7 circuits; 0 circuits remain alive. Also killed 0 non-linked directory connections. ... ************************************************************************ **************** 2500 x removed some bytes by killing between single and 300 circuits (constantly increasing sawtoothy, average 150 circuits) average 150 circuits x 2500 = 375000 circuits avoided in 9 seconds ************************************************************************ **************** ... Sep 26 18:59:37.000 [notice] We're low on memory. Killing circuits with over-long queues. (This behavior is controlled by MaxMemInQueues.) Sep 26 18:59:37.000 [notice] Removed 4624 bytes by killing 115 circuits; 0 circuits remain alive. Also killed 1 non-linked directory connections. [] https:// lists.torproject.org/pipermail/tor-relays/2017-July/012624.html - -- Cheers, Felix -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJZyqCOAAoJEF1W24InZUQd/eAQAIK7IDNbnR+E1uTpvVwimUCJ jrSPr5sCXu8t4ly0Tci/tg7mCGTd9xKJvJgUHLei7pd6UmdDJvwajrX08tE/iBC/ uJPLEr69OBBqDICf7E+Y4oQGRz4ICY/4IGeb7lU/My6TzT00gHcs0/0tuww1actm P06uobAeRx+56GCg9hGopLavSOIHsR0bFC3k5kqin79qx40XwNuN6xkFCDni/fHW EO9GazD2iE4zJ3+1lIJsIzaA7fgu+Ack2GcLpaPKMNMwX3DagG/A619HsddOoBfH EFV2ZOhnR9XWytgIfPX4e/gErTHvWPshm0qaO4PzxwAlAoSKygvz497O1HZ3AlM+ fcn+C/fkfCcU2PYVPXKV3vDzupiZ17OJGfRNtAy1EqFLCK6q7xQAp1e3JuRJZBDO 3E/18FJM7JXCUz5StxwB+oAu9LGib50vXbtAOtuLwfX4OC3Nl0Fc/gw0ueYwWIPu QvsU0WNelwaUo3wWs47fJsMsJqjpt0Uywh8yvK809xvqogUFiQBF2ynIp5QzfaJ0 or/7axRHXglkxVaF+q84GFG8LAaspurGauQQFtzUdzl/ljWC963PyrGiOr0kCj/R OIc3TDSDYopFTllXeeVu2bysW7PrzL3vu5rcOHbbVAnUoRukA4Hh6qJFQuTk+Ndb tT8G8jk1QJjRqH/IaTLg =r7/i -----END PGP SIGNATURE-----

3 3

IPonU tor relays: MyFamily configuration
by nusenu 28 Sep '17

28 Sep '17

Hello IPonU Relay Operator, thanks for running relays. Since you recently became a tor exit operator you are now in a position that can potentially harm tor users if you do not set your MyFamily on all your relays. Please have a look at you MyFamily configuration. https://nusenu.github.io/OrNetStats/endtoend-correlation-groups 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

Individual Operator Exit Probability Threshold
by John Ricketts 27 Sep '17

27 Sep '17

All, I have brought this question up in meetings in Seattle and other places so some of you may have already heard me ask this question. So, at risk of repeating the question for some... here goes. I am about to fire up more Exit Relays and if I do so I will jump from my roughly 3% of Exit Probability to what technically could easily reach 6-8%. I would like to know everyone’s opinion on having an individual operator have that much exit share. In my case, all the traffic would be coming from the same AS as well, but distributed over four different cities with different upstream carriers. Please chime in, if I get the a green light from the discussion it will happen within a month. Sincerely, John L. Ricketts, PhD Quintex Alliance Consulting

13 20

On some differences after upgrade to latest tor for Jessie
by a tor op 27 Sep '17

27 Sep '17

Hi I'm running an obfs4 bridge and upgraded to latest version. Use Debian Jessie (8.9). One thing that puzzles me is the log /var/log/tor/log I used to always see some useful info there, like number of connecting clients during the last 6 hours etc. I have an entry: [notice] Clean shutdown finished. Exiting. at the end of the file with time stamp from when the upgrade was performed but today's version of it is NUL. I also noticed that for some reason the 'service tor restart' etc command does not work. Or am I mixing this with Ubuntu now?!.. And it does not give any info back on terminal. Weird. Maybe it has something to do with that shit systemd I donno. I have a limited time troubleshooting this right now since I also do other things in life than troubleshoot tor. 'systemctl status tor' gives info like this: systemd[1]: Reloaded Anonymizing overlay network for TCP and seem to indicate that everything is running with some other stats info. It also seems to work and Atlas has it Green and there seems to be connections coming in and so on. Can someone fill me in on wtf is going on? I'd like to know about the differences I feel I am experiencing, the lack of feedback from 'service' command and the empty tor log file. TIA

3 2

>18k 'Machiavelli' bridges added since 2017-09-02 (>4k currently running = 64% of bridges)
by nusenu 26 Sep '17

26 Sep '17

Hi, do you know anything about >18k Machiavelli named bridges that have been added in the last few days? (>4k currently running) thanks, nusenu properties: OS: Linux tor version: 0.3.0.10 transports: obfs4 https://twitter.com/nusenu_/status/905580044503969792 new bridges per first_seen date: [...] | 2017-09-02 13:43:33 | 1 | < usual rate | 2017-09-02 14:43:33 | 2 | | 2017-09-02 15:43:33 | 1 | | 2017-09-02 17:43:33 | 1 | | 2017-09-02 18:43:33 | 1360 | < Machiavelli bridges start here | 2017-09-02 19:43:33 | 667 | | 2017-09-02 20:43:33 | 196 | | 2017-09-02 21:43:33 | 184 | | 2017-09-02 22:43:33 | 196 | | 2017-09-02 23:43:33 | 189 | | 2017-09-03 00:43:33 | 196 | [...] | 2017-09-06 18:43:33 | 152 | | 2017-09-06 19:43:33 | 149 | | 2017-09-06 20:43:33 | 148 | +---------------------+----------+ First Machiavelli named bridge (running in the last 7 days) appeared on 2016-11-28 00:41:02 -- https://mastodon.social/@nusenu https://twitter.com/nusenu_

3 3

Accounting logic
by r1610091651 25 Sep '17

25 Sep '17

Hi I'm on version 0.3.1.7 on Linux. I've following config entries: AccountingMax 1639 GBytes AccountingStart month 24 00:00 Today I've discovered following log entries: Sep 24 00:00:00.000 [notice] Configured hibernation. This interval began at 2017-09-24 00:00:00; the scheduled wake-up time is 2017 -09-28 16:44:28; we expect to exhaust our quota for this interval around 2017-10-21 20:52:28; the next interval begins at 2017-10-24 00:00:00 (all times local) Sep 24 00:00:01.000 [notice] Commencing hibernation. We will wake up at 2017-09-28 16:44:28 local time. Sep 24 00:00:01.000 [notice] Going dormant. Blowing away remaining connections. For context, Tor did not exceed previous quota and was operating normally before 24 september 00:00. To me this is not what I would have expected as behaviour given the config. My exception is that the tor would reset counters at month end/beginning and continue operation. Is it a bug? Thanks Sebastian

2 2

update installation guide please
by I 25 Sep '17

25 Sep '17

2 1

bad exit flag reason
by nusenu 24 Sep '17

24 Sep '17

Hi, [1] is not maintained since a long time. I'm curious what the reason for assigning the badexit flag to [2] was. If you know anything about it and can share something, that would be great. thanks, nusenu [2] https://atlas.torproject.org/#search/flag:badexit 37.221.171.234 75FCEA0BE7A2A472669352A1F0F2E59F99C6A3AA 37.221.171.237 128814837EC27F20D76EBDDB2CB3AB70258F0BA8 [1] https://trac.torproject.org/projects/tor/wiki/doc/badRelays -- https://mastodon.social/@nusenu https://twitter.com/nusenu_

3 3

bug messages in my relay's notices.log
by Scott Bennett 23 Sep '17

23 Sep '17

I've gotten a couple of these sets of messages in the last few hours. Sep 22 05:13:17.366 [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.6-rc efc306c59aa9ee1a) Sep 22 05:13:17.366 [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.6-rc efc306c59aa9ee1a) Sep 22 05:13:17.366 [warn] Bug: 0x11a63fc <tor_bug_occurred_+268> at /usr/local/bin/tor (on Tor 0.3.1.6-rc efc306c59aa9ee1a) Sep 22 05:13:17.366 [warn] Bug: 0x11abbd4 <tor_compress_process+228> at /usr/local/bin/tor (on Tor 0.3.1.6-rc efc306c59aa9ee1a) Sep 22 05:13:17.366 [warn] Bug: 0x11ab0fa <tor_compress+554> at /usr/local/bin/tor (on Tor 0.3.1.6-rc efc306c59aa9ee1a) Sep 22 05:13:17.366 [warn] Bug: 0x11ab540 <tor_uncompress+64> at /usr/local/bin/tor (on Tor 0.3.1.6-rc efc306c59aa9ee1a) Sep 22 05:13:17.366 [warn] Bug: 0x114ecfd <connection_dir_reached_eof+1773> at /usr/local/bin/tor (on Tor 0.3.1.6-rc efc306c59aa9ee1a) Sep 22 05:13:17.366 [warn] Bug: 0x1126c43 <connection_handle_read+3027> at /usr/local/bin/tor (on Tor 0.3.1.6-rc efc306c59aa9ee1a) Sep 22 05:13:17.366 [warn] Bug: 0x106db94 <connection_add_impl+532> at /usr/local/bin/tor (on Tor 0.3.1.6-rc efc306c59aa9ee1a) Sep 22 05:13:17.366 [warn] Bug: 0x1c1e8564e <event_base_assert_ok_nolock_+3102> at /usr/local/lib/libevent-2.1.so.6 (on Tor 0.3.1.6-rc efc306c59aa9ee1a) Sep 22 05:13:17.366 [warn] Bug: 0x1c1e80a1e <event_base_loop+1310> at /usr/local/lib/libevent-2.1.so.6 (on Tor 0.3.1.6-rc efc306c59aa9ee1a) Sep 22 05:13:17.366 [warn] Bug: 0x106fa55 <do_main_loop+1413> at /usr/local/bin/tor (on Tor 0.3.1.6-rc efc306c59aa9ee1a) Sep 22 05:13:17.366 [warn] Bug: 0x1071e89 <tor_main+233> at /usr/local/bin/tor (on Tor 0.3.1.6-rc efc306c59aa9ee1a) Sep 22 05:13:17.366 [warn] Bug: 0x106d899 <main+25> at /usr/local/bin/tor (on Tor 0.3.1.6-rc efc306c59aa9ee1a) Sep 22 05:13:17.366 [warn] Bug: 0x106d791 <_start+417> at /usr/local/bin/tor (on Tor 0.3.1.6-rc efc306c59aa9ee1a) My outdated system is running FreeBSD 10.3-STABLE. I've never seen these messages before that I can remember. What causes them? What, if anything, should I do about them? And what fallout do they cause for users? Thanks in advance for any relevant information! Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************

3 5