- tor-relays - lists.torproject.org

Running both Transmission server and Tor relay
by Ch1keen 06 Nov '17

06 Nov '17

Transmission is the open source torrent application which supports web-based interface. So when users upload torrent files from other computers to that server, it automatically downloads files written in torrent files. I used that at my home server, but I'd like to use my server as Tor relay also. But as many knows, running BitTorrent over Tor is really bad idea. It seriously harms security of Tor network. So I thought about the solution about how to use them simultaneously. 1. One machine, Two services. If that situation not harms the security, I will use them on one machine. 2. Two machines, Two services. Running that services one machine to one service to avoid the crashes between two. 3. Gave up running one service. If really no way to run both, I will gave up running Transmission service. Which could be best solution I will make? Sent from ProtonMail mobile

5 6

handling of MyFamily for an outdated relay
by Toralf Förster 04 Nov '17

04 Nov '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Looking at his : I do wonder how to deal with deleting all /var/lib/tor/data2/* files of a Tor relay and running a new one with the same config (but now different key/fingerprint). I added the new fingerprint to the config, which now has 3 entries (the middle is 1 outdated): MyFamily 1AF72E8906E6C49481A791A6F8F84F8DFEBBB2BA,6EABEBF38CE7E3DF672C4DB01383606FE3EB2215,D11D11877769B9E617537B4B46BFB92B443DE33D Is this the right way ? I'm asking b/c I do see now "Alleged Family Members" here: https://atlas.torproject.org/#details/D11D11877769B9E617537B4B46BFB92B443DE… - -- Toralf PGP C4EACDDE 0076E94E -----BEGIN PGP SIGNATURE----- iI0EAREIADUWIQQaN2+ZSp0CbxPiTc/E6s3eAHbpTgUCWf3YchccdG9yYWxmLmZv ZXJzdGVyQGdteC5kZQAKCRDE6s3eAHbpTuLJAQCAmqnYRI5y4NpShgQp7kcdSTC2 MfrsfHkH3aObifTJ1wD9ERBkJN6zAIY7usN6sPy4VfHzAjkGaMTDLoBlYRA2f1w= =EQTO -----END PGP SIGNATURE-----

2 3

Monitoring multiple relays
by Xza 01 Nov '17

01 Nov '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello, I have a couple relays / exits running. Now my question is : how do you manage them is there any dashboard or CLI tools to manage them ( statistics, ect.. ) I know the cli tool specially for Tor "arm" Thanks alot. - -- PGP : 29A4CE52 -----BEGIN PGP SIGNATURE----- iQI4BAEBCgAiGxxEbyA8eWFuZGVyZXNvbkByaXNldXAubmV0PgUCV0SJlwAKCRBI of/XNyszSvv/D/9VtjI+bmiqK53v//StUbmpYjgQjYheYvwktFld+2XDURh52dmU sbk3lab2RS1eQJxjV0BVXMF9O2JUAlp4NA2UMpj8ZJlCk0h1S6p2o4/sAlsrHr8Z nb67HiaRIyEvi9cQiXFtDtK/onAkEuKskolyvh3ysJRRUubHSX1z8WuNJIc4xyGH ZpSLPGUOO6qI7mM8ztS0muEy1khmkHgtlyHi2l4K/NsW3I90cV3w6Db2AEnV6v1c tsfehqLExsHUdEo0U3hHU7yY1p2fzD5Z+C0tgVKTnP5Zus/Vr9OH/zFwxneo0E7a 5FHdnCZnNIG9W32uQgjDdmBEv/YFEd0um/vMWFGUehFANSt+DIps7E+AjwiJwm2i ov97JJurQkrSMX7ZchTEsy720Ju272olp2eDiHaXXTK2TkxcEq+d1gZfj7CXycPW 6mCrj6L6URJAZ34GJQfFFjv8QbFmKkAvGhxl/O8KXRbXxedbLH7PY73jmFjJcmxO +KnSeyqMe1KbzazYyFydP+VmgI2k1IlO89l8Jq1Gq9f2KOPY9UKFZjGDKLS0xGZW EnqU/KUINcrGejYFT8nYNxA+OFTd/ZGIX5qP4Vo5NsZ/pDLZjdxIcvHx1jjZbER+ 5Ku2bihm2KTNAGoYDqB3LGCm+QdEFG/p573xQCcXPk92GyhMJDi9EMPDgA== =mTa0 -----END PGP SIGNATURE-----

