- tor-relays - lists.torproject.org

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

nyx question on info on top right side, present on CentOS, missing on Debian.
by Stijn Jonker 04 Feb '18

04 Feb '18

Hi All, I initially went to the nyx website to find the right forum to ask questions. I understood this is the one :-), if not apologies. So I'm running two relays, one is running on CentOS7, the other Debian Stretch. On both I have nyx (2.0.4) installed. The "Debian" one is missing the CPU, Exit policy etc info. It's not tor version specific, as I recently upgraded the tor software on the nodes regularly. So on the CentOS node I see this on the top at the right; cpu: 61.3% tor, 5.0% nyx mem: 371 MB (12.4%) pid: 1279 uptime: 02:59:09 fingerprint: 328E54981C6DDD7D89B89E418724A4A7881E3192 exit policy: reject *:* On the Debian node it's simply not printing any of these three lines. I can't find in the (debug) logging whether an utility or library is missing. It's nothing major, but annoying. Especially with the new alpha releases it's nice to keep an eye out on mem/cpu. Does anyone have an idea what the trick is to get it to work on debian? -- CentOS info: [user@tornode ~]$ tor --version Tor version 0.3.3.1-alpha (git-de8bc9eed6eaadfc). [user@tornode ~]$ nyx --version nyx version 2.0.4 (released November 5, 2017) [user@tornode ~]$ uname -a Linux tornode.sjc.nl 3.10.0-693.17.1.el7.x86_64 #1 SMP Thu Jan 25 20:13:58 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux -- Debian info: [maint@tornode2 ~]$ tor --version Tor version 0.3.3.1-alpha-dev (git-9e48338a12fd1fef+0f23e7e96). [user@tornode2 ~]$ nyx --version nyx version 2.0.4 (released November 5, 2017) [user@tornode2 ~]$ uname -a Linux tornode2 4.9.0-5-amd64 #1 SMP Debian 4.9.65-3+deb9u2 (2018-01-04) x86_64 GNU/Linux [user@tornode2 ~]$ lsb_release -c Codename: stretch Thx, Stijn

3 5

Re: [tor-relays] atlas.torproject.org: missing updated information for relays
by nusenu 04 Feb '18

04 Feb '18

it is back now. -- https://mastodon.social/@nusenu twitter: @nusenu_

1 0

tor cpu / MBit/s benchmarks
by tor7 04 Feb '18

04 Feb '18

Hello! I'd like to collect some samples for how many MBit/s on a single tor daemon are possible on given CPU model before it is limited by the CPU. If your single tor daemon routes more than 350 MBit/s in each direction and you are running on bare metal it would be awesome if you could share your - CPU model (ideally a link to ark.intel.com if it is an intel cpu) - avg. daily CPU usage (ie. from munin graphs) - actual traffic (MBit/s) - optional: relay fingerprint thank you! tor7

3 4

Re: [tor-relays] atlas.torproject.org: missing updated information for relays
by nusenu 04 Feb '18

04 Feb '18

> searching for relays by fingerprint I always get the same information: > > Information for relays was published: 2018-02-02 19:00:00 UTC this is a known outage: https://lists.torproject.org/pipermail/tor-dev/2018-February/012881.html https://twitter.com/nusenu_/status/959764027072278529: > An outage in the @torproject infrastructure currently affects at least #CollecTor, #Onionoo and @TorAtlas. Expect relay information on @TorAtlas to be older than usual (currently stuck at 2018-02-02 19:00). -- https://mastodon.social/@nusenu twitter: @nusenu_

1 0

issue with setting up a private bridge
by Hamid Safe 04 Feb '18

04 Feb '18

2 1

Limiting connection count
by Moritz Kammerer 03 Feb '18

03 Feb '18

Hi, I'm running a Tor relay on a Raspberry 2 behind a router using port forward. Relay bandwidth is set to 1 MByte / second. Tor is accepting so many connections that my Raspi can't keep up and my router is getting very slow (I assume because of a crappy NAT implementation). Bandwidth is not an issue, its the open connection count. Is there a way to limit the maximum number of connections? I tried to apply a ulimit on open files via systemd, but Tor is then showing a warning. At the moment I run a iptables rule which restricts the connection count to port 9001 (OR port) to 1000. But I'm not sure how this will affect the relay, for example Tor Metrics is showing the relay as offline. BR, Moritz

