- tor-relays - lists.torproject.org

1 circuit using 1.5Gig or ram? [0.3.3.2-alpha]
by starlight.2017q4＠binnacle.cx 12 Feb '18

12 Feb '18

On 12 Feb (19:44:02 UTC), David Goulet wrote: >Wow... 1599323088 bytes is insane. This should _not_ happen for only 1 >circuit. We actually have checks in place to avoid this but it seems they >either totally failed or we have a edge case. > >Can you tell me what scheduler were you using (look for "Scheduler" in the >notice log). > >Any warnings in the logs that you could share or everything was normal? > >Finally, if you can share the OS you are running this relay and if Linux, the >kernel version. Don't know if it's relevant but my relay was hit in similar fashion in December. Running 0.2.9.14 (no KIST) on Linux at the time (no other related log messages, MaxMemInQueues=1GB reduced from 2GB after OOM termination): Dec 15 15:28:52 Tor[]: assign_to_cpuworker failed. Ignoring. Dec 15 15:48:16 Tor[]: assign_to_cpuworker failed. Ignoring. Dec 15 16:39:44 Tor[]: We're low on memory. Killing circuits with over-long queues. (This behavior is controlled by MaxMemInQueues.) Dec 15 17:39:45 Tor[]: Removed 442695264 bytes by killing 1 circuits; 18766 circuits remain alive. Also killed 0 non-linked directory connections. Dec 15 19:03:22 Tor[]: We're low on memory. Killing circuits with over-long queues. (This behavior is controlled by MaxMemInQueues.) Dec 15 19:03:23 Tor[]: Removed 1060505952 bytes by killing 1 circuits; 19865 circuits remain alive. Also killed 0 non-linked directory connections. More recently (and more reasonably, MaxMemInQueues=512MB), running 0.3.2.9: Feb 4 20:12:39 Tor[]: Scheduler type KIST has been enabled. Feb 6 08:12:41 Tor[]: Heartbeat: Tor's uptime is 1 day 11:59 hours. I've sent 29.00 MB and received 364.99 MB. Feb 6 14:04:43 Tor[]: We're low on memory. Killing circuits with over-long queues. (This behavior is controlled by MaxMemInQueues.) Feb 6 14:04:43 Tor[]: Removed 166298880 bytes by killing 2 circuits; 20213 circuits remain alive. Also killed 0 non-linked directory connections. Feb 6 14:11:17 Tor[]: Heartbeat: Tor's uptime is 1 day 17:59 hours, with 20573 circuits open. I've sent 910.29 GB and received 902.58 GB. Feb 6 14:11:17 Tor[]: Circuit handshake stats since last time: 1876499/3018306 TAP, 4322015/4322131 NTor. Feb 6 14:11:17 Tor[]: Since startup, we have initiated 0 v1 connections, 0 v2 connections, 1 v3 connections, and 23846 v4 connections; and received 6 v1 connections, 7844 v2 connections, 11906 v3 connections, and 214565 v4 connections. Feb 6 14:12:41 Tor[]: Heartbeat: Tor's uptime is 1 day 17:59 hours. I've sent 31.62 MB and received 420.63 MB. Feb 6 14:22:50 Tor[]: We're low on memory. Killing circuits with over-long queues. (This behavior is controlled by MaxMemInQueues.) Feb 6 14:22:50 Tor[]: Removed 181501584 bytes by killing 2 circuits; 19078 circuits remain alive. Also killed 0 non-linked directory connections. Feb 6 15:01:50 Tor[]: We're low on memory. Killing circuits with over-long queues. (This behavior is controlled by MaxMemInQueues.) Feb 6 15:01:50 Tor[]: Removed 105918912 bytes by killing 1 circuits; 19679 circuits remain alive. Also killed 0 non-linked directory connections. Feb 6 15:46:24 Tor[]: Channel padding timeout scheduled 157451ms in the past. Feb 6 19:30:36 Tor[]: new bridge descriptor 'Binnacle' (fresh): $4F0DB7E687FC7C0AE55C8F243DA8B0EB27FBF1F2~Binnacle at 108.53.208.157 Feb 6 20:11:17 Tor[]: Heartbeat: Tor's uptime is 1 day 23:59 hours, with 18045 circuits open. I've sent 1043.74 GB and received 1034.65 GB. Feb 6 20:11:17 Tor[]: Circuit handshake stats since last time: 260970/368918 TAP, 3957087/3957791 NTor. Perhaps this indicates some newer KIST mitigation logic is effective.

