- tor-relays - lists.torproject.org

Report on the FOSDEM relays meetup
by Nicolas Braud-Santoni 10 Feb '18

10 Feb '18

Hi, I facilitated the meetup at FOSDEM, last Sunday, and I wanted to report back on what happened, and what worked (or did not). We had around 20 people, with relatively little overlap with the 34C3 meetup (I could be wrong, though, as I'm bad at recognising faces). This seems quite good, esp. considering that the 34C3 meetup was a month before, and that the meetup wasn't announced especially early (we announced ~2 weeks in advance there would be one, but the time and precise location couldn't be fixed until Sat. morning) The room configuration wasn't exactly ideal (typical lecture room, not great if you want people to talk to one another). That's something we can probably improve next year, by organising the meetup at a side-event (say, on Friday early evening) at one of the local hackerspaces or somesuch; this way, we get a better location and we could communicate time & locations much more in advance. Communication-wise, I started publishing the events in blog.tpo (thanks hiro!), which seems to have helped some people; if we organise it as a side-event next year, we shoudl also get it on their website: https://fosdem.org/2018/fringe/ Content-wise, there were some pretty fruitful discussion, but we spent quite a bit of time on questions that recurr at other meetups too: - What's the most useful thing I can bring to the network? (TL;DR: Ideally, fast relays (if possible exits); if you can't contribute more than 1MB/s, make it a bridge) - Can I run my relay on a Raspberry Pi (or similar) ? - Why does my relay (or Internet connection) die once I have TLS connections established to most other relays? (This instance was likely caused by an ISP-provided router with bad TCP connection tracking.) - Why doesn't Tor support IPv6 yet? (Feel free to add more questions if I forgot some here) Those are all somewhat simple, and I think we would definitely benefit from having better, and more visible, FAQs for those. I will try to take the time and make/improve wiki pages for those, but I wouldn't mind some help from one of the website-makers to see how we can make it more visible. Getting people to ask a bunch of questions at the start, and broadly categorizing them, as suggested by Roger last meetup, seemed to work well: we managed to cover all topics people were interested in, and were only 20 minutes over time. However, I had people shortly introduce themselves before adding their question, and that might not be so good in retrospect, as the intros took a bunch of time, and might have been an obstacle to people suggesting more questions. If people are interested, I can start collating advise on how to facilitate tor-relays meetups in some wiki page, though I'm not sure yet how to convey that “nicoo's way of relays meetup” isn't meant to be authoritative or prescriptive at all (read: I have no clue what I'm doing, but hopefully it works not too bad.) Best, nicoo

2 2

TorAtlas/Relay Search: false-positive warnings about outdated tor version eliminated
by nusenu 10 Feb '18

10 Feb '18

I'd like to highlight a small but important change Iain (Atlas developer) implemented and deployed today on atlas. Previously there was a rare edge case where atlas would say that your relay runs an outdated version (with the big red banner some of you might know) even though you actually did update your relay already. This false positive is now gone! After you update your relay you might see something like this on Atlas (under the platform field): Tor 0.2.9.14 on Linux (version is 0.2.9.12 in consensus) This is nothing you should be worried about, it is expected to happen after a version upgrade. If it stays there for more than 2 days on a running relay you might consider reaching out to this list. happy relaying, nusenu [1] http://lists.nycbug.org/pipermail/tor-bsd/2018-January/000620.html -- https://mastodon.social/@nusenu twitter: @nusenu_

1 0

Disable CellStatistics !!!
by starlight.2017q4＠binnacle.cx 09 Feb '18

09 Feb '18

After many crashes and much pain, I determined that having CellStatistics enabled causes a busy relay to consume at least two or three _gigabytes_ of additional memory. Relay operators with less than 16GB per instance are advised to disable it. By default CellStatistics is disabled unless explicitly set in torrc. CellStatistics can be turned off without restarting, via the control-channel command setconf CellStatistics=0

2 1

Disable CellStatistics to reduce RAM usage
by teor 09 Feb '18

09 Feb '18

Hi, If your relay is using too much RAM, please disable CellStatistics. (It's not on by default.) For more details, please see: https://trac.torproject.org/projects/tor/ticket/25141 https://trac.torproject.org/projects/tor/ticket/24806#comment:13 T

3 3

High processor usage - just curious
by Gary Smith 08 Feb '18

08 Feb '18

Hi, I have noticed that after a few minutes of becoming online, and randomly perhaps a couple of times every hour (??) tor uses 100 % processor on all cores for about 40/50 seconds. I am curious what is tor doing internally to need so much power? There is normally isn't more than 4 mbits going through my relay, I noticed this a while back on htop before the December load increase and on previous versions so this has got to be an "internal thing". There is no log entry when this happens. I do not think it is a bug I am just curious why it needs this much computational power, Thanks.

3 5

Exit Relay Up
by Conrad Rockenhaus 05 Feb '18

05 Feb '18

Hello All, I just brought up my third relay, ConradsOVHRelay03, as an exit. I appreciate the feedback that everyone provided me with before and I hope that this relay is configured perfectly. I’m glad to add more bandwidth to the cause. Thanks, Conrad

2 1

relayor v0.3.1 is released
by nusenu 05 Feb '18

05 Feb '18

Hi, relayor v0.3.1 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.2 FreeBSD 10.4, 11.1 HardenedBSD 11.1 Ubuntu 16.04 CentOS 7 Fedora 27 Changes since v0.3.0: ------------------------------ - support custom tor-exit-notice.html files (fixes #140) - increase tor_alpha_version: 0.3.2.x -> 0.3.3.x - Debian/Ubuntu: add support for tor nightly builds - implement per-instance ExitRelay settings (fixes #146) - make tor package state configurable (latest vs. present) regards, nusenu -- https://mastodon.social/@nusenu twitter: @nusenu_

1 0

Relays not in cached consensus
by Tyler Durden 05 Feb '18

05 Feb '18

Hi Just ~3 weeks before the 34C3, two of our newer Exits were thrown out of the consensus weight and since than never came back in. I'm talking about: geri (geri.enn.lu) 93FAB6F91C2EF33D0ACEEF7448177FCA2CEB99A0 freki (freki.enn.lu) C8AB1B2AF0CBAAE3611A814B4C7D38DCE0CBFEB4 We tried to purge the Tor installation, generate completely new keys, switched to alpha versions, switched back to stable, waited for weeks but it's always the same result. Only the authority servers moria1, longc. and dizum seem to "recognise" our exits. The logs say the same for every authority server except the 3 ones mentioned above: [info] handle_response_fetch_desc(): Received http status code 404 ("Servers unavailable") from server '154.35.175.225:80' while fetching "/tor/server/d/[__redacted__] I'll try again soon. Any ideas how to fix this? Greetings -- Frënn vun der Ënn A.S.B.L. (NGO) e. virii(a)enn.lu (GPG: 0xce8c12f32a2cf11b) t. +352-27-40-20-30-4 w. https://enn.lu/

2 2

looking for a contact possibility to reach frecy's operator
by nusenu 05 Feb '18

05 Feb '18

if you are the operator of this relay please drop me an email https://atlas.torproject.org/#details/28AB7201E1036C3B8AC7CE2E99945F8A49887… -- https://mastodon.social/@nusenu twitter: @nusenu_

1 0

chutney debugging: (Sandbox) Caught a bad syscall attempt (syscall kill)
by tor7 04 Feb '18

04 Feb '18

I'm trying chutney to measure my CPU, but it does not appear to work: chutney/tools/test-network.sh --flavour basic-min --data-bytes 104857600 test-network.sh: using CHUTNEY_DNS_CONF '/dev/null' test-network.sh: no $TOR_DIR, chutney will use $PATH for tor binaries test-network.sh: $CHUTNEY_PATH not valid, using this script's location Using Python 2.7.14 Sending SIGINT to nodes Waiting for nodes to finish. Removing stale lock file for test000a ... Removing stale lock file for test001a ... bootstrap-network.sh: bootstrapping network: basic-min Using Python 2.7.14 NOTE: creating '/home/user/chutney/tools/../net/nodes.1517749361', linking to '/home/user/chutney/tools/../net/nodes' Creating identity key /home/user/chutney/net/nodes/000a/keys/authority_identity_key for test000a with tor-gencert --create-identity-key --passphrase-fd 0 -i /home/user/chutney/net/nodes/000a/keys/authority_identity_key -s /home/user/chutney/net/nodes/000a/keys/authority_signing_key -c /home/user/chutney/net/nodes/000a/keys/authority_certificate -m 12 -a 127.0.0.1:7000 Creating identity key /home/user/chutney/net/nodes/001a/keys/authority_identity_key for test001a with tor-gencert --create-identity-key --passphrase-fd 0 -i /home/user/chutney/net/nodes/001a/keys/authority_identity_key -s /home/user/chutney/net/nodes/001a/keys/authority_signing_key -c /home/user/chutney/net/nodes/001a/keys/authority_certificate -m 12 -a 127.0.0.1:7001 Using Python 2.7.14 Starting nodes Using Python 2.7.14 test000a is running with PID 1001 test001a is running with PID 1004 test002r is running with PID 1007 test003c is running with PID 1010 4/4 nodes are running Waiting 20 seconds for a consensus containing relays to be generated... Running 1 verify rounds... Using Python 2.7.14 Verifying data transmission: (retrying for up to 60 seconds) Connecting: Exit to 127.0.0.1:4747 via client localhost:9003 Transmitting Data: Connecting: Exit to 127.0.0.1:4747 via client localhost:9003 Transmitting Data: Connecting: Exit to 127.0.0.1:4747 via client localhost:9003 Transmitting Data: Connecting: Exit to 127.0.0.1:4747 via client localhost:9003 Transmitting Data: Connecting: Exit to 127.0.0.1:4747 via client localhost:9003 Transmitting Data: Connecting: Exit to 127.0.0.1:4747 via client localhost:9003 Transmitting Data: Connecting: Exit to 127.0.0.1:4747 via client localhost:9003 Transmitting Data: Connecting: Exit to 127.0.0.1:4747 via client localhost:9003 Transmitting Data: Connecting: Exit to 127.0.0.1:4747 via client localhost:9003 Transmitting Data: Connecting: Exit to 127.0.0.1:4747 via client localhost:9003 Transmitting Data: Connecting: Exit to 127.0.0.1:4747 via client localhost:9003 Transmitting Data: Connecting: Exit to 127.0.0.1:4747 via client localhost:9003 Transmitting Data: Transmission: Failure Set CHUTNEY_DEBUG to diagnose. Completed 1 of 1 verify rounds. Using Python 2.7.14 Sending SIGINT to nodes Waiting for nodes to finish. Removing stale lock file for test000a ... Removing stale lock file for test001a ... Removing stale lock file for test002r ... Removing stale lock file for test003c ... Summary: nodes Detail: chutney/tools/warnings.sh /home/user/chutney/tools/../net/nodes.1517749361 Warning: OpenSSL version from headers does not match the version we're running with. If you get weird crashes, that might be why. (Compiled with 1010007f: OpenSSL 1.1.0g 2 Nov 2017; running with 1010007f: OpenSSL 1.1.0g-fips 2 Nov 2017). Number: 4 ------------------------ open tor listener (after starting chutney) tcp 0 0 0.0.0.0:7000 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:7001 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:7002 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:8000 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:8001 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:8002 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:5000 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:5001 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:5002 0.0.0.0:* LISTEN there is no tor on tcp port 9003, should there be one? grep 9003 chutney/net/nodes/*/torrc chutney/net/nodes/003c/torrc:SocksPort 9003 manually starting that torrc file (after setting RunAsDaemon to 0) gives: tor -f /home/user/chutney/net/nodes/003c/torrc --Log "info stdout" (Sandbox) Caught a bad syscall attempt (syscall kill) tor(+0x1853fa)[0x6141342b23fa] /lib64/libc.so.6(kill+0x7)[0x75008527ace7] /lib64/libc.so.6(kill+0x7)[0x75008527ace7] tor(+0x1c3bab)[0x6141342f0bab] /lib64/libevent-2.0.so.5(event_base_loop+0x7a9)[0x7500863853f9] tor(do_main_loop+0x29d)[0x61413417b78d] tor(tor_main+0xe25)[0x61413417e5a5] tor(main+0x19)[0x614134177009] /lib64/libc.so.6(__libc_start_main+0xea)[0x75008526488a] tor(_start+0x2a)[0x61413417705a] Tor version 0.3.1.9 upgrading to 0.3.2.9 solves the issue. https://trac.torproject.org/projects/tor/ticket/24198

2 1