4 4

Relays operators meetup @ FOSDEM 2018 ?
by Nicolas Braud-Santoni 03 Feb '18

03 Feb '18

Hi, I might be able to organise a relays operators meetup at FOSDEM, early February. (This is contingent on me being able to come, though.) I wanted to ask whether there are other relay operators who are planning to go, and which times would work; I made a quick poll to this effect : https://framadate.org/HpPbnRwOYNmK6D5G Feel free to add yourself without filling your availability yet, if you will be around but haven't looked at the schedule yet. I know we had the yearly meetup at 34C3 quite recently, but after discussions there it seemed like a good idea to reach out to relays operators who don't necessarily attend congress, to people who don't yet run relays but have questions, and do so in a different context than congress. Best, nicoo

2 4

measure rate of initiated HTTPs connnections
by Toralf Förster 02 Feb '18

02 Feb '18

I do wonder why the follwoing iptables rule does fire more often than expected althought there're much less (<100) new outgoing Tor exit connections within 1 second at my Tor exit relay: /sbin/iptables -A OUTPUT -p tcp --destination-port 443 --syn --match connlimit --connlimit-above 2000 --connlimit-mask 0 --connlimit-daddr --match limit --limit 1/second --limit-burst 1 -j LOG -- Toralf PGP C4EACDDE 0076E94E

2 3

75 Exit Relays (48 currently running) - AS 197226 SPRINT SA (PL) - No Contact/MyFamily
by nusenu 01 Feb '18

01 Feb '18