1 0

1 circuit using 1.5Gig or ram? [0.3.3.2-alpha]
by Stijn Jonker 12 Feb '18

12 Feb '18

Hi all, So in general 0.3.3.1-alpha-dev and 0.3.3.2-alpha running on two nodes without any connection limits on the iptables firewall seems to be a lot more robust against the recent increase in clients (or possible [D]DoS). But tonight for a short period of time one of the relays was running a bit "hot" so to say. Only to be greated by this log entry: Feb 12 18:54:55 tornode2 Tor[6362]: We're low on memory (cell queues total alloc: 1602579792 buffer total alloc: 1388544, tor compress total alloc: 1586784 rendezvous cache total alloc: 489909). Killing circuits withover-long queues. (This behavior is controlled by MaxMemInQueues.) Feb 12 18:54:56 tornode2 Tor[6362]: Removed 1599323088 bytes by killing 1 circuits; 39546 circuits remain alive. Also killed 0 non-linked directory connections. Feb 12 19:04:10 tornode2 Tor[6362]: Your network connection speed appears to have changed. Resetting timeout to 60s after 18 timeouts and 1000 buildtimes. So 1 Circuit being able to claim 1,5 gig or ram, now this seems a big much. Whilst the DoS protection seems to do something (see below). Now this could be a new attack or just an error etc. However wouldn't some sort of fair memory balance between circuits be an other mitigation factor to consider? Not saying it should be as strict as "circuit memory"/"# of circuits" but 99.x% of memory for one circuit feels wrong for a relay. Feb 12 13:58:34 tornode2 Tor[6362]: DoS mitigation since startup: 910770 circuits rejected, 10 marked addresses. 25972 connections closed. 324 single hop clients refused. Feb 12 19:58:34 tornode2 Tor[6362]: DoS mitigation since startup: 1222320 circuits rejected, 12 marked addresses. 33359 connections closed. 402 single hop clients refused. Thx, Stijn

3 5

torservers are not rechable
by TorGate 11 Feb '18

11 Feb '18

Hi to all, i have started my servers again and changed the wan ip adress. But the servers have the old ip after uptime of 2 times. Can i update manualy the wan ips ? The dns names are changed to the new ipadresses. regards Steffen TorGate torgate(at)linux-hus.dk

3 3

Exits lost their function
by Paul 11 Feb '18

11 Feb '18

What could bring several exits at different providers and different operating systems (Linux and FreeBSD) down on the same day, Jan 21st? Since, while they still run as relays, they don’t show as exits any more without any change from my side. They do run on Tor 0.3.1.9 or 0.3.2.9 in the same Family. Thanks Paul

5 14

new requirements for Tor Exit relays in effect as of 2018-01-20
by nusenu 11 Feb '18

11 Feb '18

