- tor-relays - lists.torproject.org

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 31 Jan '18

31 Jan '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 28 Jan '18

28 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

>30% of the Tor network runs outdated version: Consider enabling auto-updates
by nusenu 27 Jan '18

27 Jan '18

Hi, when writing the content for the Tor Relay Guide we also collected steps to enable auto updates for various Linux distributions. The motivation for this is that there are a lot of relays (>3000) running outdated tor releases. If more operators enable auto-updates the number of outdated tor relays hopefully decreases. https://trac.torproject.org/projects/tor/wiki/TorRelayGuide#AutomaticSoftwa… Debian: https://trac.torproject.org/projects/tor/wiki/TorRelayGuide/DebianUbuntuUpd… RPM Distros: https://trac.torproject.org/projects/tor/wiki/TorRelayGuide/RPMUpdates thanks, nusenu -- https://mastodon.social/@nusenu twitter: @nusenu_

7 11

debugging unbound on 'torexit' failing DNS queries
by nusenu 26 Jan '18

26 Jan '18

<tor-admin(a)portaltodark.world> wrote: > Resent under the correct alias. > > I'm having high amounts of failures on this VPS (PulseServers). I run a > local unbound instance, and see an incredible amount of: > Jan 17 19:27:33 torexit unbound: [559:0] notice: sendto failed: Operation > not permitted > Jan 17 19:27:33 torexit unbound: [559:0] notice: remote address is > 198.97.190.53 port 53 > Jan 17 19:27:33 torexit unbound: [559:0] notice: sendto failed: Operation > not permitted > Jan 17 19:27:33 torexit unbound: [559:0] notice: remote address is > 192.42.93.30 port 53 > Jan 17 19:27:33 torexit unbound: [559:0] notice: sendto failed: Operation > not permitted > Jan 17 19:27:33 torexit unbound: [559:0] notice: remote address is > 192.35.51.30 port 53 > Jan 17 19:27:33 torexit unbound: [559:0] notice: sendto failed: Operation > not permitted > > To give proportion to "incredible amount", > Jan 17 19:21:32 torexit rsyslogd: imjournal: 9897 messages lost due to > rate-limiting > Jan 17 19:22:02 torexit journal: Suppressed 1216 messages from > /system.slice/unbound.service > Jan 17 19:22:32 torexit journal: Suppressed 1209 messages from > /system.slice/unbound.service > Jan 17 19:23:02 torexit journal: Suppressed 1827 messages from > /system.slice/unbound.service > Jan 17 19:23:32 torexit journal: Suppressed 2333 messages from > /system.slice/unbound.service > Jan 17 19:24:02 torexit journal: Suppressed 3029 messages from > /system.slice/unbound.service > Jan 17 19:24:32 torexit journal: Suppressed 2822 messages from > /system.slice/unbound.service > Jan 17 19:25:02 torexit journal: Suppressed 2715 messages from > /system.slice/unbound.service > Jan 17 19:25:32 torexit journal: Suppressed 3166 messages from > /system.slice/unbound.service > Jan 17 19:26:02 torexit journal: Suppressed 4093 messages from > /system.slice/unbound.service > Jan 17 19:26:32 torexit journal: Suppressed 45878 messages from > /system.slice/unbound.service > Jan 17 19:27:02 torexit journal: Suppressed 30125 messages from > /system.slice/unbound.service > Jan 17 19:27:32 torexit journal: Suppressed 31764 messages from > /system.slice/unbound.service > Jan 17 19:28:02 torexit journal: Suppressed 31229 messages from > /system.slice/unbound.service > > Could it be limits from the VPS provider on the amount of outbound udp/53 > connections? To me this looks more like a local problem? Are you doing any packet filtering on the host (outbound)? Does DNS work on that host if you try manual queries? From the IPs in your logs I assume your unbound is configured to query recursively itself (no upstream forwarding) that is good, can you confirm that and provide your unbound config + iptalbes -vnL? -- https://mastodon.social/@nusenu twitter: @nusenu_

4 13

Re: [tor-relays] A lot of Warn messages when bootstrapping
by Dark Matter 26 Jan '18

26 Jan '18

Thanks for the fast reply! > Your relay has probably chosen some overloaded guards. > The problem comes from the extra load on those machines, not your relay. > Your relay will eventually try other guards. > > Are you sure it's not overloaded? > It might be worth checking the logs, inbound connections, RAM, and CPU > after it has been running for a few days. Yes, the relay is working fine - the only problem was the connection limit due to some OS-level limits.which is why I had to restart the relay in the first place. > Ignore the warning messages unless your relay is having problems. Ok, I'll do :) Once one successful circuit was established, there were no warnings any more. It just took some time - but I cannot tell if the relay switched guards or if the guard nodes finally managed to accept a connection request, since I didn't check the guard node set prior to restarting. Regards, Dark

1 0

No graph update for my relay in ATLAS
by Peter Ott 26 Jan '18

26 Jan '18