Dear anonymous relay operator, thank you for adding so many exit relays this month in AS 197226 SPRINT SA (PL) (netblocks 185.234.218.x and 77.87.79.x) we would really like to keep these relays on the network, but they do not have any contact information and MyFamily configuration set - which is required for such big relay groups. If you are the relay operator, please set a working contactInfo and proper MyFamily configuration and drop an email to bad-relays(a)lists.torproject.org. If they do not hear from you, tor directory authorities might decide remove these relays. It would be a shame to loose so much bandwidth. thanks for your understanding, nusenu +---------------------+-----------------+-------------+------------+---------+---------+------------------------------------------+ | first_seen | IP | tor_version | nickname | or_port | contact | fingerprint | +---------------------+-----------------+-------------+------------+---------+---------+------------------------------------------+ | 2018-01-17 22:00:00 | 185.234.218.37 | 0.3.2.9 | Ceto | 23774 | NULL | 171F6B9BBEC4EBF903CF312CB71CE554F46D8689 | | 2018-01-17 22:00:00 | 185.234.218.34 | 0.3.2.9 | Hera | 25565 | NULL | 75712D28F4744FBECAD2E67250644C7258FA71F6 | | 2018-01-17 22:00:00 | 185.234.218.36 | 0.3.2.9 | Brizo | 25595 | NULL | A44A3AF8B117665AEB200D0D60674177629EBD18 | | 2018-01-17 22:00:00 | 185.234.218.39 | 0.3.2.9 | Helios | 27365 | NULL | 625DC27C540CAE9EF37A8E8851808556AE3E4621 | | 2018-01-17 22:00:00 | 185.234.218.46 | 0.3.2.9 | Rhea | 32736 | NULL | 52E2BC36E8B333561C3F36689C1DF9A384B281AC | | 2018-01-17 22:00:00 | 185.234.218.40 | 0.3.2.9 | Hestia | 28736 | NULL | 983221B0D3E68EF8A1D0D6A1EF2DDCF0BA73F710 | | 2018-01-17 22:00:00 | 185.234.218.31 | 0.3.2.9 | Aphrodite | 25535 | NULL | 7D8EFB8923173FB89EFE457BA2A6B04D7A9C3395 | | 2018-01-17 22:00:00 | 185.234.218.35 | 0.3.2.9 | Zeus | 25575 | NULL | F8ED98209AB9E73420530AA18BABE8AABC4E7619 | | 2018-01-17 22:00:00 | 185.234.218.33 | 0.3.2.9 | Hades | 25555 | NULL | 0875C580CC0F0F7E57727AC3C2233F5E6A58AE28 | | 2018-01-17 22:00:00 | 185.234.218.42 | 0.3.2.9 | Pallas | 30263 | NULL | D3E518F3749F9FC398261EC60B00B3B1D7535E42 | | 2018-01-17 22:00:00 | 185.234.218.38 | 0.3.2.9 | Chaos | 26536 | NULL | 1C49F07147A9113583190D38E58BA40DBECFB9F7 | | 2018-01-17 22:00:00 | 185.234.218.43 | 0.3.2.9 | Styx | 28736 | NULL | D6FC8F1E0FB2FC3AC4634FC26E4E1E4D7E1FB558 | | 2018-01-17 22:00:00 | 185.234.218.41 | 0.3.2.9 | Nyx | 29096 | NULL | 8B200C067525B70930C4D6CB5DE4C7320B0418AC | | 2018-01-17 22:00:00 | 185.234.218.44 | 0.3.2.9 | Tyche | 29736 | NULL | F76368EC7009FB98F81544473B2F709859FB5327 | | 2018-01-17 22:00:00 | 185.234.218.32 | 0.3.2.9 | Apollo | 25545 | NULL | 830227075292332360349D7A5842B1125004DC6D | | 2018-01-17 22:00:00 | 185.234.218.45 | 0.3.2.9 | Uranus | 31837 | NULL | 01F6F2FA7921681EF6CF9DD327D8E1531B249B78 | | 2018-01-17 23:00:00 | 77.87.79.46 | 0.3.2.9 | Artemis | 29384 | NULL | 65B2D3A0E002704B32B751C4238983D83297E5FB | | 2018-01-17 23:00:00 | 185.234.218.49 | 0.3.2.9 | Maia | 32736 | NULL | ECC5026169EDC6012244B06C2C8C9E90A4574077 | | 2018-01-17 23:00:00 | 77.87.79.49 | 0.3.2.9 | Astra | 29374 | NULL | B4FEC3BD7FF7D269490A5DDCD5B96799BC46489A | | 2018-01-17 23:00:00 | 185.234.218.50 | 0.3.2.9 | Heracles | 31945 | NULL | 94D951D305DEFBBF2552BBDD9C919B09633DDA24 | | 2018-01-17 23:00:00 | 77.87.79.47 | 0.3.2.9 | Hypnos | 25363 | NULL | 537DD2E2D2F026FA9CD210E4B854584762DD9DB6 | | 2018-01-17 23:00:00 | 185.234.218.48 | 0.3.2.9 | Proteus | 28373 | NULL | 7F6DF29D2E0A82834E45AC210990B855802752B6 | | 2018-01-17 23:00:00 | 185.234.218.47 | 0.3.2.9 | Peitha | 28342 | NULL | 6716D11B3D43EA12EC883AA45A600EA277946A39 | | 2018-01-18 00:00:00 | 77.87.79.59 | 0.3.2.9 | Charon | 32734 | NULL | 7868248CD8FEE709AEAC0D13F1E30F79EC02D4C4 | | 2018-01-18 00:00:00 | 77.87.79.60 | 0.3.2.9 | Nemesis | 27364 | NULL | 54DC9A823CDFAB833590B4E4AE7EC386F38E2EB2 | | 2018-01-18 00:00:00 | 77.87.79.56 | 0.3.2.9 | Sirens | 35736 | NULL | AA545B49FE9AE5FC4B2295330E77EAD7BA228AEC | | 2018-01-18 00:00:00 | 77.87.79.52 | 0.3.2.9 | Erotes | 28374 | NULL | 36876E90176DBE3395A3EE8A2584FE7C3513C3C6 | | 2018-01-18 00:00:00 | 77.87.79.57 | 0.3.2.9 | Eleus | 28374 | NULL | F47044B9A265994F17EE02FBDA2046DB1A48E6F6 | | 2018-01-18 00:00:00 | 77.87.79.55 | 0.3.2.9 | Doris | 33625 | NULL | 9D30457253C5F43AAF38D6356C2B1E8CE4D4672D | | 2018-01-18 00:00:00 | 77.87.79.53 | 0.3.2.9 | Astra | 34948 | NULL | C486FA81814E1EA9E6B4585205816B6CBF96445F | | 2018-01-18 00:00:00 | 77.87.79.54 | 0.3.2.9 | Selene | 34837 | NULL | 6B8FDB5B3CFBB68DCC553922268EF0587BAB44B0 | | 2018-01-18 00:00:00 | 77.87.79.64 | 0.3.2.9 | Cybele | 39475 | NULL | CEB93C2E3D2876FF62BA0DC2F21808346E36270A | | 2018-01-18 00:00:00 | 77.87.79.51 | 0.3.2.9 | Elysium | 26374 | NULL | 34D18949F03875F6B1FCC4F6418CE10137BA7942 | | 2018-01-18 00:00:00 | 77.87.79.61 | 0.3.2.9 | Adriane | 39374 | NULL | BD37B322CE0EF1ACA6B7FDD0D66F54504C053BF5 | | 2018-01-18 00:00:00 | 77.87.79.58 | 0.3.2.9 | Theia | 37845 | NULL | 594252BFEE13625AC120F50F3015CB3C1DA55690 | | 2018-01-18 00:00:00 | 77.87.79.62 | 0.3.2.9 | Ino | 27364 | NULL | 02B2B98F879CFC70313BB20C4A88AE150E121DFD | | 2018-01-18 00:00:00 | 77.87.79.63 | 0.3.2.9 | Cotys | 34273 | NULL | 10E609E88024C1DB1E8D701602F254C0E8A7576E | | 2018-01-18 01:00:00 | 77.87.79.65 | 0.3.2.9 | Acheron | 35334 | NULL | 94FA1F71A8192C4337F734EC911FBA846045AB54 | | 2018-01-18 01:00:00 | 77.87.79.68 | 0.3.2.9 | Ourea | 27364 | NULL | A75AAE0B7C4A394F3E67DE31E2185EF37F439A5B | | 2018-01-18 01:00:00 | 77.87.79.70 | 0.3.2.9 | Cronus | 34567 | NULL | CAD689550FF6D332698E3687CD0DC40B2475CB38 | | 2018-01-18 01:00:00 | 77.87.79.67 | 0.3.2.9 | Dione | 35334 | NULL | E7C04B1DDE6DFA350A275E88D8612A5380020667 | | 2018-01-18 01:00:00 | 77.87.79.66 | 0.3.2.9 | Atlas | 36543 | NULL | CA318FEF4A3274CBF89416FD580C8B64D6A7589F | | 2018-01-18 01:00:00 | 77.87.79.48 | 0.3.2.9 | Nike | 28376 | NULL | A201E6FAC690713EB25AAE42A18D4C7E277C3B73 | | 2018-01-18 01:00:00 | 77.87.79.69 | 0.3.2.9 | Themis | 29374 | NULL | DCE904F85AC6E399455E9E41584B582CC71B65E8 | | 2018-01-26 01:00:00 | 185.234.218.225 | 0.3.2.9 | Gala | 9001 | NULL | D568DDFC9EB8990DB407ADB727DE07A51D835084 | | 2018-01-26 01:00:00 | 185.234.218.229 | 0.3.2.9 | Pluto | 9001 | NULL | 4A8B675A0B3C1D6454DBE7A2BD25BF039F596C8F | | 2018-01-26 01:00:00 | 185.234.218.222 | 0.3.2.9 | Chronos | 9001 | NULL | 5C6CA8731F14EFEFEF809533847FD560FB7A9CDA | | 2018-01-26 01:00:00 | 185.234.218.231 | 0.3.2.9 | Asclepius | 9001 | NULL | BBEE2C18269C474539F30016CE427FA5C8D6EB81 | | 2018-01-26 01:00:00 | 185.234.218.237 | 0.3.2.9 | Falacer | 9001 | NULL | 0267D63ECED91B436E697A6A09EEBC10EF1834B4 | | 2018-01-26 01:00:00 | 185.234.218.226 | 0.3.2.9 | Hephaestus | 9001 | NULL | 9BEBB4DA55DC8C29289FC8929D32B5AC36FEB3E1 | | 2018-01-26 01:00:00 | 185.234.218.224 | 0.3.2.9 | Eros | 9001 | NULL | B95EE27634948F7AB399A1E6E43595A9C07B8A75 | | 2018-01-26 01:00:00 | 185.234.218.221 | 0.3.2.9 | Asclepius | 9001 | NULL | A7B317D3E45882524B071FF26D02ED5CA3896A94 | | 2018-01-26 01:00:00 | 185.234.218.227 | 0.3.2.9 | Rea | 9001 | NULL | 93EA7712DADE2D903A63241C028CDC61828B6474 | | 2018-01-26 01:00:00 | 185.234.218.230 | 0.3.2.9 | Caelus | 9001 | NULL | 63829EB51C9E731A1B842CBB887B30F28141C636 | | 2018-01-26 01:00:00 | 185.234.218.232 | 0.3.2.9 | Diana | 9001 | NULL | 49D2098FFC4E19F387E6180EEAD8F59EF3F49E3C | | 2018-01-26 01:00:00 | 185.234.218.235 | 0.3.2.9 | Ops | 9001 | NULL | D6EA61F4D08F60278AAFC867EEF7BFFD62693689 | | 2018-01-26 01:00:00 | 185.234.218.234 | 0.3.2.9 | Mercury | 9001 | NULL | 407C9F6C0765C30734798999B3F61F9DA44BAACF | | 2018-01-26 01:00:00 | 185.234.218.238 | 0.3.2.9 | Fiora | 9001 | NULL | D9BF6019077878703EF6534B23D2136598E4D09E | | 2018-01-26 01:00:00 | 185.234.218.223 | 0.3.2.9 | Dionysus | 9001 | NULL | 3AEEC2D6F168CC59F46F62531BDF234F5066C30D | | 2018-01-26 01:00:00 | 185.234.218.228 | 0.3.2.9 | Somnus | 9001 | NULL | AE8F5B743EA1D772FD1017CF3DE070FE0CB0A702 | | 2018-01-26 01:00:00 | 185.234.218.236 | 0.3.2.9 | Vesta | 9001 | NULL | FC9AE0DD0B4A03ACA845A534A29B1442B2CB1654 | | 2018-01-26 02:00:00 | 185.234.218.248 | 0.3.2.9 | Pales | 9001 | NULL | 7779110F487C0F1C399321848D7879F16CFB7933 | | 2018-01-26 02:00:00 | 185.234.218.250 | 0.3.2.9 | Fides | 9001 | NULL | F92479656F51E2C0C29935F75AFE94921D77E8D5 | | 2018-01-26 02:00:00 | 185.234.218.242 | 0.3.2.9 | Diana | 9001 | NULL | 742C08BD99FC849BF641331C8A0E5B198CA058D0 | | 2018-01-26 02:00:00 | 185.234.218.244 | 0.3.2.9 | Sol | 9001 | NULL | 80F620ABA515A928CBE2D043B4253536F022EF16 | | 2018-01-26 02:00:00 | 185.234.218.249 | 0.3.2.9 | Vediovis | 9001 | NULL | FDDF7F36DDD254FDEAE5127F595C5DA0A571034A | | 2018-01-26 02:00:00 | 185.234.218.246 | 0.3.2.9 | Larunda | 9001 | NULL | 17E0D5E328FD6A06D3BD1A1CCB190682D038A7AA | | 2018-01-26 02:00:00 | 185.234.218.241 | 0.3.2.9 | Lucina | 9001 | NULL | 3EEA0DD81D8C4CE243E991538E47CA32EFF5CCC4 | | 2018-01-26 02:00:00 | 185.234.218.239 | 0.3.2.9 | Vulcan | 9001 | NULL | 8726F9C47A3703A1F0D79626CDCB0CF0DEB0FDBC | | 2018-01-26 02:00:00 | 185.234.218.240 | 0.3.2.9 | Lares | 9001 | NULL | 084AC15FD4FC3F1229A994D8E8F8ABE8FDD77E97 | | 2018-01-26 02:00:00 | 185.234.218.247 | 0.3.2.9 | Feronia | 9001 | NULL | 83F72AB24DE1EC398FF5828C9DB19A6357E573DC | | 2018-01-26 02:00:00 | 185.234.218.243 | 0.3.2.9 | Fons | 9001 | NULL | 5B06421F56248CED92212987F72D27BB4F0BB3C2 | | 2018-01-26 02:00:00 | 185.234.218.233 | 0.3.2.9 | Mars | 9001 | NULL | 25E7317FC422673C537221860B16DD1B3283B88C | | 2018-01-26 02:00:00 | 185.234.218.245 | 0.3.2.9 | Luna | 9001 | NULL | F4DA978E63B181C60C4FC206E9274D46810489ED | | 2018-01-30 23:00:00 | 185.234.218.33 | 0.3.2.9 | Hades | 25555 | NULL | A7F34E65DD14F72E237760216CCB65A99EB9BE59 | +---------------------+-----------------+-------------+------------+---------+---------+------------------------------------------+ -- https://mastodon.social/@nusenu twitter: @nusenu_