Dear Tor Exit Operator, I'm sending you this email to inform you that on 2018-01-20 the requirements for exit operators changed. Since that date your exit policy MUST allow exiting to port 80 _and_ 443 to be eligible for the exit flag. If your exit policy does not meet these new requirements, you lost your exit flag on 2018-01-20 (if you used to have it before that date). Find below a list of 34 exit relays that are affected by these requirement changes (consensus data as of 2018-01-19 13:00): contactInfo: 022F 0FF2 CB04 2342 7178 334F BA3F 9725 266C DD10 (OstwaldRipening) contactInfo: 0x49FAB046 Chris Jeane <chris jeane AT gmail dot com> (SpikeNJ) contactInfo: 0xB4F409D25BC71927 18NkcxXvFQKo2qyTqa6sQNt6bNEgXAvF9U (anoncat1) contactInfo: 0xd3956a77 Your pure Manifestation of Peace (newton) contactInfo: 0xFDB8716D Gerald Turner <gturner(a)unzane.com> - 1FRMLK42AvHNwn2NV3ASrxdMDYd12C1qbs (Unzane) contactInfo: 1024R/0FCE8549 Alexander Oelzant <alexander(a)oelzant.priv.at> (SCggHJTyWbtzDA9YZi) contactInfo: 145tXZyQEfdmpYhmbFtYe84kjghB5ymPA4 (NormalCitizen) contactInfo: 145tXZyQEfdmpYhmbFtYe84kjghB5ymPA4 (OrdinaryCitizen) contactInfo: 145tXZyQEfdmpYhmbFtYe84kjghB5ymPA4 (RegularCitizen) contactInfo: <admin AT openbsd DOT se> (che) contactInfo: Eran Sandler <eran(a)sandler.co.il> (tor4thepeople2) contactInfo: flo(a)gmx.it (DannenTor) contactInfo: Magnus <magnus(a)1337.cf> (Pandora) contactInfo: nobody AT example dot com (blent) contactInfo: Piotr <unknown(a)yahoo.com> (icubdw2o2xipsdc) contactInfo: replace k with c : kontakt @ zwiebeltoralf . de (zwiebeltoralf) contactInfo: replace k with c : kontakt @ zwiebeltoralf . de (zwiebeltoralf2) contactInfo: Systems Manager <service(a)ns.sol.net> (soltor0) contactInfo: Thor Exit <thor.exit AT yandex dot com> (ThorExit) contactInfo: torinternetzforall(a)aol.com (jUsTwAnTaFREEsHiRt) contactInfo: tor-mngr AT scalaire DOT fr (servicePublic2) contactInfo: Tsen <tsenchi.ng AT yandex dot com> (mycontribution) contactInfo: TvdW <tor AT tvdw DOT eu> - bitcoin 1NKKoCQwKs67eKBGedMD8wYoAs3Z4mMAex (EmpokNor) contactInfo: TvdW <tor AT tvdw DOT eu> - bitcoin 1NKKoCQwKs67eKBGedMD8wYoAs3Z4mMAex (TerokNor) contactInfo: VolkerWilcken at web dot de (EXITNODESAVE) contactInfo: yv3r3nd5yi1k(a)mail.ru (relay651054) contactInfo: <zwiebeln at online de> please donate BTC 1K38x9xqK3YDzjehYFAEPzsESEC4ScH5wJ (alsaceonion) contactInfo: <zwiebeln at online de> please donate BTC 1K38x9xqK3YDzjehYFAEPzsESEC4ScH5wJ (alsaceonionb) contactInfo: <zwiebeln at online de> please donate BTC 1K38x9xqK3YDzjehYFAEPzsESEC4ScH5wJ (mandela) contactInfo: <zwiebeln at online de> please donate BTC 1K38x9xqK3YDzjehYFAEPzsESEC4ScH5wJ (mandelab) contactInfo: <zwiebeln at online de> please donate BTC 1K38x9xqK3YDzjehYFAEPzsESEC4ScH5wJ (montrealonion) contactInfo: <zwiebeln at online de> please donate BTC 1K38x9xqK3YDzjehYFAEPzsESEC4ScH5wJ (montrealonionb) contactInfo: <zwiebeln at online de> please donate BTC 1K38x9xqK3YDzjehYFAEPzsESEC4ScH5wJ (quebeconion) contactInfo: <zwiebeln at online de> please donate BTC 1K38x9xqK3YDzjehYFAEPzsESEC4ScH5wJ (quebeconionb) @niftybunny: I you are motivated, you can send them an email directly by extracting valid email data from this list. zwiebeln at online de, zwiebeltoralf and TvdW are aware, I don't know about the rest, and I obviously omitted those for which we do not have any contactInfo. The actual learning here are: Missing proper per-notifications for exit operators. This topic (new req: 80+443) has been discussed before [1] but has not been properly announced, this could have been a TPO tweet or a blog post or an email to this list with proper subject and not hidden in a long thread. I should auto-detect such events (multiple relays loosing flags at the same time) without knowing about them. [1] https://lists.torproject.org/pipermail/tor-relays/2017-December/013663.html https://lists.torproject.org/pipermail/tor-relays/2018-January/014278.html -- https://mastodon.social/@nusenu twitter: @nusenu_