Hi, it seems that the graph in ATLAS (1 month and 3 months) for my relay isn't updated any longer for the graph 'read.' and 'written bytes per second' (last info was of 2018-01-01). The graph for 'consensus weight', 'middle probability' etc. seems to be ok. During startup of TOR (running it on Windows 10 / x64) the DirPort and the ORPort is reachable. Any idea? Btw how long must the relay be 'up' to get the 'stable' or 'guard' flag granted. My relay is now online for 46 days -only restarted for a TOR release upgrade-. A change of the IP-adress seems to be handled fine by TOR. This change by the ISP occurs at least every 3 days or so). Thanks in advance and best regards Peter Relay TRUMPER FP: 12DFC9D1852979939D9317F57A857C80BC73165E

4 6

Advertised Bandwidth
by MarkIt8Dude 25 Jan '18

25 Jan '18

Hi all, I’d like to understand something about Advertised Bandwidth. I set up my Tor Relay 3 months ago. With the following settings : RelayBandwidthRate 1250 KBytes RelayBandwidthBurst 1450 KBytes But i only get and Advertised Bandwidth of 83.79 KiB/s. Very far from my settings. And also it makes me think that my relay is completely useless …☹ Any suggestions ? Thx,

3 2

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

25 Jan '18

Hi to all! i have a little relay running in my home LAN on Windows 2016 server (MLTorNode, FE4033D750831C32A957174ADD11E40F558A14A9). A few days ago, i create two VLan on my home network, one dedicated for my Tor relay. Today i updated service to 3.2.9 release. After starting tor service, log say that Orport and DIRport are reachable from outside, so it seems to be working without problems. But if i query Atlas, my node seems to be down from 5 days. The IP showed in Atlas is old (i have dynamic IP and dynamic DNS). I stop and start several times service with no luck. Anyone can help me? My node is small, but i like very much Tor and i want to continue contributing to the project. -- Marlenio (MLTorNode) FE4033D750831C32A957174ADD11E40F558A14A9

2 3

Middle relays stopping because of "SYN flood"?
by Christian Krbusek 25 Jan '18

25 Jan '18