8 8

Exit offline
by D.S. Ljungmark 01 Nov '17

01 Nov '17

Sadly, we had some issues and had to take the modio exit offline for a while. We were seeing interesting traffic spikes on ipv6, and the pfsense firewall couldn't handle the traffic properly, so the relay will have to be offline until we got a replacement firewall in place. Try not to miss us too much. Regards, D.S.

1 1

stability of "Sandbox" feature
by fatal 31 Oct '17

31 Oct '17

Hey, the Tor manpage still states, that "the [sandbox] option is currently an experimental feature". How 'experimental' is it with e. g. Debian Stretch and using the torproject repo? Give it a try, or wait some more time? tnx f.

2 1

relayor v0.3.0 is released
by nusenu 31 Oct '17

31 Oct '17

Hi, relayor v0.3.0 has been released. https://github.com/nusenu/ansible-relayor Whether you run a single or many relays, relayor helps you with running relays with minimal effort (automate everything). Introduction to get you started: https://medium.com/@nusenu/deploying-tor-relays-with-ansible-6612593fa34d Main benefits for a tor relay operator ====================================== * automation - no more manual setup tasks * security: offline Ed25519 master keys every tor instance is run with a distinct user * automatically makes use of IPv6 IPs (if available) * automatic tor instance generation (two by default - configurable) * enables tor's Sandbox feature by default on Debian-based systems * easily choose between alpha/non-alpha releases * easily restore a relay setup * easily choose between exit relay/non-exit relay mode * automatic deployment of a tor exit notice html page via tor's DirPort * automatic MyFamily management Supported Operating Systems ---------------------------- Debian 8, 9 and Debian Testing OpenBSD 6.1 FreeBSD 10.3, 11.1 HardenedBSD 11 Ubuntu 16.04 CentOS 7 Fedora 26 Notable changes since v0.2.1: ------------------------------ - enable tor's Sandbox feature by _default_ on Debian based systems - add support for automatic use of OutboundBindAddressExit via simple on/off boolean (opt-in) - add support for HardenedBSD - add support for tor alpha releases on FreeBSD/HardenedBSD - add support for more torrc options - performance improvement due to the use of dynamic includes (ansible) NOTE: The minimal required ansible version has been increased to 2.4.1 due to show-stopper bugs in older versions. regards, nusenu -- https://mastodon.social/@nusenu twitter: @nusenu_

1 0

Maximum of 2 Tor Instances per IP-Address (?)
by Petrarca 31 Oct '17

31 Oct '17

I read a few times at different places that there is a maximum of two Tor instances that can be run over one public IP address. My questions: 1) Is this statement true? 2) Is there an easy workaround maybe? 3) Just out of curiosity: what is the background for this limitation (if it is true)? Background: I was thinking about running several things on the onion network, e.g. one or more relays (maybe on different platforms?), hidden services (like wordpress, nextcloud), private tor client/access, etc. That would be all running over one internet connection with one WAN IP address with sufficient bandwidths. I probably could set most of it up on one platform/device but I think it might be better to implement them on separated devices rather (even different physical devices). Any comments are welcome - I'm always happy to learn :-) but

3 2

Thank you to directory operators
by Tor Node Admin ＠ SechsNullDrei.org 31 Oct '17

31 Oct '17

Good morning, Relay operators often receive gratitude on this list for running relays, but let's not forget the directory operators - those individuals/organizations who are more central to The Tor Network and run their directory servers at a higher personal risk level than the relay operators. Sincerely, Isaac, <mailto:Tor@SechsNullDrei.org> Tor(a)SechsNullDrei.org