1 0

Question regarding exit sizing
by Conrad Rockenhaus 10 Feb '18

10 Feb '18

Hello, I have a question regarding relay sizing to add additional nodes to the network. What scenario is better for the network - adding five 100mbps nodes, or one 500 mbps node? Let’s keep it easy and say all five of those 100 mbps nodes would be in the same datacenter, configured in the same configuration, etc. I’m just curious, because I”m getting ready to add a few more nodes, but I’m wondering if it’ll be better to go big, or just stay small. Thanks, Conrad Rockenhaus

3 3

unreplied conntrack sessions
by Quintin 10 Feb '18

10 Feb '18

nusenu wrote: > If your hoster suspends your server if you exceed 10k concurrent connections > I'm afraid it is probably not suitable for an exit relay The response from the hoster was: > Your server should not have over 20,000 unreplied connections. This is a sign of abuse. What about the exit node causes such abormally high conntrack sessions? Q -- 0101100101000001010010000101010101000001010010000010000001000010 0100110001000101010100110101001100100000010110010100111101010101

3 5

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

10 Feb '18

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

2 2

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

10 Feb '18

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

1 0

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

09 Feb '18

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

2 1

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

09 Feb '18

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

3 3

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

08 Feb '18

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

3 5

Exit Relay Up
by Conrad Rockenhaus 05 Feb '18

05 Feb '18

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

2 1

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

05 Feb '18

Hi, relayor v0.3.1 has been released. https://github.com/nusenu/ansible-relayor Whether you run a single or many relays, relayor helps you with running relays with minimal effort (automate everything). Introduction to get you started: https://medium.com/@nusenu/deploying-tor-relays-with-ansible-6612593fa34d Main benefits for a tor relay operator ====================================== * automation - no more manual setup tasks * security: offline Ed25519 master keys every tor instance is run with a distinct user * automatically makes use of IPv6 IPs (if available) * automatic tor instance generation (two by default - configurable) * enables tor's Sandbox feature by default on Debian-based systems * easily choose between alpha/non-alpha releases * easily restore a relay setup * easily choose between exit relay/non-exit relay mode * automatic deployment of a tor exit notice html page via tor's DirPort * automatic MyFamily management Supported Operating Systems ---------------------------- Debian 8, 9 and Debian Testing OpenBSD 6.2 FreeBSD 10.4, 11.1 HardenedBSD 11.1 Ubuntu 16.04 CentOS 7 Fedora 27 Changes since v0.3.0: ------------------------------ - support custom tor-exit-notice.html files (fixes #140) - increase tor_alpha_version: 0.3.2.x -> 0.3.3.x - Debian/Ubuntu: add support for tor nightly builds - implement per-instance ExitRelay settings (fixes #146) - make tor package state configurable (latest vs. present) regards, nusenu -- https://mastodon.social/@nusenu twitter: @nusenu_

1 0

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

05 Feb '18

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

2 2

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

05 Feb '18

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

1 0

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

04 Feb '18

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

2 1

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