3 5

High number of simultaneous connections from a single host
by zless 01 Feb '18

01 Feb '18

Hello everyone, I was inspecting my node and just saw that it has a very high number of connections. It jumped from the normal 6000-7000 to more than 17000 simultaneous connections. Looking at the connections with `ss` I see some hosts with over 1000 connections while the majority is usually bellow 10. Here are some stats with the IP and the associated number of simultaneous connections: 212.32.226.237 : 1531 207.244.110.200 : 1520 162.210.192.70 : 1471 207.244.70.120 : 1455 198.7.59.194 : 1454 212.32.239.28 : 1450 5.79.103.239 : 1414 5.79.103.238 : 1401 51.15.162.120 : 1379 37.48.104.231 : 56 5.79.72.66 : 26 37.48.105.240 : 25 212.83.3.154 : 25 78.46.99.242 : 23 178.63.47.145 : 18 46.4.84.142 : 17 213.133.100.55 : 17 46.4.106.87 : 15 144.76.18.214 : 14 Is it normal for a single host to produce so many connections? How do you people handle such situations? Thanks

5 5

What's the priority right now?
by Conrad Rockenhaus 01 Feb '18

01 Feb '18

I’m ready to get node #3 up right now…so what’s the priority for high speed nodes right now, exits or relays? Just wanted to know before I brought it online. This one is based in the great land of Canada :D. Thanks, Conrad

