- tor-relays - lists.torproject.org

If you get weird crashes, that might be why
by pa011 26 Jun '16

26 Jun '16

On start-up my Exit (Linux 3.16.0-4-amd64) Tor 0.2.7.6 creates this log message: [warn] OpenSSL version from headers does not match the version we're running with. If you get weird crashes, that might be why. (Compiled with 100010bf: Op$bf: OpenSSL 1.0.1k 8 Jan 2015; running with 1000114f: OpenSSL 1.0.1t 3 May 2016). Unfortunately it really crashes ones a day. This seems to be an ongoing problem for years now? Could anyone please give some help - or is there none? Thanks Paul

4 4

Re: [tor-relays] Tor Weather has been discontinued
by l3thal.injecti0n＠gmail.com 24 Jun '16

24 Jun '16

If tor weather isn't running, and tshirt emails aren't being sent out, is someone doing this manually then? How can I help get the show on the road? Not gonna lie, I was really looking forward to the tshirt email as my relay definitely should have earned one about 2 weeks ago. haha. Actually I just donated $100... maybe now I can get a tshirt? https://atlas.torproject.org/#details/1F45542A24A61BF9408F1C05E0DCE4E29F2CB…

8 15

Multiple fingerprints for same IP:Port combo
by simon 22 Jun '16

22 Jun '16

Hi, Is it possible to have multiple Tor-nodes (with different keypair and fingerprint) at the same IP-Port combination? Or does that not work with the Directory implementation? The idea would be to have nodes under an anycast IP, because the anycast network has a lot of unused capacity. Another possibilty is to replicate the same node and re-use the same keypair in multiple physical locations for the same anycast IP, but I'm not sure this is a good idea. Simon

2 1

Opt-In Trial: Fallback Directory Mirrors
by Nick Mathewson 21 Jun '16

21 Jun '16

TL;DR: Stable non-exit relays can help tor clients use the Tor network. Please opt-in! We want to run a trial of fallback directory mirrors (fallbacks) in Tor. Tor clients contact fallbacks to download the consensus during initial bootstrap, before they contact the directory authorities. Fallbacks allow Tor to bootstrap in networks that block the Tor directory authorities. This allows people to use Tor without manually configuring bridges or pluggable transports. For more information about fallbacks, see: https://trac.torproject.org/projects/tor/wiki/doc/FallbackDirectoryMirrors For this trial, we want to find around 100 stable non-exit relays, as exits currently experience high load. We want relays that expect to be stable for the next 2 years, with: good uptime, the same IP address(es) and port, the same relay identity key, good bandwidth and network connectivity. In December 2015, we created a list of ~400 candidate fallbacks. https://trac.torproject.org/projects/tor/attachment/ticket/15775/fallback_d… If your relay is on this list, and you expect it to be on the same IP address(es) and port for at least 2 years, please consider opting-in for this trial. (Relays that aren't on the list are welcome to opt-in. They will be considered in future releases, or if the selection criteria change.) For the initial fallback release, we will only add your relay if you opt in. Please reply on the tor-relays mailing list, if you are able. (Opt-ins, opt-outs, and fallbacks chosen for inclusion in tor, will be managed using lists in the publicly available tor git repository.) all best wishes, & thanks for running Tor!

19 29

Relay Fingerprint Changed After Updates
by Brian Kroll 21 Jun '16

21 Jun '16

Hi All, I had a weird event happen where the fingerprint of my relay changed after updates to the OS. The host is running Debian 8.3 and the Tor version was at 0.2.7.6 at the time of update. Apt was used to update packages and the following packages were installed/upgraded. libapt-inst1.5:amd64 (1.0.9.8.3) libssl1.0.0:amd64 (1.0.1t-1+deb8u2) libidn11:amd64 (1.29-1+deb8u1) libtasn1-6:amd64 (4.2-3+deb8u2) libxml2:amd64 (2.9.1+dfsg1-5+deb8u2) libcairo2:amd64 (1.14.0-2.1+deb8u1) libexpat1:amd64 (2.1.0-6+deb8u3) libglib2.0-0:amd64 (2.42.1-1+b1) libgdk-pixbuf2.0-common (2.31.1-2+deb8u5) libgdk-pixbuf2.0-0:amd64 (2.31.1-2+deb8u5) libgtk2.0-common (2.24.25-3+deb8u1) libgtk2.0-0:amd64 (2.24.25-3+deb8u1) libgtk2.0-bin (2.24.25-3+deb8u1) libnettle4:amd64 (2.7.1-5+deb8u1) libhogweed2:amd64 (2.7.1-5+deb8u1) libksba8:amd64 (1.3.2-1+deb8u1) apt-utils (1.0.9.8.3) libxapian22 (1.2.19-1+deb8u1) locales (2.19-18+deb8u4) openssh-client (1:6.7p1-5+deb8u2) openssh-sftp-server (1:6.7p1-5+deb8u2) openssh-server (1:6.7p1-5+deb8u2) openssl (1.0.1t-1+deb8u2) After the updates completed I checked on the status of the relay and noticed that it was not running and started the Tor process again. After starting the process the fingerprint changed. My relay BrownLine was 9504CB22EEB25D344DE63CB7A6F2C46F895C3686 and now after updates is 9C8A123081EFBE022EF795630F447839DDFDDDEC. I have looked through Tor logs and can find nothing of value but heartbeat notices. I have also reviewed system logs and can find nothing out of the ordinary. Any thoughts on this? Any help would be appreciated. I will also open a bug report if needed. Thanks! //Brian