Dear list, recently I´m facing issues with my 4 middle relays: B1E889E8EA604D81326F5071E0ABF1B2B16D5DAB FC9AC8EA0160D88BCCFDE066940D7DD9FA45495B BDB9EBCB1C2A424973A240C91EEC082C3EB61626 ACD889D86E02EDDAB1AFD81F598C0936238DC6D0 All of them running v0.3.2.9 on Debian stretch (kvm, 2 cores, 2GB RAM) and stopping with the log entries below. I can´t remember when this started but I´m quite sure it did not happen a few month ago. There have not been any recent changes on the hardwarenode or on the VMs. All of them running the "same" configuration created by ansible-relayor - one example below. The VMs are running at the time the relays go offline and even a network restart doesn´t fix the issue so I have to restart the VM to get the relays up and running again. Any hints would be much appreciated, if any more infos are needed just ask. Cheers, Christian >>>>> CONFIG START <<<<< # ansible-relayor generated torrc configuration file # Note: manual changes will be OVERWRITTEN on the next ansible-playbook run OfflineMasterKey 1 RunAsDaemon 0 Log notice syslog OutboundBindAddress 188.118.198.244 SocksPort 0 User _tor-188.118.198.244_443 DataDirectory /var/lib/tor-instances/188.118.198.244_443 ORPort 188.118.198.244:443 DirPort 188.118.198.244:80 SyslogIdentityTag 188.118.198.244_443 ControlSocket /var/lib/tor-instances/188.118.198.244_443/controlsocket Nickname ph3x Sandbox 1 ExitRelay 0 ExitPolicy reject *:* ContactInfo 4096R/0x73538126032AD297 Christian Krbusek <abuse AT ph3x DOT at> - 1NtneNxb8awwH8woJ7oL7UVj1SJDpAn8Kc RelayBandwidthRate 15 MB RelayBandwidthBurst 30 MB NumCPUs 2 MyFamily acd889d86e02eddab1afd81f598c0936238dc6d0,b1e889e8ea604d81326f5071e0abf1b2b16d5dab,bdb9ebcb1c2a424973a240c91eec082c3eb61626,fc9ac8ea0160d88bccfde066940d7dd9fa45495b # end of torrc >>>>> CONFIG END <<<<< >>>>> LOGS START <<<<< at-vie01a-tor01.ph3x.at: Jan 25 17:58:24 at-vie01a-tor01 Tor-86.59.119.83_443[540]: Since startup, we have initiated 0 v1 connections, 0 v2 connections, 0 v3 connections, and 8629 v4 connections; and receiv ed 60 v1 connections, 4568 v2 connections, 9249 v3 connections, and 403685 v4 connections. Jan 25 18:00:17 at-vie01a-tor01 kernel: [64938.876706] TCP: too many orphaned sockets Jan 25 18:01:06 at-vie01a-tor01 kernel: [64987.773119] TCP: too many orphaned sockets Jan 25 18:01:06 at-vie01a-tor01 kernel: [64987.774838] TCP: too many orphaned sockets Jan 25 18:01:06 at-vie01a-tor01 kernel: [64987.786154] TCP: too many orphaned sockets Jan 25 18:01:06 at-vie01a-tor01 kernel: [64987.786189] TCP: too many orphaned sockets Jan 25 18:01:06 at-vie01a-tor01 kernel: [64987.786235] TCP: too many orphaned sockets Jan 25 18:01:06 at-vie01a-tor01 kernel: [64987.786250] TCP: too many orphaned sockets Jan 25 18:01:06 at-vie01a-tor01 kernel: [64987.786315] TCP: too many orphaned sockets Jan 25 18:01:06 at-vie01a-tor01 kernel: [64987.786333] TCP: too many orphaned sockets Jan 25 18:01:06 at-vie01a-tor01 kernel: [64987.786391] TCP: too many orphaned sockets Jan 25 18:01:06 at-vie01a-tor01 kernel: [64987.786411] TCP: too many orphaned sockets Jan 25 18:01:15 at-vie01a-tor01 kernel: [64997.053055] net_ratelimit: 2 callbacks suppressed Jan 25 18:01:15 at-vie01a-tor01 kernel: [64997.053056] TCP: too many orphaned sockets Jan 25 18:01:16 at-vie01a-tor01 kernel: [64998.301030] TCP: too many orphaned sockets Jan 25 18:01:16 at-vie01a-tor01 kernel: [64998.365099] TCP: too many orphaned sockets Jan 25 18:01:17 at-vie01a-tor01 kernel: [64998.557033] TCP: too many orphaned sockets Jan 25 18:01:18 at-vie01a-tor01 kernel: [64999.805082] TCP: too many orphaned sockets Jan 25 18:01:27 at-vie01a-tor01 kernel: [65009.277179] TCP: too many orphaned sockets Jan 25 18:01:28 at-vie01a-tor01 kernel: [65009.533307] TCP: too many orphaned sockets Jan 25 18:01:28 at-vie01a-tor01 kernel: [65009.533678] TCP: too many orphaned sockets Jan 25 18:01:28 at-vie01a-tor01 kernel: [65009.533697] TCP: too many orphaned sockets Jan 25 18:01:28 at-vie01a-tor01 kernel: [65009.533820] TCP: too many orphaned sockets Jan 25 18:01:28 at-vie01a-tor01 kernel: [65009.534615] TCP: too many orphaned sockets Jan 25 18:01:28 at-vie01a-tor01 kernel: [65009.535200] TCP: too many orphaned sockets Jan 25 18:01:28 at-vie01a-tor01 kernel: [65009.535460] TCP: too many orphaned sockets Jan 25 18:01:28 at-vie01a-tor01 kernel: [65009.535708] TCP: too many orphaned sockets Jan 25 18:01:28 at-vie01a-tor01 kernel: [65009.536685] TCP: too many orphaned sockets Jan 25 18:01:34 at-vie01a-tor01 kernel: [65015.677629] net_ratelimit: 11 callbacks suppressed Jan 25 18:01:34 at-vie01a-tor01 kernel: [65015.677661] TCP: too many orphaned sockets Jan 25 18:01:34 at-vie01a-tor01 kernel: [65015.677910] TCP: too many orphaned sockets Jan 25 18:01:34 at-vie01a-tor01 kernel: [65015.677989] TCP: too many orphaned sockets Jan 25 18:01:34 at-vie01a-tor01 kernel: [65015.680478] TCP: too many orphaned sockets Jan 25 18:01:34 at-vie01a-tor01 kernel: [65015.680857] TCP: too many orphaned sockets Jan 25 18:01:34 at-vie01a-tor01 kernel: [65015.682767] TCP: too many orphaned sockets Jan 25 18:01:34 at-vie01a-tor01 kernel: [65015.682832] TCP: too many orphaned sockets Jan 25 18:01:34 at-vie01a-tor01 kernel: [65015.682953] TCP: too many orphaned sockets Jan 25 18:01:34 at-vie01a-tor01 kernel: [65015.683033] TCP: too many orphaned sockets Jan 25 18:01:34 at-vie01a-tor01 kernel: [65015.683041] TCP: too many orphaned sockets Jan 25 18:02:13 at-vie01a-tor01 kernel: [65054.590190] net_ratelimit: 6 callbacks suppressed Jan 25 18:02:13 at-vie01a-tor01 kernel: [65054.590194] TCP: too many orphaned sockets Jan 25 18:02:13 at-vie01a-tor01 kernel: [65054.597927] TCP: too many orphaned sockets Jan 25 18:05:15 at-vie01a-tor01 kernel: [65237.086196] TCP: request_sock_TCP: Possible SYN flooding on port 443. Sending cookies. Check SNMP counters. Jan 25 18:17:01 at-vie01a-tor01 CRON[24416]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) Jan 25 18:57:09 at-vie01a-tor01 systemd[1]: Stopped target Timers. at-vie01a-tor02.ph3x.at: Jan 25 10:17:01 at-vie01a-tor02 CRON[19123]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) Jan 25 11:17:01 at-vie01a-tor02 CRON[23992]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) Jan 25 11:59:10 at-vie01a-tor02 Tor-86.59.119.88_443[509]: Heartbeat: Tor's uptime is 11:59 hours, with 38342 circuits open. I've sent 218.94 GB and received 192.87 GB. Jan 25 11:59:10 at-vie01a-tor02 Tor-86.59.119.88_443[509]: Circuit handshake stats since last time: 88566/90206 TAP, 12299213/12353484 NTor. Jan 25 11:59:10 at-vie01a-tor02 Tor-86.59.119.88_443[509]: Since startup, we have initiated 0 v1 connections, 0 v2 connections, 0 v3 connections, and 6295 v4 connections; and receiv ed 60 v1 connections, 3085 v2 connections, 6040 v3 connections, and 300693 v4 connections. Jan 25 12:17:01 at-vie01a-tor02 CRON[28856]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) Jan 25 12:18:28 at-vie01a-tor02 kernel: [44384.957658] TCP: request_sock_TCP: Possible SYN flooding on port 443. Sending cookies. Check SNMP counters. Jan 25 13:17:01 at-vie01a-tor02 CRON[28998]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) Jan 25 14:17:01 at-vie01a-tor02 CRON[29061]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) Jan 25 14:36:57 at-vie01a-tor02 ntpd[490]: Soliciting pool server 185.144.161.170 Jan 25 14:37:05 at-vie01a-tor02 ntpd[490]: Soliciting pool server 2a02:1748:0:1500:3::2005 Jan 25 14:37:16 at-vie01a-tor02 ntpd[490]: error resolving pool 1.debian.pool.ntp.org: Temporary failure in name resolution (-3) Jan 25 14:37:36 at-vie01a-tor02 ntpd[490]: error resolving pool 0.debian.pool.ntp.org: Temporary failure in name resolution (-3) at-vie01a-tor03.ph3x.at: Jan 24 13:21:18 at-vie01a-tor03 systemd[1]: apt-daily.timer: Adding 9h 35min 45.841113s random time. Jan 24 13:24:24 at-vie01a-tor03 kernel: [62694.054136] TCP: request_sock_TCP: Possible SYN flooding on port 443. Sending cookies. Check SNMP counters. Jan 24 13:59:57 at-vie01a-tor03 Tor-78.142.140.242_443[517]: Heartbeat: Tor's uptime is 17:59 hours, with 0 circuits open. I've sent 314.59 GB and received 317.28 GB. Jan 24 13:59:57 at-vie01a-tor03 Tor-78.142.140.242_443[517]: Circuit handshake stats since last time: 35924/36525 TAP, 10006455/10027375 NTor. Jan 24 13:59:57 at-vie01a-tor03 Tor-78.142.140.242_443[517]: Since startup, we have initiated 0 v1 connections, 0 v2 connections, 0 v3 connections, and 11906 v4 connections; and received 47 v1 connections, 4092 v2 connections, 8578 v3 connections, and 409960 v4 connections. Jan 24 14:17:01 at-vie01a-tor03 CRON[21604]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) Jan 24 15:17:01 at-vie01a-tor03 CRON[21670]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) Jan 24 15:41:25 at-vie01a-tor03 ntpd[492]: error resolving pool 1.debian.pool.ntp.org: Temporary failure in name resolution (-3) at-vie01a-tor04.ph3x.at: Jan 25 12:00:52 at-vie01a-tor04 Tor-188.118.198.244_443[510]: Heartbeat: Tor's uptime is 11:59 hours, with 36596 circuits open. I've sent 192.29 GB and received 194.32 GB. Jan 25 12:00:52 at-vie01a-tor04 Tor-188.118.198.244_443[510]: Circuit handshake stats since last time: 84713/86100 TAP, 11892935/11941101 NTor. Jan 25 12:00:52 at-vie01a-tor04 Tor-188.118.198.244_443[510]: Since startup, we have initiated 0 v1 connections, 0 v2 connections, 0 v3 connections, and 5938 v4 connections; and rec eived 44 v1 connections, 2949 v2 connections, 5395 v3 connections, and 287856 v4 connections. Jan 25 12:17:01 at-vie01a-tor04 CRON[29820]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) Jan 25 12:29:17 at-vie01a-tor04 kernel: [44936.694001] hrtimer: interrupt took 12598111 ns Jan 25 13:17:01 at-vie01a-tor04 CRON[2275]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) Jan 25 14:17:01 at-vie01a-tor04 CRON[7180]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) Jan 25 14:27:14 at-vie01a-tor04 kernel: [52013.316026] TCP: request_sock_TCP: Possible SYN flooding on port 443. Sending cookies. Check SNMP counters. Jan 25 15:17:01 at-vie01a-tor04 CRON[7920]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) Jan 25 16:17:01 at-vie01a-tor04 CRON[8023]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) Jan 25 16:42:38 at-vie01a-tor04 ntpd[492]: Soliciting pool server 81.16.38.161 Jan 25 16:42:46 at-vie01a-tor04 ntpd[492]: error resolving pool 3.debian.pool.ntp.org: Temporary failure in name resolution (-3) >>>>> LOGS END <<<<<