3 2

UbuntuCore
by Paul Templeton 30 Oct '17

30 Oct '17

These nodes are popping up everywhere - is this some sort of malware being deployed on systems around the globe? Paul

5 4

Relay flag set counts
by grarpamp 30 Oct '17

30 Oct '17

1 s Authority Fast HSDir Running Stable V2Dir Valid 2 s Authority Fast Running Stable V2Dir Valid 7 s Authority Running Stable V2Dir Valid 270 s Exit Fast Guard HSDir Running Stable V2Dir Valid 58 s Exit Fast Guard Running Stable V2Dir Valid 25 s Exit Fast Guard Running Stable Valid 168 s Exit Fast HSDir Running Stable V2Dir Valid 71 s Exit Fast Running Stable V2Dir Valid 45 s Exit Fast Running Stable Valid 149 s Exit Fast Running V2Dir Valid 15 s Exit Fast Running Valid 7 s Exit Running Stable V2Dir Valid 10 s Exit Running Stable Valid 3 s Exit Running V2Dir Valid 2 s Exit Running Valid 1293 s Fast Guard HSDir Running Stable V2Dir Valid 311 s Fast Guard Running Stable V2Dir Valid 167 s Fast Guard Running Stable Valid 1721 s Fast HSDir Running Stable V2Dir Valid 513 s Fast Running Stable V2Dir Valid 469 s Fast Running Stable Valid 754 s Fast Running V2Dir Valid 200 s Fast Running Valid 96 s Running Stable V2Dir Valid 41 s Running Stable Valid 95 s Running V2Dir Valid 27 s Running Valid

1 0

"Fast" flag definition
by Igor Mitrofanov 30 Oct '17

30 Oct '17

Hi, It looks like 94.7% of all Running relays have the "Fast" flag now. If that percentage becomes 100%, the flag will become meaningless. What were the reasons behind the current definition of "Fast", and are those still valid? If not, should "Fast" become self-adjusting ("faster than 2 Mbps or 70% of all Guard relays, whichever is greater")? Thanks!

3 3

Exit probability
by Dr Gerard Bulger 29 Oct '17

29 Oct '17

How is exit probability counted? Is it only port 80 exit tested? I exit many 1000s of ports, including 443, but not those of high risk of abuse emails and thus upsetting the ISP. So port 80 along with others are blocked. I realise no port 80 limits the use of the exit so not expecting so see a high probability of exit. But Atlas shows none. Currently of some 3000 connections 200 are exit. Tor atlas show exit probability of 0.0000% Gerry -----Original Message----- From: tor-relays [mailto:tor-relays-bounces@lists.torproject.org] On Behalf Of teor Sent: 29 October 2017 12:45 To: tor-relays(a)lists.torproject.org Subject: Re: [tor-relays] sum of consensus weight of 2 relays running at the same IP On 29 Oct 2017, at 23:30, Toralf Förster <toralf.foerster(a)gmx.de> wrote: >> On 10/29/2017 01:24 PM, teor wrote: >> Possibly. >> >> Are the relays CPU-limited, or bandwidth-limited? > > Not at all, neither limited by a config value nor by the hardware > (1GBit/s, 200 MBit/s guaranteed, i7-3930, all non-Tor processes have > "nice" in front, ids are 1AF72E8906E6C49481A791A6F8F84F8DFEBBB2BA and > 6EABEBF38CE7E3DF672C4DB01383606FE3EB2215) I'm sorry, this doesn't help me answer your question. Usually, a relay is limited by either the available network bandwidth, or by the speed of a single CPU core on the machine. If the first relay used all the available bandwidth, then two relays will eventually have lower consensus weight values. If the first relay used all of a single CPU core for its main thread, then the two relays will eventually have similar consensus weight values. T _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

3 2

sum of consensus weight of 2 relays running at the same IP
by Toralf Förster 29 Oct '17

