- tor-relays - lists.torproject.org

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

25 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