3 4

Tor 0.3.0.x end-of-life date in one week (2018-02-01)
by nusenu 25 Jan '18

25 Jan '18

This is a quick reminder that in one week, Tor 0.3.0.x will reach its end of life date (2018-02-01). >300 relays are still running that major version. https://nusenu.github.io/OrNetStats/#major-versions list of affected relays: https://atlas.torproject.org/#search/version:0.3.0.%20running:true https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTor… Consider enabling auto-updates to keep your relays safe https://trac.torproject.org/projects/tor/wiki/TorRelayGuide#AutomaticSoftwa… -- https://mastodon.social/@nusenu twitter: @nusenu_

1 0

nyx no connections shown
by TorGate 23 Jan '18

23 Jan '18

Hi, i have 2 new relais running and have also installed nyx. When i go to the page 2 in nyx is there no connection. But my network show me over 4000 tor connections . What is the issue with nyx on my torservers ? TorGate torgate(at)linux-hus.dk

5 16

kelihos infection
by scar 22 Jan '18

22 Jan '18

Hello fellow relay operators, I have received word from my ISP that they detected malicious traffic from my account. I'm running the exit node "cave" with reduced exit policy, https://atlas.torproject.org/#details/3875c9c843d33762fa733bcaf128f26a10bc7… The information received from my ISP was: infection => 'kelihos', subtype => 'kelihos.e', port => '52935', asn => '209', family => 'kelihos', sourceSummary => 'Drone Report' Typically they will also provide an IP address related to the infection, which is usually a sinkhole. The solution is to block the IP in my exit policy. However no IP was provided in this report and there is not one available, since my ISP is just relaying information they receive from a 3rd party detection agency. Furthermore, the port mentioned, 52935, is not allowed in my exit policy, so I'm guessing that port is somewhere else... Any ideas about this "infection" and how we could prevent it from using our exit nodes? Thanks