3 2

0.3.2.9 not reporting bandwidth in atlas
by Paul Templeton 31 Jan '18

31 Jan '18

Is it me or is there some issue. Since I've upgraded to version 0.3.2.9 there has been no update to the bandwidth graphs. family:867B95CACD64653FEEC4D2CEFC5C49B4620307A7 Paul 609662E824251C283164243846C035C803940378

3 2

MyFamily and ContactInfo fields are required for operators running multiple tor instances
by nusenu 31 Jan '18

31 Jan '18

Hi, I'd like to highlight that today the following two sentences requiring ContactInfo and MyFamily for operators running multiple relays got added to the tor manual page [1]: > ContactInfo **must** be set to a working address if you run more than one > relay or bridge. (Really, everybody running a relay or bridge should set > it.) > > > MyFamily **must** be set correctly if you run more than one relay or > bridge. (That is, every relay should list all the others as described > above.) The main motivation for this change have been suspicious tor relays that bad-relays@ ML decided to remove but had no way direct way to contact and so was forced to make hard decisions. With these clear statements bad-relays@ ML group can handle problematic cases better. regards, nusenu [1] https://gitweb.torproject.org/tor.git/tree/doc/tor.1.txt#n1717 -- https://mastodon.social/@nusenu twitter: @nusenu_

