tor-relays February 2018

tor-relays@lists.torproject.org

72 participants
67 discussions

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-relays February 2018