29 Oct '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I assumed that 2 Tor at the same ip address would get haöf of the consensus of the previously runnning only one Tor relay at the same hardware. But it semes, that both Tor relays get now the same value as the one before. Is this intended ? - -- Toralf PGP C4EACDDE 0076E94E -----BEGIN PGP SIGNATURE----- iI0EAREIADUWIQQaN2+ZSp0CbxPiTc/E6s3eAHbpTgUCWfW5BRccdG9yYWxmLmZv ZXJzdGVyQGdteC5kZQAKCRDE6s3eAHbpTse3AP9waxb9fe+ECq0QyR2PkS6Tw3j1 Lc+H7UafeeuUalHJngEAg9pg1jHzZnrEir03xCQEeP9HRrtfbKCUBo/AI/40KMo= =wt5I -----END PGP SIGNATURE-----

2 3

Testing Golang relay implementation
by Michael McLoughlin 28 Oct '17

28 Oct '17

All, I am working on a pure Golang relay implementation. https://github.com/mmcloughlin/pearl/ I have thus far been testing locally with chutney ( https://gitweb.torproject.org/chutney.git) The project is not complete by any stretch, but I believe I am close to the point where it can handle Tor network traffic. I expect I can learn *a lot* by running against real traffic rather than my sandboxed environment. I wanted to get in touch with the community before going live. Any advice gratefully received. The implementation identifies itself clearly in the server descriptor, both in the "platform" and "contact" items. If people notice any problems with the relay specifically they will be able to contact me. Thanks, Mike

9 17

Atlas / Onionoo ...
by Sebastian Urbach 27 Oct '17

27 Oct '17

Back on the road ;-) -- Sincerely yours / M.f.G. / Sincères salutations Sebastian Urbach --------------------------------------------------------------------------- Those who surrender freedom for security will not have, nor do they deserve, either one. --------------------------------------------------------------------------- Benjamin Franklin (1706-1790)

2 1

decrease in traffic
by Trey Nolen 27 Oct '17

27 Oct '17