6 8

Tor uses up all available memory and eventually quits
by georgemaschke＠posteo.de 31 Jan '18

31 Jan '18

I am running a Tor (0.2.5.16 on Debian Linux) relay on a VPS with one gigabyte of RAM and no swap partition or swap file. The hosting company states that it doesn't support swap in order to prolong the life of its solid state drives. Tor gradually uses up more and more memory until its percentage usage is in the high 90s. Then Tor quits. This happens within about 48 hours of launch. What can I do to resolve this problem? Thanks! George W. Maschke https://georgemaschke.net

6 7

#2667 [Core Tor/Tor]: Exits should block reentry into the tor network
by nusenu 31 Jan '18

31 Jan '18

> Comment (by arma): > > I continue to think that teaching exit relays to avoid allowing exit > connections to known relays (IP:ORPort) is a good and useful step. > > We keep running across messy situations where letting somebody connect to > a relay from an exit relay's IP address turns into a security surprise. Does that mean that exits will no longer be able to run tor clients (ie. to run apt updates via tor)? -- https://mastodon.social/@nusenu twitter: @nusenu_

2 2

Attack or issue? 4 / 11 M of traffic
by Stijn Jonker 30 Jan '18

30 Jan '18

Hi All, Since around midnight CET, my relay who was happily running almost the same amount of traffic in and outbound, has dropped to 4 Meg in, 11 Meg out according to SNMP on the host. (Cap: 10M/peak 12.5M). Lots of messages like: - Channel padding timeout scheduled 304317ms in the past. - Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [45685 similar message(s) suppressed in last 60 seconds] Any suggestions what to check / verify for this? 328E54981C6DDD7D89B89E418724A4A7881E3192 Thx, Stijn

