- tor-relays - lists.torproject.org

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 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