2 1

Become a Fallback Directory Mirror
by teor 22 Jan '18

22 Jan '18

Dear Relay Operators, Do you want your relay to be a Tor fallback directory mirror? Will it have the same address and port for the next 2 years? Just reply to this email with your relay's fingerprint. If your relay is on the current list, you don't need to do anything. If you're asking: Q: What's a fallback directory mirror? Fallback directory mirrors help Tor clients connect to the network. For more details, see [1]. Q: Is my relay on the current list? Search [2] and [3] for your relay fingerprint or IP address and port. [2] is the current list of fallbacks in Tor. [3] is used to create the next list of fallbacks. Q: What do I need to do if my relay is on the list? Keep the same IP address, keys, and ports. Email tor-relays if the relay's details change. Q: Can my relay be on the list next time? We need fast relays that will be on the same IP address and port for 2 years. Reply to this email to get on the list, or to update the details of your relay. Once or twice a year, we run a script to choose about 150-200 relays from the potential list [3] for the list in Tor [2]. Q: Why didn't my relay get on the list last time? We check a relay's uptime, flags, and speed [4]. Sometimes, a relay might be down when we check. That's ok, we will check it again next time. It's good to have some new relays on the list every release. That helps tor clients, because blocking a changing list is harder. Q: What about the current relay DDoS? We don't think the DDoS will have much impact on the fallback list. If your relay is affected, please: * make sure it has enough available file descriptors, and * set MaxMemInQueues to the amount of RAM you have available per tor instance (or maybe a few hundred MB less). We're also working on some code changes. See [5] for more details. [1]: https://trac.torproject.org/projects/tor/wiki/doc/FallbackDirectoryMirrors [2]: https://gitweb.torproject.org/tor.git/tree/src/or/fallback_dirs.inc [3]: https://gitweb.torproject.org/tor.git/tree/scripts/maint/fallback.whitelist [4]: https://trac.torproject.org/projects/tor/attachment/ticket/21564/fallbacks_… [5]: https://lists.torproject.org/pipermail/tor-relays/2017-December/013881.html -- Tim / teor PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n ------------------------------------------------------------------------

15 26

connlimit: better to use "DROP" or "REJECT --reject-with tcp-reset"?
by tor 21 Jan '18

21 Jan '18

For relay operators using iptables connlimit to mitigate DoS attacks (or increased load from new clients), is it better for the Tor network to use "DROP" rules, or should we use something like "REJECT --reject-with tcp-reset"?

4 11

hidden service performance
by Igor Mitrofanov 21 Jan '18

21 Jan '18

I'd like to call out the apparent hidden service performance slowdown: https://metrics.torproject.org/torperf.html?start=2017-04-23&end=2018-01-21… I hope the dev team is looking into it. Thanks, Igor

3 2

updateFallbackDirs.py issues
by Toralf Förster 21 Jan '18

21 Jan '18

I do wonder why $> scripts/maint/updateFallbackDirs.py check_existing tells $> WARNING::1AF72E8906E6C49481A791A6F8F84F8DFEBBB2BA not a candidate: changed address/port recently (2017-10-22 07:00:00) But 1AF72E8906E6C49481A791A6F8F84F8DFEBBB2BA didn't changed it address/port since end of 2016. What I did is to establish a 2nd Tor relay at the same hardware at 2 different ports in automn last year: D11D11877769B9E617537B4B46BFB92B443DE33D (to verify if the combined bandwidth/weight of both would be equal to the one of the former single relay at the same IP). And I played a little bit with its configuration values. What comes in addition into my mind is that at every reboot I do run first "certbot" to check for a renewed LetsEncrypt certificate. And shortly (1 or 2 minutes) after it finished both Tor instances are started. -- Toralf PGP C4EACDDE 0076E94E