2 1

How to post to this list
by grarpamp 30 Jan '18

30 Jan '18

1) DO NOT Top Post, backwards it's because that's, reply below what you're replying to. 2) DO NOT Bulk Quote, trim what you're replying to down to the minimum size needed to convey the relavant context. 3) DO NOT Block Reply, piecewise interleave your replies below each piece of context to which you are replying. 4) DO NOT send HTML, set you rmailer to compose and send plain text emails. Far too many breaking basic "email netiquette" lately. Learn more by searching that quote.

4 5

tor on arm vps
by Quintin 29 Jan '18

29 Jan '18

I see online.net has a lot of ARM VPSes. Does tor run fine on these? Q -- 0101100101000001010010000101011101000101010010000010000001000010 0100110001000101010100110101001100100000010110010100111101010101

3 11

A lot of Warn messages when bootstrapping Tor 0.3.2.9 (stable)
by Dark Matter 29 Jan '18

29 Jan '18

Hello, I'm running a tor-relay with Tor version 0.3.2.9 (stable). I had to do some daemon restarts, because of connection limit issues. Since the last two restarts the Tor process issues a lot of warnings while bootstrapping, because it could not create a (client) circuit. Relay functionality is working without problems. Before these restarts I had no problems connecting to the tor network and creating circuits. Tor usually booted within less than a minute without warnings. I found a ticket describing the same problem (although for a different Tor version) here: https://trac.torproject.org/projects/tor/ticket/24639. Are there any known workarounds yet? For more detail, I'll post the last warning messages: Jan 25 18:31:54.000 [warn] Problem bootstrapping. Stuck at 90%: Establishing a Tor circuit. (Connection timed out; TIMEOUT; count 1503; recommendation warn; host B7047FBDE9C53C39011CA84E5CB2A8E3543066D0 at 199.249.223.60:443) Jan 25 18:31:54.000 [warn] 1503 connections have failed: Jan 25 18:31:54.000 [warn] 1026 connections died in state connect()ing with SSL state (No SSL object) Jan 25 18:31:54.000 [warn] 392 connections died in state handshaking (TLS) with SSL state SSLv2/v3 read server hello A in HANDSHAKE Jan 25 18:31:54.000 [warn] 84 connections died in state handshaking (Tor, v3 handshake) with SSL state SSL negotiation finished successfully in OPEN Jan 25 18:31:54.000 [warn] 1 connections died in state handshaking (TLS) with SSL state unknown state in HANDSHAKE Tor had to try to open a circuit for more than half an hour before finally succeeding... Regards, Dark

3 2

The Onion Box: Connections
by Ralph Wetzel 28 Jan '18

28 Jan '18

3 2

Upgraded relay non show in ATLAS
by MLTor Node 27 Jan '18

27 Jan '18

6 11