I'm new to running a Tor relay and started one about a month ago. I've got 50 Mbps dedicated to it and at first it climbed in traffic pretty steadily until it got to around 25-30 Mbps being used. Since then, it has declined steadily and is down to about 350 KBps now (yes, I'm keeping the units straight). My node is a single core VPS running 3.2GHz and with 1GB RAM. Currently, top shows tor as using about 15% of the memory. When it was churning out at the maximum rate it got to, the CPU was pretty hammered. I was considering allocating another core, but there is no need anymore as it is hovering around 7% usage. The server is running on Ubuntu 16.04.3 and I'm running 0.3.1.7 tor. Am I doing something wrong to result in the decrease in traffic? Any advice is appreciated. Trey Nolen

6 14

"Onionoo seems to serve outdated data"
by tor 26 Oct '17

26 Oct '17

I see "Onionoo seems to serve outdated data :( Last update was: Tue Oct 24 2017" at the top of Atlas, and querying the Onionoo API directly results in the same outdated data. Anyone working on fixing it?

2 1

Balancing throughput versus getting Black-Holed
by Paul Templeton 26 Oct '17

26 Oct '17

Hi All, I have a question. I would like to know other peoples experiences for exit nodes and the methods of mitigating getting black holed. I have a node that gets black-holed all the time now - it runs at 18Mibt - 41781FDC57238DAB955DF6D6E8400CEC5ACBE706 I have noticed smaller relays/exits on the same AS don't seem to run into the same problem. I was thinking of running two to three smaller exits at around 4MiBt or just going for a larger faster middle. Thoughs/Comments. I have been emailing the provider and their carrier but know one ever responds/reply's. Paul

4 8

Re: [tor-relays] Troubleshooting rasptor4273 (was: Decline in relays)
by rasptor 4273 25 Oct '17

25 Oct '17

My IP/ORPORT is 24.132.17.230:9001. My relay is still running. arm shows traffic going through and several circuits on the connections page. And from my notices.log file: Oct 24 16:35:45.000 [notice] Heartbeat: It seems like we are not in the cached consensus. Oct 24 16:35:45.000 [notice] Heartbeat: Tor's uptime is 6 days 0:00 hours, with 2 circuits open. I've sent 47.17 MB and received 237.75 MB. Oct 24 16:35:45.000 [notice] Average packaged cell fullness: 66.463% Oct 24 16:35:45.000 [notice] TLS write overhead: 8% Oct 24 16:35:45.000 [notice] Circuit handshake stats since last time: 0/0 TAP, 0/0 NTor. However there's also a lot of this in that file: Oct 24 16:55:45.000 [warn] Your server (24.132.17.230:9001) has not managed to confirm that its ORPort is reachable. Please check your firewalls, ports, address, /etc/hosts file, etc. Oct 24 16:55:45.000 [warn] Your server (24.132.17.230:9030) has not managed to confirm that its DirPort is reachable. Please check your firewalls, ports, address, /etc/hosts file, etc. I added the log line to my torrc and sent a SIGHUP signal. Entries are being added to the log file, so that worked. Regards, Joep On Oct 23, 2017 22:59, "David Goulet" <dgoulet(a)torproject.org> wrote: On 23 Oct (22:49:55), rasptor 4273 wrote: > My relay has gone off the consensus. > Fingerprint: E7FFF8C3D5736AB87215C5DB05620103033E69C3 Interesting. And it is still running as of now without any problems? Can you give me the IP/ORPORT tuple? You think you can add this to your torrc and then HUP your relay (very importatnt to NOT restart it). Log info file <FULL_PATH_TO_LOG_FILE> And then after a some hours (maybe a day), we'll be looking for "Decided to publish new relay descriptor". If it appears, we know that your relay keeps uploading to the directory authorities so thus chances are that there is a problem on the dirauth side not finding you reachable. Thanks! David > Alias: rasptor4273 > Am running Tor 0.2.5.14 on Debian, Raspberry Pi 2B. I upgraded to that > version on September 3rd. > > I grepped through these: > https://collector.torproject.org/archive/relay-descriptors/consensuses/ and > the latest entry I found for my alias is in the file > ./17/2017-09-17-13-00-00-consensus. > > Not sure what other information I can provide. Do let me know if I can do > anything else to help troubleshoot. > > Best, > Joep > > On Mon, Oct 23, 2017 at 9:14 PM, George <george(a)queair.net> wrote: > > > David Goulet: > > > Hello everyone! > > > > > > Since July 2017, there has been a steady decline in relays from ~7k to > > now > > > ~6.5k. This is a bit unusual that is we don't see often such a steady > > behavior > > > of relays going offline (at least that I can remember...). > > > > > > It could certainly be something normal here. However, we shouldn't rule > > out a > > > bug in tor as well. The steadyness of the decline makes me a bit more > > worried > > > than usual. > > > > > > You can see the decline has started around July 2017: > > > > > > https://metrics.torproject.org/networksize.html?start= > > 2017-06-01&end=2017-10-23 > > > > > > What happened around July in terms of tor release: > > > > > > 2017-06-08 09:35:17 -0400 802d30d9b7 (tag: tor-0.3.0.8) > > > 2017-06-08 09:47:44 -0400 e14006a545 (tag: tor-0.2.5.14) > > > 2017-06-08 09:47:58 -0400 aa89500225 (tag: tor-0.2.9.11) > > > 2017-06-08 09:55:28 -0400 f833164576 (tag: tor-0.2.4.29) > > > 2017-06-08 09:55:58 -0400 21a9e5371d (tag: tor-0.2.6.12) > > > 2017-06-08 09:56:15 -0400 3db01d3b56 (tag: tor-0.2.7.8) > > > 2017-06-08 09:58:36 -0400 64ac28ef5d (tag: tor-0.2.8.14) > > > 2017-06-08 10:15:41 -0400 dc47d936d4 (tag: tor-0.3.1.3-alpha) > > > ... > > > 2017-06-29 16:56:13 -0400 fab91a290d (tag: tor-0.3.1.4-alpha) > > > 2017-06-29 17:03:23 -0400 22b3bf094e (tag: tor-0.3.0.9) > > > ... > > > 2017-08-01 11:33:36 -0400 83389502ee (tag: tor-0.3.1.5-alpha) > > > 2017-08-02 11:50:57 -0400 c33db290a9 (tag: tor-0.3.0.10) > > > > > > Note that on August 1st 2017, 0.2.4, 0.2.6 and 0.2.7 went end of life. > > > > > > That being said, I don't have an easy way to list which relays went > > offline > > > during the decline (since July basically) to see if a common pattern > > emerges. > > > > > > So few things. First, if anyone on this list noticed that their relay > > went off > > > the consensus while still having tor running, it is a good time to > > inform this > > > thread :). > > > > > > Second, anyone could have an idea of what possibly is going on that is > > have > > > one or more theories. Even better, if you have some tooling to try to > > list > > > which relays went offline, that would be _awesome_. > > > > > > Third, knowing what was the state of packaging in > > Debian/Redhat/Ubuntu/... > > > around July could be useful. What if a package in distro X is broken and > > the > > > update have been killing the relays? Or something like that... > > > > > > Last, looking at the dirauth would be a good idea. Basically, when did > > the > > > majority switched to 030 and then 031. Starting in July, what was the > > state of > > > the dirauth version? > > > > > > Any help is very welcome! Again, this decline could be from natural > > cause but > > > for now I just don't want to rule out an issue in tor or packaging. > > > > (Replying to OP since it went OT) > > > > As some of you know, TDP did a little suite of shell scripts based on > > OONI data to look at diversity statistics: > > > > https://torbsd.github.io/oostats.html > > > > With the source here for further tinkering: > > > > https://github.com/torbsd/tdp-onion-stats/ > > > > Maybe something we could look at is "exception reports", which in some > > industries means regular reports that look at anomalies or "exceptions" > > which display out-of-the-ordinary statistics, generally prompting some > > sort of action. > > > > In other words, daily reports would be run on, say, bw consensus by > > country, and if there was some statistically significant change over N > > periods of time, it would be noted. Or if a particular OS drops or > > jumps. Or if a particular AS jumps or declines for relays, bridges, > > whatever. > > > > If done right, a bunch of these reports could point to particular > > changes to the network that need further investigation, and in some > > cases, might quickly point to the related issue. Eg, countryX shutdown > > ISP with a particular AS number, etc. > > > > The more reports coupled with careful optimization over time could > > become an alarm system for Tor network changes, instead of just "er, > > such-and-such distro didnt update their packages then, I just found out > > in git." > > > > Thoughts? > > > > g > > > > > > -- > > > > > > 34A6 0A1F F8EF B465 866F F0C5 5D92 1FD1 ECF6 1682 > > > > > > _______________________________________________ > > tor-relays mailing list > > tor-relays(a)lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > > > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays -- HiTVizeJUSe9JPvs6jBv/6i8YFvEYY/NZmNhD2UixVY= _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

2 2

Tor t-shirts
by Vasilis 24 Oct '17

24 Oct '17

Hello, During the last Tor meeting I asked some people about the Tor t-shirt situation and the big delays to processing and response and it seems that the situation has been resolved and person eligible for a t-shirt have either been notified or have already received them. Has everyone eligible for a Tor t-shirt got one already? Are there still people that are still waiting? Thank to everyone running/run Tor relays. Cheers, ~Vasilis -- Fingerprint: 8FD5 CF5F 39FC 03EB B382 7470 5FBF 70B1 D126 0162 Pubkey: https://pgp.mit.edu/pks/lookup?op=get&search=0x5FBF70B1D1260162

11 17

Just got my first Abuse email :-)
by Paul Templeton 22 Oct '17

22 Oct '17

It makes me happy but alas it was forwarded to me by the provider and didn't include an email address... so now I can not reply, SIGH Question: this has come from port 22 usage - how important is this port to the general population? Thoughts... Regards, Paul

6 6

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 20 Oct '17

20 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