2 6

Onionoo bandwidth recording stopped?
by Ralph Wetzel 21 Jan '18

21 Jan '18

3 5

Question about downtime
by Conrad Rockenhaus 21 Jan '18

21 Jan '18

Hello, Note - to others that have sent me emails about a proposed project, I will respond, I’m sorry I just got caught up in a huge emergency project. Anyway, I had a quick question, on the relay side I run ConradsOVHRelay01 (Relay) and ConradsOVHRelay02 (Exit). They’re running on CentOS, so I have to manually install the latest version of tor to keep up with the security updates. I am considering migrating to Ubuntu or Debian to make the update process simpler. To avoid downtime, would it be better to spin up two more boxes and migrate or would bringing them down for maintenance be acceptable? I would like to avoid downtime personally, as they’re stable, fast relays. I’m just looking for thoughts and ideas. Thanks, Conrad

3 2

Increased cpu usage
by r1610091651 20 Jan '18

20 Jan '18

Hi AFter upgrade from 3.1.9 to 3.2.9, I've noticed that the cpu usage doubled for same throughput / conditions. Is anyone else seeing that too? Regards

6 5

Re: [tor-relays] Good vsp providers
by Tyler Johnson 19 Jan '18

19 Jan '18

Are the advertised bandwidths from online.net what you will see in actual practice? For instance, if one of their LTS servers comes with 300Mbps, will you get close to that throughput? I have a few servers with oneprovider.com (online.net reseller I believe) and it's about 1/10 what is advertised, which is still good, considering the cost, but I'd like to run higher bandwidth relays. Also, does anyone know if the KVM offered through online.net have virtual media capabilities? Thanks, Tyler On Jan 19, 2018 03:16, "niftybunny" <abuse(a)to-surf-and-protect.net> wrote: Okay, you are from the US. Tor is legal in the US and legal in EU. You should be fine. I would not recommend running a Tor Exit if you are from Russia, UAE or Turkey. I used to have 20 Exists with Online.net and I got lots of abuse but they were fine after verifying me. And by the way, you dont have much choice with traffic flat and Tor exit friendly anyway. Markus On 19. Jan 2018, at 01:20, Fabian A. Santiago <fsantiago(a)garbage-juice.com> wrote: On January 18, 2018 6:26:40 PM EST, Mirimir <mirimir(a)riseup.net> wrote: On 01/18/2018 11:54 AM, niftybunny wrote: You will held responsible to your actions (traffic). So worst case scenario is: They give your personal data to a LEA and you are now in charge to explain to a LEO that this is a Tor Exit. Depends on your country if this is a good idea. If you dont want any personal data with your VPS, get a bulletproof VPS but even offshore ISPs ban Tor Exists together with CP and hate speech. Welcome to the wonderful world of Tor Exists. Enjoy your stay. Markus How about HostSailor? They accept Bitcoin, and don't authenticate customers. But I don't know how they'd handle Tor relays. On 18. Jan 2018, at 23:45, Fabian A. Santiago <fsantiago(a)garbage-juice.com> wrote: January 18, 2018 4:50 PM, "George" <george(a)queair.net> wrote: niftybunny: online.net <http://online.net> trabia.com <http://trabia.com> (ask first) both offer 100mbit for less than 5 euros This is a CSV file that TDP is slowly tinkering with. While it's focused on BSD-providing VPSs, most offer more. https://github.com/torbsd/torbsd.github.io/blob/master/docs/bsd-vps.md 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 I asked online.net about their cloud ssd vps service and tor and have the following dialog going: " Hello. I'm interested in running a Tor relay exit node on your cloud SSD vps product. Is this allowed? I would be running a reduced reduced exit policy. Thank you. **************************************** Flavio Pastore 1/18/18 5:13 PM Hello, Thanks for your ticket. Our platform is a IaaS one. So, if you're willing to set up legal activities, you're more than welcome regardless of the service used. If not, you will reported accordingly. I hope I have this point clear, but we remain here at your entire disposal for any further information. Best regards, Flavio Online / Scaleway Looking for an amazing job? Join us NOW ! https://careers.scaleway.com/ **************************** Fabian.santiago(a)gmail.com 1/18/18 5:40 PM By legal services, do you mean a mechanism in order to respond to abuse reports? if so, i have covered that need by the following: 1.> i publish a tor readme html page on the server for anyone to browse to learn about tor and what my server is doing. it also includes links to the tor project's own pages with additional information. I would also be published in the tor atlas showing my node's information for all to see that i am a tor node. 2.> i publish contact information so that complaint concerns can be addressed to me directly as needed. will this suffice in your opinion? could you also make a note on your end that I would be running an exit relay so that you know, in case you do wind up receiving complaints about my node's traffic? I find (and have read) that with a reduced reduced exit policy the chance for complaint generating traffic is greatly minimized anyway. thank you. " so they seem to be kewl with it but in your opinions, what does he mean by "legal activities"? Thanks. -- Thanks, Fabian S. OpenPGP: 3C3FA072ACCB7AC5DB0F723455502B0EEB9070FC _______________________________________________ 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 _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays Uggh, monthly recurring Bitcoin payments sounds painful. Nah. Maybe not a good idea then with online.net. they seem to offer vps' in Paris and Amsterdam and I have no idea what their LE would do when handed my info. So forget it. Ok, any decently priced unmetered providers with servers in the US? I am in the US. I'll check out the csv someone mentioned as well. Thanks. They also just added this response: " Flavio Pastore wrote: Hello, Thanks for providing us more information about what services you're going to use in your server. By the way, it is very difficult to give you an exhaustive reply in advance, there is not a full text explaining what can be considered as illegal and what legal instead. But we ensure to apply the EU law as general set of rules, and the French law as specific set of rules. Besides, it is impossible to give you all details about that unfortunately. Finally , regarding the exit policy, it depends on the abuse and our security team treats case by case according to the specific abuse committed. Best regards, " Thanks again everyone. -- Thanks, Fabian S. OpenPGP: 3C3FA072ACCB7AC5DB0F723455502B0EEB9070FC _______________________________________________ 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