2 1

Handling abuse - like to get your help please
by pa011 21 Jun '16

21 Jun '16

As I am new to this business could somebody please give me a hint how to best handle such an abuse complain - possibly stop it? Thanks, Regards and a nice weekend. we have detected abuse from the IP address xxx.xxx.xxx,xxx, which according to a whois lookup is on your network. We would appreciate if you would investigate and take action as appropriate. Log lines are given below, but please ask if you require any further information. If you are not the correct person to contact about this please accept our apologies - your e-mail address was extracted from the whois record by an automated process. This mail was automatically generated. Note: Local timezone is +0200 (CEST) /var/log/apache2/access.log:xxx.xxx.xxx.xxx - - [17/Jun/2016:09:25:50 +0200] "POST /cgi-bin/php-cgi?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%6E HTTP/1.1" 404 293 "-" "Mozilla/5.0 (iPad; CPU OS 6_0 like Mac OS X) AppleWebKit/536.26(KHTML, like Gecko) Version/6.0 Mobile/10A5355d Safari/8536.25" /var/log/apache2/access.log:xxx.xxx.xxx.xxx - - [17/Jun/2016:09:25:51 +0200] "POST /cgi-bin/php.cgi?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%6E HTTP/1.1" 404 293 "-" "Mozilla/5.0 (iPad; CPU OS 6_0 like Mac OS X) AppleWebKit/536.26(KHTML, like Gecko) Version/6.0 Mobile/10A5355d Safari/8536.25" /var/log/apache2/access.log:xxx.xxx.xxx.xxx - - [17/Jun/2016:09:25:52 +0200] "POST /cgi-bin/php4?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%6E HTTP/1.1" 404 290 "-" "Mozilla/5.0 (iPad; CPU OS 6_0 like Mac OS X) AppleWebKit/536.26(KHTML, like Gecko) Version/6.0 Mobile/10A5355d Safari/8536.25"

13 18

[warn] eventdns: All nameservers have failed
by pa011 19 Jun '16

19 Jun '16

Jun 19 20:24:38.000 [warn] eventdns: All nameservers have failed Jun 19 20:24:38.000 [notice] eventdns: Nameserver 8.8.4.4:53 is back up I do get this in my logs on an exit (Tor 0.2.7.6) several times every hour. The /etc/resolv.conf contains # Generated by SolusVM nameserver 8.8.8.8 nameserver 8.8.4.4 Is it really best to set only one DNS like specified here https://trac.torproject.org/projects/tor/ticket/11600 ? Or are there better working solutions?

4 3

Why are you using torproject's RPMs? (was: We need a new RPM maintainer)
by nusenu 17 Jun '16

17 Jun '16

(forwarding a question from tor-dev since here are probably more ops that might want to answer the question bellow) https://lists.torproject.org/pipermail/tor-dev/2016-June/011073.html Dear tor-relay operators, are you using torproject's RPMs (instead of those provided by your distro maintainer)? If so: Nick Mathewson asked: > People who download our RPMs: in what way are they beneficial?

3 4

Tor-arm
by NotRandom Someone 16 Jun '16

16 Jun '16

Hi everyone, I have a question about monitoring a tor middle relay. What do you think about using tor-arm ? Is it safe ? (Bugs, leaks,etc) ? Or using just the informations on globe/atlas.torproject.org is more useful ? Thank you.

6 5

8 universities doing joint HS research? (2016-06-12)
by nusenu 15 Jun '16

15 Jun '16

This looks interesting, 8 new relays joined together: http://article.gmane.org/gmane.network.onion-routing.ornetradar/1373 "hsde" => hidden service discovery?

2 1