3 4

Good vsp providers
by Fabian A. Santiago 19 Jan '18

19 Jan '18

Does anyone here use a vsp hosting provider which offers unlimited bandwidth usage at a reasonable cost monthly? Would need to run / offer Ubuntu. Country is of little importance. Thanks. -- Thanks, Fabian S. OpenPGP: 3C3FA072ACCB7AC5DB0F723455502B0EEB9070FC

6 20

Re: [tor-relays] [OrNetRadar] AS: "DigitalOcean, LLC" - 2018-01-16
by nusenu 19 Jan '18

19 Jan '18

I propose to reject these new DigitalOcean relays (no contact/MyFamily) +---------------------+------------------------------------------+-------------+---------+----------+----------+---------+ | first_seen | fingerprint | tor_version | or_port | dir_port | nickname | contact | +---------------------+------------------------------------------+-------------+---------+----------+----------+---------+ | 2018-01-16 01:00:00 | FD94F9A1FB940786691A7B8A266DCA50C6AE28F1 | 0.2.9.11 | 443 | 80 | Unnamed | NULL | | 2018-01-16 02:00:00 | 314E00247E8A661F3FB583275AD3F7B5466EFC99 | 0.2.9.11 | 443 | 80 | Unnamed | NULL | | 2018-01-16 03:00:00 | 0DDD78A986EDECA1E6FD36F8C4ACEFBCB95A90D7 | 0.2.9.11 | 443 | 80 | Unnamed | NULL | | 2018-01-16 03:00:00 | 3137D94063BA0F5D92BAD71EC4F452CA875D81D3 | 0.2.9.11 | 443 | 80 | Unnamed | NULL | | 2018-01-16 03:00:00 | AF1D8F02C0949E9755C0DF9C6761FBBF7AAB62C2 | 0.2.9.11 | 443 | 80 | Unnamed | NULL | | 2018-01-16 04:00:00 | 5C0C3F106C81BDA139DB1B5CD11E3E8E00C2ECF5 | 0.2.9.11 | 443 | 80 | Unnamed | NULL | | 2018-01-16 04:00:00 | B901626F9F7CD538B8B7812223F6614B1CFBDD78 | 0.2.9.11 | 443 | 80 | Unnamed | NULL | | 2018-01-16 04:00:00 | 26F2EE549E1BAE4979E15A432DBB63FC5148B31C | 0.2.9.11 | 443 | 80 | Unnamed | NULL | +---------------------+------------------------------------------+-------------+---------+----------+----------+---------+ ornetradar(a)riseup.net: > 2018-01-16 > > | Up | Ext | JoinTime | IP | CC | ORp | Dirp | Version | Contact | Nickname | eFamMembers | > |------+-------+------------+----------------+------+-------+--------+-----------+-----------+------------+---------------| > | 1 | 0 | 00:16:46 | 138.197.99.49 | us | 443 | 80 | 0.2.9.11 | None | Unnamed | 1 | > | 1 | 0 | 01:09:43 | 165.227.25.219 | us | 443 | 80 | 0.2.9.11 | None | Unnamed | 1 | > | 1 | 0 | 02:07:50 | 178.62.240.100 | nl | 443 | 80 | 0.2.9.11 | None | Unnamed | 1 | > | 1 | 0 | 02:11:33 | 159.89.192.117 | sg | 443 | 80 | 0.2.9.11 | None | Unnamed | 1 | > | 1 | 0 | 02:15:04 | 178.62.33.87 | gb | 443 | 80 | 0.2.9.11 | None | Unnamed | 1 | > | 1 | 0 | 02:53:44 | 139.59.135.196 | de | 443 | 80 | 0.2.9.11 | None | Unnamed | 1 | > | 1 | 0 | 02:56:53 | 165.227.38.141 | ca | 443 | 80 | 0.2.9.11 | None | Unnamed | 1 | > | 1 | 0 | 03:00:57 | 139.59.89.46 | in | 443 | 80 | 0.2.9.11 | None | Unnamed | 1 | > > https://nusenu.github.io/OrNetRadar/2018/01/16/a2 -- https://mastodon.social/@nusenu twitter: @nusenu_

5 9

Re: [tor-relays] Tor 0.3.2.9 Linux - too slow to handle this many circuit creation requests
by rush23＠gmx.net 19 Jan '18

19 Jan '18

1 0

Tor 0.3.2.9 Linux - first period fine, since today lots of: Your computer is too slow to handle this many circuit creation requests!
by Stijn Jonker 18 Jan '18

18 Jan '18

Hi All, Is this a "known" issue, my non-exit relay has been running for over a year, and although with the recent issues (attack / network issue or the likes) with some ipfilter kunfu it managed to get through the storm pretty well. Now all of a sudden since early today my logs are flooded with: Jan 18 11:34:44 tornode Tor[65839]: 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. [204844 similar message(s) suppressed in last 60 seconds] First message is at Jan 18 07:17:13, last just Jan 18 11:37:44, when adding the # of circuits up, total in ~4 hours: 18033820 being 18 Million, which feels a bit much, but don't have any figures to compare. On the current hardware this never seemed to be an issue, not even by far it was normally (according to ESXi) at ~400-500mhz, now it's using 2 vCPU's at ~4000Mhz. Now of course I can lower the bandwidth, but if these are low bandwidth circuits then lowering the bandwidth from 10Mbyte/sec (peak 12,5Mbyte/sec) to a lower value might actually not resolve it. Anybody seeing this as well and/or ideas / advice etc? Stijn

4 3

The Onion Box v4.1
by Ralph Wetzel 18 Jan '18

18 Jan '18

5 8

tor 0.3.2.9 reached deb.torproject.org and FreeBSD repos
by nusenu 17 Jan '18

17 Jan '18

Since this has been a common question in the last few days.. -- https://mastodon.social/@nusenu twitter: @nusenu_

2 1

Re: [tor-relays] Assigning BadExit to Exits failing to resolve hostnames starting on 2018-01-15
by nusenu 17 Jan '18

17 Jan '18

> Hello, > > Arthur and I have been emailing affected exit operators for a while > now and many operators fixed their exits but some minor number or exits > remain broken (even some that are running good tor versions). > > I believe it is reasonable to assign the BadExit flag to exits failing 100% > of DNS resolution attempts and have a CW > 200 (or any other value you like, > I just would not bother about exits with a CW of 20) starting with 2018-01-15, > if we did send them an email about the problem (if they have a contactInfo set). > > https://arthuredelstein.net/exits/ These are 4 exits failing 100% of DNS resolution attempts based on Arthur's scan data from 2018-01-16 05:10:00 UTC +------------------------------------------+-------------+-------+----------------------------------------------------+ | fingerprint | tor_version | CW | contact | +------------------------------------------+-------------+-------+----------------------------------------------------+ | 6F6586F1631CAC1115B9561656E7664D386B7F4B | 0.3.1.9 | 404 | Ins0mnia Shells <orwell1984.info AT gmail dot com> | | 34D3AF8DC4CF68BDEA354D21C24EFB2EAFD7191F | 0.3.1.7 | 2040 | tor(a)krosnov.org | | 92E3764D5485DC4AC01178271FB5A8A2D90DA9FF | 0.3.1.9 | 16700 | Random Person <tor-admin(a)portaltodark.world> | | 60A7451D512B647C0D05A2063CA7F329311347B5 | 0.2.5.16 | 21200 | NULL | +------------------------------------------+-------------+-------+----------------------------------------------------+ -- https://mastodon.social/@nusenu twitter: @nusenu_

1 0

Has the storm passed?
by Ana Lucia Cortez 16 Jan '18

16 Jan '18

About 36 hours ago I tentatively disabled all my firewall rules who where limiting connections to my relay. Everything looks pretty normal, I see no spikes, no errors, no failures. > Jan 15 10:18:36 Tor-relay: > Heartbeat: > Tor's uptime is 4 days 18:00 hours, > with 36,596 circuits open. > I've sent 4,962.80 GB > and received 4,935.38 GB. > Circuit handshake stats since last time: > 244,441 / 244,441 TAP, > 10,558,601 / 10,558,601 NTor. > Since startup, > we have initiated > 0 v1 connections, > 0 v2 connections, > 2 v3 connections, and > 71,189 v4 connections; > and received > 1 v1 connections, > 31,976 v2 connections, > 53,960 v3 connections, and > 755,679 v4 connections. While I still see a lot of Hetzners & Co. in my top 30 connections, they seem to behave better. > Conn Subnet AS Org > 18 46.188.***.0/17 AS8334 2COM Co ltd. > 17 192.243.***.0/20 AS39572 Internet Service Solution Corp. (ISSC-11) > 14 24.60.***.0/14 AS7922 Comcast Cable Communications, LLC (CCCS) > 13 192.99.***.0/16 AS16276 OVH Hosting, Inc. (HO-2) > 12 212.109.***.0/23 AS29182 CJSC Server WebDC colocation > 11 213.239.***.0/18 AS24940 Hetzner Online AG > 10 95.65.***.0/17 AS31252 SC STARNET SRL > 10 213.239.***.0/18 AS24940 Hetzner Online AG > 9 139.59.***.0/16 DigitalOcean, LLC (AP) > 9 163.172.***.0/16 AS12876 Online SAS -- Relay:32E7AAF1F602814D699BEF6761AD03E387758D49

3 2