- tor-relays - lists.torproject.org

Re: [tor-relays] Detecting Network Attack [re: exit synflooded]
by tor＠t-3.net 25 Nov '17

25 Nov '17

I went and added a reject for exit to port 8888 and HUPed the process. Maybe this is the fix! :)

1 0

Exit from Different IP from OR Port
by Dr Gerard Bulger 25 Nov '17

25 Nov '17

Direct Exit to a different IP. I naively thought that the proxy lines in torrc could to that via an https proxy. Alas that's not what that line is for! I got an impression from earlier chats a while ago that exiting to a non-advertised IP was regarded as simply not cricket, in that the internet should know the IP or Tor exits exiting. The trouble now is too many are sites apply blanket bans on Tor exits. I failed get a Tor on my VPS to use a VPN as the final exit, as my knowledge of routing is too limited. I kept cutting myself off from the branch I was sitting on fiddling with this remotely. As some exits to do manage this, I wonder if anyone can post be a script or point me in the right direction as to how they do it. Scenario: Set up a VPN connection. Have a script that in effect offers split tunnelling for TOR to allow exit via the VPN. The OR port needs to remain local fixed IP. The default route of the VPN server remains local. Doing everything in and out via most VPNs would not be useful as these services have very dynamic IPs. Gerry >>>Detecting exit nodes is error prone, as you point out. Some exit >>> nodes have their traffic exit a different address than their >>> listening port. Hey does Exonerator handle these? >> Right. It's not trivial for tor to figure out what exit relays are >> multi-homed -- at least not without actually establishing circuits >> and fetching content over each exit relay. >> >> I just finished an exitmap scan and found 17 exit relays that exit >> from an IP address that is different from what's listed in the >> consensus: > This mode of operation, regardless of how it happens, is not in itself > a problem, nor cause for alarm. In fact, the nature of these "exit IP > different than ORPort" relays can and often does assist users in > circumventing censorship... a fundamental use case of Tor. > For instance, the arbitrary automated and blind blocking via dumb > blocklists that prevent even such most basic user activity and human > right to knowledge as simply reading websites via Tor. Such blocking > examples can often be found here: > https://trac.torproject.org/projects/tor/wiki/org/doc/ListOfServicesBl > ockingTor > > It's also entirely up to the exit operator to determine if the third > party non contractual / SLA exonerator service is of any particular > use or benefit to them or not... perhaps they have other notary means, > or are immune or not subject to any such legal or jurisdictional > issues, for which it becomes moot. > > Similarly, realtime TorDNSEL and the like could be considered to be > censorship enabling tools. > -----Original Message----- From: tor-relays [mailto:tor-relays-bounces@lists.torproject.org] On Behalf Of teor Sent: 25 November 2017 07:31 To: tor-relays(a)lists.torproject.org Subject: Re: [tor-relays] Tor Metrics issue > On 25 Nov 2017, at 17:36, Arisbe <arisbe(a)cni.net> wrote: > > In the immediate past I monitored both my relays and my bridges through atlas. So, now with Tor Metrics, I don't see my bridges. Am I doing something wrong or are they not in the data base? How do you search for your relays and bridges? T _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

3 2

Pretty sure our exit was being synflooded.
by tor＠t-3.net 25 Nov '17

25 Nov '17

Was anyone else's exit being synflooded yesterday and today? I put some iptables code in to help, it might have mitigated it. I'm pretty sure our exit "Libero" was being synflooded. Managed to lose all our flags shortly after the instability was (finally) resolved, go figure =p

2 1

Re: [tor-relays] my IP got blocked -> closed
by Patrice 25 Nov '17

25 Nov '17

Hi, I want to tell that the issue is no longer exists. I can now visit ebay, ikea, ect. without a problem. It was like grarpamp said, there was a bunch of malicious software on one of my Computers. Very shameful, there was no virus detection installed. Therefore my tor relay was not the problem but my windows pc. ;-) Thank you for your help! Kind regards Kalle > 2. Re: my IP got blocked (grarpamp) > >>> Detecting exit nodes is error prone, as you point out. Some exit nodes >>> have their traffic exit a different address than their listening >>> port. Hey does Exonerator handle these? >> Right. It's not trivial for tor to figure out what exit relays are >> multi-homed -- at least not without actually establishing circuits and >> fetching content over each exit relay. >> >> I just finished an exitmap scan and found 17 >> exit relays that exit from >> an IP address that is different from what's listed in the consensus: > This mode of operation, regardless of how it happens, is not in > itself a problem, nor cause for alarm. In fact, the nature of these > "exit IP different than ORPort" relays can and often does assist > users in circumventing censorship... a fundamental use case of Tor. > For instance, the arbitrary automated and blind blocking via dumb > blocklists that prevent even such most basic user activity and human > right to knowledge as simply reading websites via Tor. Such blocking > examples can often be found here: > https://trac.torproject.org/projects/tor/wiki/org/doc/ListOfServicesBlockin… > > It's also entirely up to the exit operator to determine if the > third party non contractual / SLA exonerator service is of any > particular use or benefit to them or not... perhaps they have other > notary means, or are immune or not subject to any such legal or > jurisdictional issues, for which it becomes moot. > > Similarly, realtime TorDNSEL and the like could be considered > to be censorship enabling tools. >

1 0

Re: [tor-relays] Pretty sure our exit was being synflooded.
by Paul Templeton 25 Nov '17

25 Nov '17

Happening to middles as well - I get black hold all the time - ISP has auto rules. Paul ----- Original Message ----- From: tor(a)t-3.net To: tor-relays(a)lists.torproject.org Sent: Saturday, November 25, 2017 10:23:24 AM Subject: [tor-relays] Pretty sure our exit was being synflooded. Was anyone else's exit being synflooded yesterday and today? I put some iptables code in to help, it might have mitigated it. I'm pretty sure our exit "Libero" was being synflooded. Managed to lose all our flags shortly after the instability was (finally) resolved, go figure =p _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

2 1

Tor meetup at Primavera hacker (Santiago de Chile) [es/en/pt]
by ilv＠torproject.org 21 Nov '17

21 Nov '17

[ES][EN][PT]¡Encuentro Tor en la Primavera Hacker! ¡Ven! ======================================================== [ES] ¡Encuentro Tor en la Primavera Hacker! ¡Ven! [EN] Tor Meetup at Primavera Hacker! Join us! [PT] Encontro Tor na Primavera Hacker! Venha! [ES] ¡Encuentro Tor en la Primavera Hacker! ¡Ven! ------------------------------------------------- ¡Hola! La Primavera Hacker está por llegar. Durante los días 2 y 3 de diciembre, hackers, activistas, tecnólogos, feministas y demás fauna se darán cita en Santiago de Chile. Esta es una invitación para todos los interesadas e interesados en colaborar con la comunidad Tor. Tor es software libre, estructurado alrededor de una red de servidores mantenidos por voluntarias y voluntarios a lo largo del globo para proteger el anonimato en línea y evadir la censura en Internet. Durante los dos días, miembros de la comunidad Tor estarán presentes en la Primavera Hacker con agenda abierta, dispuestos a conversar, intercambiar experiencias, aprender y enseñar respecto a las tecnologías contra la vigilancia y, principalmente, discutir sobre cómo colaborar con Tor. Tendremos también una mesa llena de stickers y regalitos de Tor :-) Encuentro Tor ------------- La red Tor está compuesta por más de 6 mil computadoras alrededor del mundo. Sin embargo, América Latina tiene una participación muy pequeña. Actualmente en Chile hay solamente 2 nodos en funcionamiento. En Brasil, apenas 25. ¡Necesitamos aumentar la diversidad de la red más allá de los Estados Unidos y Europa! Ven y participa del Encuentro Tor, y aprende como ser parte de la comunidad. Durante los dos días del festival, nuestra idea es cubrir los siguientes temas: - Como funciona Tor, por qué Tor tiene problemas con los VPNs y con los servicios proxy de un salto (1-hop) - Install fest: ¡Instala Tor Browser y Orbot con nosotros! - Como colaborar con la traducción de la documentación al castellano. - Como instalar, configurar y administrar su nodo de Tor. - Como ser voluntario más allá de mantener nodos. - Como usar OONI para detectar la censura en redes. - Como usar herramientas como onion-share. - Tor en universidades y buenas prácticas de investigación. - Tor y la ley, ajustar la legislación sobre Tor en Latinoamérica. - Mejorar la metodología de pruebas para OONI -- Listas de URLs de prueba (https://ooni.torproject.org/get-involved/contribute-test-lists/) - OONI y bloqueos: Cómo analizar los datos de OONI (https://api.ooni.lo) Si no puedes llegar al encuentro, puedes hablar por el canal: IRC: irc.oftc.net #tor-south Por la lista de correo: https://lists.torproject.org/pipermail/global-south/ Y el Wiki (Trac) para la documentación, eventos y otras cosas: https://trac.torproject.org/projects/tor/wiki/org/teams/CommunityTeam/Proje… Primavera Hacker: https://phacker.org - http://u5ed42u6sbzq7xzs.onion Un abrazo, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- [EN] Tor Meetup at Primavera Hacker! Join us! Hi! Primavera Hacker (Hacker Spring) is coming. During December 2 and 3, hackers, activists, technologists, feminists and related people will meet in Santiago de Chile. This is an invitation for all people interested in collaborating with the Tor community. Tor is free software, structured around a network of volunteer-run servers, spread all around the world to anonymity online and circumvent Internet censorship. During the two days of the meeting, Tor community members will be present at Primavera Hacker with an open schedule, eager to tealk, exchange experiences, learn and teach about technologies against surveillance and, mainly, discuss how to collaborate with Tor. We will also have a table full of stickers and other Tor swag :-) Tor Meetup ---------- The Tor network is formed by over 6 thousand computers around the world. However, Latin America hosts a very small share of it. Nowadays, in Chile there are only 2 working servers. In Brasil, just 25. We need to increase the diversity of the network beyond the United States and Europe! Come and be a part of the Tor Meetup, and learn how to engage in the Tor community. During the two days of primavera hacker we will cover the following topics: - How does Tor work, why does Tor have problems with VPNs and 1-hop proxy services. - Install fest: Install Tor Browser and Orbot with us! - How to collaborate translating documentation into Spanish. - How to install, configure and administer your Tor relay. - How to use OONI to detect network censorship. - How to use tools such as onion-share. - Tor for universities and good research practices. - Tor and the law, adjust legislation about Tor in Latin America. - Improve the OONI testing methodology -- List of test URLs (https://ooni.torproject.org/get-involved/contribute-test-lists/) - OONI and blocking: How to analyze OONI data (https://api.ooni.lo) If you cannot make it to the meeting, you can talk with the participants on the following channel: IRC: irc.oftc.net #tor-south On our mailing list: https://lists.torproject.org/pipermail/global-south/ And the Wiki (Trac) for documentation, events and other things: https://trac.torproject.org/projects/tor/wiki/org/teams/CommunityTeam/Proje… Primavera Hacker: https://phacker.org - http://u5ed42u6sbzq7xzs.onion hugs, ==== Encontro Tor na Primavera Hacker! Venha! ======================================== Hola! A Primavera Hacker está chegando! Nos dias 2 e 3 de dezembro, hackers, ativistas, tecnologistas, feministas se encontrarão em Santiago, no Chile. Este é um convite para todos interessados e interessadas em colaborar com a comunidade Tor. O Tor é um software livre rodado por uma rede de servidores voluntários distribuída pelo mundo para garantir o anonimato online e contornar a censura na Internet. Durante os dois dias membros da comunidade Tor estarão presentes na Primavera Hacker com a agenda aberta para conversar, trocar experiências, aprender e ensinar as tecnologias anti vigilância e, principalmente, discutir sobre como colaborar com o Tor. Teremos uma mesa cheia de adesivos e brindes do Tor :) Encontro Tor ------------- A rede Tor é composta por mais de 6 mil computadores ao redor do mundo. No entanto, a América Latina tem uma participação muito pequena. Atualmente, no Chile há apenas 2 servidores em funcionamento. E no Brasil apenas 25. Nós precisamos aumentar a diversidade da rede além dos Estados Unidos e Europa! Venha participar do Encuentro Tor e saiba como se engajar na comunidade Tor. Durante os dois dias a nossa ideia é ensinar: - Como funciona o Tor, porque Tor, os problemas com as VPNs e serviços proxy de 1-hop. - Install fest: instale Tor browser & Orbot com a gente! - Como colaborar na tradução da documentação em ES/PT. - Como instalar, configurar e gerenciar o seu relay do Tor. - Como usar o OONI para detectar a censura na rede. - Como usar ferramentas como onion-share. - Como ser voluntário além da hospedagem de servidores. - Tor em universidades e boas práticas de pesquisa. - Tor e a lei: ajustar as leis para o Tor na América Latina. - OONI melhorar a metodologia testada -- listas de URL de testes (https://ooni.torproject.org/get-involved/contribute-test-lists/) - OONI e bloqueios, como analisar OONI data (https://api.ooni.io) Se você não puder comparecer no Encontro, você pode falar com a gente por esse canal: IRC: irc.oftc.net #tor-south E pela lista de email: https://lists.torproject.org/pipermail/global-south/ E wiki (Trac) para documentacao, eventos e outras coisas: https://trac.torproject.org/projects/tor/wiki/org/teams/CommunityTeam/Proje… Primavera Hacker: https://phacker.org - http://u5ed42u6sbzq7xzs.onion um abraço, -- ilv, gus, vasilis, gwolf

1 0

The Onion Box v4.0
by Ralph Wetzel 18 Nov '17

18 Nov '17

3 3

Re: [tor-relays] [tor-dev] Detecting multi-homed exit relays (was: Onion auto-redirects using Alt-Svc HTTP header)
by grarpamp 18 Nov '17

18 Nov '17

>> Detecting exit nodes is error prone, as you point out. Some exit nodes >> have their traffic exit a different address than their listening >> port. Hey does Exonerator handle these? > > Right. It's not trivial for tor to figure out what exit relays are > multi-homed -- at least not without actually establishing circuits and > fetching content over each exit relay. > > I just finished an exitmap scan and found 17 > exit relays that exit from > an IP address that is different from what's listed in the consensus: This mode of operation, regardless of how it happens, is not in itself a problem, nor cause for alarm. In fact, the nature of these "exit IP different than ORPort" relays can and often does assist users in circumventing censorship... a fundamental use case of Tor. For instance, the arbitrary automated and blind blocking via dumb blocklists that prevent even such most basic user activity and human right to knowledge as simply reading websites via Tor. Such blocking examples can often be found here: https://trac.torproject.org/projects/tor/wiki/org/doc/ListOfServicesBlockin… It's also entirely up to the exit operator to determine if the third party non contractual / SLA exonerator service is of any particular use or benefit to them or not... perhaps they have other notary means, or are immune or not subject to any such legal or jurisdictional issues, for which it becomes moot. Similarly, realtime TorDNSEL and the like could be considered to be censorship enabling tools.

1 0

my IP got blocked
by Patrice 18 Nov '17

18 Nov '17

Hi everyone, I`ve got an issue with my local IP address. I am running a relay about 1 year and since 3 or 4 weeks I can`t reach some websites like: ebay or ikea. All I get is this message: * * *Access Denied* You don`t have permission to access "Http://www.ebay.com/" on this server. Reference # ____looong number______ I think I am on some blacklists. After I change my IP address all worked fine for only 2 days. Can I do something about this? Thank you for your help! Kind regards Kalle

7 7

Re: [tor-relays] tor-relays Digest, Vol 82, Issue 25
by Gabriel Curtis 16 Nov '17

16 Nov '17

tor-relays-request(a)lists.torproject.org On Nov 16, 2017 3:22 AM, <tor-relays-request(a)lists.torproject.org> wrote: > Send tor-relays mailing list submissions to > tor-relays(a)lists.torproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > or, via email, send a message with subject or body 'help' to > tor-relays-request(a)lists.torproject.org > > You can reach the person managing the list at > tor-relays-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-relays digest..." > > > Today's Topics: > > 1. Re: Atlas is now Relay Search! (teor) > 2. Test (Alessandro Lo Mo) > 3. Re: Test (Paul Templeton) > 4. Re: Atlas is now Relay Search! (Iain R. Learmonth) > 5. Re: Atlas is now Relay Search! (r1610091651) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 16 Nov 2017 13:36:52 +1100 > From: teor <teor2345(a)gmail.com> > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] Atlas is now Relay Search! > Message-ID: <FA8F2762-65E0-430B-BAE1-E3B45827A464(a)gmail.com> > Content-Type: text/plain; charset="utf-8" > > > > On 15 Nov 2017, at 09:26, Iain R. Learmonth <irl(a)torproject.org> wrote: > > > > On 14/11/17 18:26, teor wrote: > >> No, it isn't: one of the new resources appears to be blocked by AdBlock > >> Plus for iOS. So it only works with content blockers turned off. You > probably > >> want to fix this eventually, because these blocklists are popular. And > the > >> issue likely affects multiple platforms. But it's not an all iOS > devices bug. > > > > I've tested with AdBlock Plus in Firefox and I cannot recreate this > problem. > > > > Can you tell me what resource it is that is blocked and what rule it is > > matching? > > No, I can't, because iOS ad blockers do not provide this information. > Did you add many resources in the transition? > > T > > -- > Tim / teor > > PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B > ricochet:ekmygaiu4rzgsk6n > ------------------------------------------------------------------------ > >

1 0

Atlas is now Relay Search!
by Iain R. Learmonth 16 Nov '17

16 Nov '17

Hi All, You may notice that Atlas has a new look, and is no longer called Atlas. For now no URLs have changed but this is part of work to merge this tool into the Tor Metrics website. The style is determined by the Tor Metrics Style, and modifications have been made to fit this. The decision was made to deploy these changes before the actual integration into metrics.torproject.org to allow for other issues to be worked on. This was a big change and it was tricky maintaining two branches of the codebase. Issues should still be reported on the Metrics/Atlas component in the Tor trac if they arise. When we come to full integration, URLs will change but there will be a period where we maintain redirects to prevent any URLs from breaking while waiting for being updated. Thanks, Iain.

13 30

Test
by Alessandro Lo Mo 15 Nov '17

15 Nov '17

Test

2 1

Re: [tor-relays] Atlas is now Relay Search!
by Arisbe 15 Nov '17

15 Nov '17

Hello All, I use to review my bridges as well as my relays on Atlas. Now I don't find my bridges on nyx. Is this something I'm doing wrong?

2 1

Re: [tor-relays] tor-relays Digest, Vol 82, Issue 23
by Patrice 14 Nov '17

14 Nov '17

How do I use a different IP address? I only got one. Should I pipe the traffic through a proxy (somewhere else)? Yeah, I though about to use the Tor browser but for my girlfriend I think not. Kind regards Kalle >> After reading all the answers, there seem to be only two solutions: >> 1. hoping that my IP get unbanned >> 2. shutdown the relay > Use a separate IP address for the relay > Run a bridge > >> (3. surf over a proxy or VPN) > Use Tor Browser? :-) > > T

2 1

Re: [tor-relays] Atlas is now Relay Search!
by Ralph Seichter 14 Nov '17

14 Nov '17

On 14.11.17 16:42, Artur Pedziwilk wrote: > Works OK on my Safari Version 11.0.1 (13604.3.5) and macOS 10.13.1 (17B48). Same versions here, but Relay Search does not work for me. URLs that are supposed to show node details don't work either, only the broken query page is shown. I tested this both with existing Atlas bookmarks and URLs copied over from Chrome. -Ralph

3 3

Re: [tor-relays] my IP got blocked
by Patrice 14 Nov '17

14 Nov '17

Sadly I run a only a relay therefore this is a troublesome action. So if more admins do this, I could be in trouble. After reading all the answers, there seem to be only two solutions: 1. hoping that my IP get unbanned 2. shutdown the relay (3. surf over a proxy or VPN) Kind regards Kalle >> Hi everyone, >> >> >> I`ve got an issue with my local IP address. I am running a relay about 1 >> year and since 3 or 4 weeks I can`t reach some websites like: ebay or ikea. >> >> All I get is this message: >> >> * >> * >> >> *Access Denied* >> You don`t have permission to access "Http://www.ebay.com/" on this server. >> >> Reference # ____looong number______ >> >> >> I think I am on some blacklists. After I change my IP address all worked >> fine for only 2 days. >> >> Can I do something about this? >> >> Thank you for your help! >> >> Kind regards >> Kalle >> > If you're running an exit, they probably saw abusive traffic, didn't > like it, and blocked your IP. You could consider not running an exit > relay from home. > > If you're running a non-exit, then they're being dumb for blocking your > IP when it is impossible for abusive traffic to come from your relay. > Some webmasters who don't understand Tor do that, but there's not really > anything we can do. Best I can suggest is you try talking to them, which > isn't a very satisfying suggestion, I know. > > Matt >

2 1

HS and relay - same server different tor instance
by blaze glory 14 Nov '17

14 Nov '17

2 2

PSA: exclude /var/lib/tor/diff-cache/ from your backups
by Roman Mamedov 14 Nov '17

14 Nov '17

Hello, Turns out that dir is highly variable, and judging from the name, also disposable. In my case it was responsible for about 20 GB of churn over a month, i.e. it took 25 GB to keep incremental backups of two Tor nodes with only 2 GB each in root FS (and I was wondering what's going on with my backup location's free space...) Dear Tor project: this is very bad style to keep that in /var/lib, content with properties like this must go into /var/cache/ [1], where it would be automatically excluded from backups by default policies in most backup systems. [1] http://www.pathname.com/fhs/pub/fhs-2.3.html#VARCACHEAPPLICATIONCACHEDATA -- With respect, Roman

3 2

Tor 0.3.2.4-alpha - debian packages available (important for fast exits)
by nusenu 13 Nov '17

13 Nov '17

If you are running a fast tor exit relay this fix is especially relevant for you: Nick Mathewson: > o Major bugfixes (exit relays, DNS): > - Fix an issue causing DNS to fail on high-bandwidth exit nodes, > making them nearly unusable. Fixes bugs 21394 and 18580; bugfix on > 0.1.2.2-alpha, which introduced eventdns. Thanks to Dhalgren for > identifying and finding a workaround to this bug and to Moritz, > Arthur Edelstein, and Roger for helping to track it down and > analyze it. Debian packages are available via deb.torproject.org now. If you want to stay with stable releases have a look at the following resolv.conf options: https://trac.torproject.org/projects/tor/wiki/doc/DnsResolver#Tuningeventdn… -- https://mastodon.social/@nusenu twitter: @nusenu_

1 1

New on relays and Tor
by Alfredo Bollati 13 Nov '17

13 Nov '17

Hi all I just started investigating and getting involved with Tor project. I have configured my router to port forwarding on one of its ports. Is there a way or some steps to follow in order to confirm that my bandwidth is being used by the relay? I have checked and the port it's open. Thanks -- Alfredo Bollati

6 5

OVH down
by Florentin Rochet 09 Nov '17

09 Nov '17

Hi all, A quick look this morning (UTC+1) at AS16276 (https://atlas.torproject.org/#search/as:AS16276) is a good example why we need more network diversity :-)

2 1

Exit Node Checking
by Kijani 07 Nov '17

07 Nov '17

Hi folks, Does anyone have a script for periodically updating strick exit nodes lists after running an inspection as per https://tc.gtisc.gatech.edu/bss/2014/r/spoiled-onions-slides.pdf or similar? Looking to help protect against crypto transaction sender redirect attacks. Many thanks

4 3

Re: [tor-relays] Nyx 2.0 Release
by Damian Johnson 07 Nov '17

07 Nov '17

Hi Stephanie, will this do the trick? http://blog.atagar.com/nyx-release-2-0/ On Tue, Nov 7, 2017 at 10:02 AM, Stephanie Whited <steph(a)torproject.org> wrote: > Glad we'll have a post up about this! > > Damian, do you want to write a draft and we can help polish or would you > like Tommy to write a draft first and get your feedback? > > -Steph > > > On 11/7/17 9:56 AM, Damian Johnson wrote: > > Thanks Tommy! Actually, I was just about to reach out to Stephanie to > ask how she would care to proceed with a tor blog post. Love to have > your professional touch on this Tommy. :P > > Cheers! -Damian > > On Tue, Nov 7, 2017 at 9:51 AM, Tommy Collison <tommyc(a)torproject.org> > wrote: > > Congrats on the launch, Damian! > > Want to write up something quick for the blog? If you want, I can pull > something together and run it by you. > > Tommy > > On 11/6/17 3:41 PM, Damian Johnson wrote: > > Hi all, after years of being in the works I'm pleased to announce Nyx! > A long overdue modernization of arm. > > http://blog.atagar.com/nyx-release-2-0/ > https://nyx.torproject.org/ > > Even more important for our controller space at large, Nyx is coming > hand-in-hand with Stem 1.6. A full year of improvements that include > descriptor creation support, ed25519 certificates, performance tuning, > and much, much more... > > https://stem.torproject.org/change_log.html#version-1-6 > > Cheers! -Damian > _______________________________________________ > 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 > > > -- > Stephanie A. Whited > Communications Director > The Tor Project

3 5

Testers needed for Nyx beta release
by Damian Johnson 07 Nov '17

07 Nov '17

Hi all! After five years Nyx (previously known as arm) is getting a far belated update. Under the covers the whole codebase has been rewritten from scratch, but for users things look much the same. One of those cases where... "When you do things right, people won't be sure you've done anything at all." -Futurama Main changes are... * Python 3.x support. * New website: https://nyx.torproject.org/ * Bandwidth graph now prepopulates when you start up, so you have a graph right away. * Connections are now available without togging DisableDebuggerAttachment in your torrc. * Support for showing IPv6 connections. * Dialog for picking tor events to log, rather than an arcane letter flag input. * Improved efficiency of log deduplication by multiple orders of magnitude. As such verbose logs no longer peg your CPU. * Richer control interpreter, including a python prompt like IDLE. * Removed features that frequently confused users such as the relay setup wizard and torrc validation. * Modernized dependencies. Nyx now uses Stem rather than TorCtl (which was deprecated in 2011). Our ducks should finally be in a row for release, but this being a full rewrite I'd like to start with an open beta to work out anything I might have missed. Would relay operators mind giving Nyx a whirl? To give it a try simply ensure you have a control port available in your torrc... ControlPort 9051 CookieAuthentication 1 ... and run the following... % git clone https://git.torproject.org/stem.git % git clone https://git.torproject.org/nyx.git % cd nyx/ % ln -s ../stem/stem stem % ./run_nyx Thanks! -Damian

17 71

Nyx 2.0 Release
by Damian Johnson 07 Nov '17

07 Nov '17

Hi all, after years of being in the works I'm pleased to announce Nyx! A long overdue modernization of arm. http://blog.atagar.com/nyx-release-2-0/ https://nyx.torproject.org/ Even more important for our controller space at large, Nyx is coming hand-in-hand with Stem 1.6. A full year of improvements that include descriptor creation support, ed25519 certificates, performance tuning, and much, much more... https://stem.torproject.org/change_log.html#version-1-6 Cheers! -Damian

4 5

Running both Transmission server and Tor relay
by Ch1keen 06 Nov '17

06 Nov '17

Transmission is the open source torrent application which supports web-based interface. So when users upload torrent files from other computers to that server, it automatically downloads files written in torrent files. I used that at my home server, but I'd like to use my server as Tor relay also. But as many knows, running BitTorrent over Tor is really bad idea. It seriously harms security of Tor network. So I thought about the solution about how to use them simultaneously. 1. One machine, Two services. If that situation not harms the security, I will use them on one machine. 2. Two machines, Two services. Running that services one machine to one service to avoid the crashes between two. 3. Gave up running one service. If really no way to run both, I will gave up running Transmission service. Which could be best solution I will make? Sent from ProtonMail mobile

5 6

handling of MyFamily for an outdated relay
by Toralf Förster 04 Nov '17

04 Nov '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Looking at his : I do wonder how to deal with deleting all /var/lib/tor/data2/* files of a Tor relay and running a new one with the same config (but now different key/fingerprint). I added the new fingerprint to the config, which now has 3 entries (the middle is 1 outdated): MyFamily 1AF72E8906E6C49481A791A6F8F84F8DFEBBB2BA,6EABEBF38CE7E3DF672C4DB01383606FE3EB2215,D11D11877769B9E617537B4B46BFB92B443DE33D Is this the right way ? I'm asking b/c I do see now "Alleged Family Members" here: https://atlas.torproject.org/#details/D11D11877769B9E617537B4B46BFB92B443DE… - -- Toralf PGP C4EACDDE 0076E94E -----BEGIN PGP SIGNATURE----- iI0EAREIADUWIQQaN2+ZSp0CbxPiTc/E6s3eAHbpTgUCWf3YchccdG9yYWxmLmZv ZXJzdGVyQGdteC5kZQAKCRDE6s3eAHbpTuLJAQCAmqnYRI5y4NpShgQp7kcdSTC2 MfrsfHkH3aObifTJ1wD9ERBkJN6zAIY7usN6sPy4VfHzAjkGaMTDLoBlYRA2f1w= =EQTO -----END PGP SIGNATURE-----

2 3

Monitoring multiple relays
by Xza 01 Nov '17

01 Nov '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello, I have a couple relays / exits running. Now my question is : how do you manage them is there any dashboard or CLI tools to manage them ( statistics, ect.. ) I know the cli tool specially for Tor "arm" Thanks alot. - -- PGP : 29A4CE52 -----BEGIN PGP SIGNATURE----- iQI4BAEBCgAiGxxEbyA8eWFuZGVyZXNvbkByaXNldXAubmV0PgUCV0SJlwAKCRBI of/XNyszSvv/D/9VtjI+bmiqK53v//StUbmpYjgQjYheYvwktFld+2XDURh52dmU sbk3lab2RS1eQJxjV0BVXMF9O2JUAlp4NA2UMpj8ZJlCk0h1S6p2o4/sAlsrHr8Z nb67HiaRIyEvi9cQiXFtDtK/onAkEuKskolyvh3ysJRRUubHSX1z8WuNJIc4xyGH ZpSLPGUOO6qI7mM8ztS0muEy1khmkHgtlyHi2l4K/NsW3I90cV3w6Db2AEnV6v1c tsfehqLExsHUdEo0U3hHU7yY1p2fzD5Z+C0tgVKTnP5Zus/Vr9OH/zFwxneo0E7a 5FHdnCZnNIG9W32uQgjDdmBEv/YFEd0um/vMWFGUehFANSt+DIps7E+AjwiJwm2i ov97JJurQkrSMX7ZchTEsy720Ju272olp2eDiHaXXTK2TkxcEq+d1gZfj7CXycPW 6mCrj6L6URJAZ34GJQfFFjv8QbFmKkAvGhxl/O8KXRbXxedbLH7PY73jmFjJcmxO +KnSeyqMe1KbzazYyFydP+VmgI2k1IlO89l8Jq1Gq9f2KOPY9UKFZjGDKLS0xGZW EnqU/KUINcrGejYFT8nYNxA+OFTd/ZGIX5qP4Vo5NsZ/pDLZjdxIcvHx1jjZbER+ 5Ku2bihm2KTNAGoYDqB3LGCm+QdEFG/p573xQCcXPk92GyhMJDi9EMPDgA== =mTa0 -----END PGP SIGNATURE-----

8 8

Exit offline
by D.S. Ljungmark 01 Nov '17

01 Nov '17

Sadly, we had some issues and had to take the modio exit offline for a while. We were seeing interesting traffic spikes on ipv6, and the pfsense firewall couldn't handle the traffic properly, so the relay will have to be offline until we got a replacement firewall in place. Try not to miss us too much. Regards, D.S.

1 1

stability of "Sandbox" feature
by fatal 31 Oct '17

31 Oct '17

Hey, the Tor manpage still states, that "the [sandbox] option is currently an experimental feature". How 'experimental' is it with e. g. Debian Stretch and using the torproject repo? Give it a try, or wait some more time? tnx f.

2 1

relayor v0.3.0 is released
by nusenu 31 Oct '17

31 Oct '17

Hi, relayor v0.3.0 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.1 FreeBSD 10.3, 11.1 HardenedBSD 11 Ubuntu 16.04 CentOS 7 Fedora 26 Notable changes since v0.2.1: ------------------------------ - enable tor's Sandbox feature by _default_ on Debian based systems - add support for automatic use of OutboundBindAddressExit via simple on/off boolean (opt-in) - add support for HardenedBSD - add support for tor alpha releases on FreeBSD/HardenedBSD - add support for more torrc options - performance improvement due to the use of dynamic includes (ansible) NOTE: The minimal required ansible version has been increased to 2.4.1 due to show-stopper bugs in older versions. regards, nusenu -- https://mastodon.social/@nusenu twitter: @nusenu_

1 0

Maximum of 2 Tor Instances per IP-Address (?)
by Petrarca 31 Oct '17

31 Oct '17

I read a few times at different places that there is a maximum of two Tor instances that can be run over one public IP address. My questions: 1) Is this statement true? 2) Is there an easy workaround maybe? 3) Just out of curiosity: what is the background for this limitation (if it is true)? Background: I was thinking about running several things on the onion network, e.g. one or more relays (maybe on different platforms?), hidden services (like wordpress, nextcloud), private tor client/access, etc. That would be all running over one internet connection with one WAN IP address with sufficient bandwidths. I probably could set most of it up on one platform/device but I think it might be better to implement them on separated devices rather (even different physical devices). Any comments are welcome - I'm always happy to learn :-) but

3 2

Thank you to directory operators
by Tor Node Admin ＠ SechsNullDrei.org 30 Oct '17

30 Oct '17

Good morning, Relay operators often receive gratitude on this list for running relays, but let's not forget the directory operators - those individuals/organizations who are more central to The Tor Network and run their directory servers at a higher personal risk level than the relay operators. Sincerely, Isaac, <mailto:Tor@SechsNullDrei.org> Tor(a)SechsNullDrei.org

3 2

UbuntuCore
by Paul Templeton 30 Oct '17

30 Oct '17

These nodes are popping up everywhere - is this some sort of malware being deployed on systems around the globe? Paul

5 4

Relay flag set counts
by grarpamp 29 Oct '17

29 Oct '17

1 s Authority Fast HSDir Running Stable V2Dir Valid 2 s Authority Fast Running Stable V2Dir Valid 7 s Authority Running Stable V2Dir Valid 270 s Exit Fast Guard HSDir Running Stable V2Dir Valid 58 s Exit Fast Guard Running Stable V2Dir Valid 25 s Exit Fast Guard Running Stable Valid 168 s Exit Fast HSDir Running Stable V2Dir Valid 71 s Exit Fast Running Stable V2Dir Valid 45 s Exit Fast Running Stable Valid 149 s Exit Fast Running V2Dir Valid 15 s Exit Fast Running Valid 7 s Exit Running Stable V2Dir Valid 10 s Exit Running Stable Valid 3 s Exit Running V2Dir Valid 2 s Exit Running Valid 1293 s Fast Guard HSDir Running Stable V2Dir Valid 311 s Fast Guard Running Stable V2Dir Valid 167 s Fast Guard Running Stable Valid 1721 s Fast HSDir Running Stable V2Dir Valid 513 s Fast Running Stable V2Dir Valid 469 s Fast Running Stable Valid 754 s Fast Running V2Dir Valid 200 s Fast Running Valid 96 s Running Stable V2Dir Valid 41 s Running Stable Valid 95 s Running V2Dir Valid 27 s Running Valid

1 0

"Fast" flag definition
by Igor Mitrofanov 29 Oct '17

29 Oct '17

Hi, It looks like 94.7% of all Running relays have the "Fast" flag now. If that percentage becomes 100%, the flag will become meaningless. What were the reasons behind the current definition of "Fast", and are those still valid? If not, should "Fast" become self-adjusting ("faster than 2 Mbps or 70% of all Guard relays, whichever is greater")? Thanks!

3 3

Exit probability
by Dr Gerard Bulger 29 Oct '17

29 Oct '17

How is exit probability counted? Is it only port 80 exit tested? I exit many 1000s of ports, including 443, but not those of high risk of abuse emails and thus upsetting the ISP. So port 80 along with others are blocked. I realise no port 80 limits the use of the exit so not expecting so see a high probability of exit. But Atlas shows none. Currently of some 3000 connections 200 are exit. Tor atlas show exit probability of 0.0000% Gerry -----Original Message----- From: tor-relays [mailto:tor-relays-bounces@lists.torproject.org] On Behalf Of teor Sent: 29 October 2017 12:45 To: tor-relays(a)lists.torproject.org Subject: Re: [tor-relays] sum of consensus weight of 2 relays running at the same IP On 29 Oct 2017, at 23:30, Toralf Förster <toralf.foerster(a)gmx.de> wrote: >> On 10/29/2017 01:24 PM, teor wrote: >> Possibly. >> >> Are the relays CPU-limited, or bandwidth-limited? > > Not at all, neither limited by a config value nor by the hardware > (1GBit/s, 200 MBit/s guaranteed, i7-3930, all non-Tor processes have > "nice" in front, ids are 1AF72E8906E6C49481A791A6F8F84F8DFEBBB2BA and > 6EABEBF38CE7E3DF672C4DB01383606FE3EB2215) I'm sorry, this doesn't help me answer your question. Usually, a relay is limited by either the available network bandwidth, or by the speed of a single CPU core on the machine. If the first relay used all the available bandwidth, then two relays will eventually have lower consensus weight values. If the first relay used all of a single CPU core for its main thread, then the two relays will eventually have similar consensus weight values. T _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

3 2

sum of consensus weight of 2 relays running at the same IP
by Toralf Förster 29 Oct '17

29 Oct '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I assumed that 2 Tor at the same ip address would get haöf of the consensus of the previously runnning only one Tor relay at the same hardware. But it semes, that both Tor relays get now the same value as the one before. Is this intended ? - -- Toralf PGP C4EACDDE 0076E94E -----BEGIN PGP SIGNATURE----- iI0EAREIADUWIQQaN2+ZSp0CbxPiTc/E6s3eAHbpTgUCWfW5BRccdG9yYWxmLmZv ZXJzdGVyQGdteC5kZQAKCRDE6s3eAHbpTse3AP9waxb9fe+ECq0QyR2PkS6Tw3j1 Lc+H7UafeeuUalHJngEAg9pg1jHzZnrEir03xCQEeP9HRrtfbKCUBo/AI/40KMo= =wt5I -----END PGP SIGNATURE-----

2 3

Testing Golang relay implementation
by Michael McLoughlin 28 Oct '17

28 Oct '17

All, I am working on a pure Golang relay implementation. https://github.com/mmcloughlin/pearl/ I have thus far been testing locally with chutney ( https://gitweb.torproject.org/chutney.git) The project is not complete by any stretch, but I believe I am close to the point where it can handle Tor network traffic. I expect I can learn *a lot* by running against real traffic rather than my sandboxed environment. I wanted to get in touch with the community before going live. Any advice gratefully received. The implementation identifies itself clearly in the server descriptor, both in the "platform" and "contact" items. If people notice any problems with the relay specifically they will be able to contact me. Thanks, Mike

9 17

Atlas / Onionoo ...
by Sebastian Urbach 27 Oct '17

27 Oct '17

Back on the road ;-) -- Sincerely yours / M.f.G. / Sincères salutations Sebastian Urbach --------------------------------------------------------------------------- Those who surrender freedom for security will not have, nor do they deserve, either one. --------------------------------------------------------------------------- Benjamin Franklin (1706-1790)

2 1

decrease in traffic
by Trey Nolen 26 Oct '17

26 Oct '17

I'm new to running a Tor relay and started one about a month ago. I've got 50 Mbps dedicated to it and at first it climbed in traffic pretty steadily until it got to around 25-30 Mbps being used. Since then, it has declined steadily and is down to about 350 KBps now (yes, I'm keeping the units straight). My node is a single core VPS running 3.2GHz and with 1GB RAM. Currently, top shows tor as using about 15% of the memory. When it was churning out at the maximum rate it got to, the CPU was pretty hammered. I was considering allocating another core, but there is no need anymore as it is hovering around 7% usage. The server is running on Ubuntu 16.04.3 and I'm running 0.3.1.7 tor. Am I doing something wrong to result in the decrease in traffic? Any advice is appreciated. Trey Nolen

6 14

"Onionoo seems to serve outdated data"
by tor 26 Oct '17

26 Oct '17

I see "Onionoo seems to serve outdated data :( Last update was: Tue Oct 24 2017" at the top of Atlas, and querying the Onionoo API directly results in the same outdated data. Anyone working on fixing it?

2 1

Balancing throughput versus getting Black-Holed
by Paul Templeton 25 Oct '17

25 Oct '17

Hi All, I have a question. I would like to know other peoples experiences for exit nodes and the methods of mitigating getting black holed. I have a node that gets black-holed all the time now - it runs at 18Mibt - 41781FDC57238DAB955DF6D6E8400CEC5ACBE706 I have noticed smaller relays/exits on the same AS don't seem to run into the same problem. I was thinking of running two to three smaller exits at around 4MiBt or just going for a larger faster middle. Thoughs/Comments. I have been emailing the provider and their carrier but know one ever responds/reply's. Paul

4 8

Re: [tor-relays] Troubleshooting rasptor4273 (was: Decline in relays)
by rasptor 4273 25 Oct '17

25 Oct '17

My IP/ORPORT is 24.132.17.230:9001. My relay is still running. arm shows traffic going through and several circuits on the connections page. And from my notices.log file: Oct 24 16:35:45.000 [notice] Heartbeat: It seems like we are not in the cached consensus. Oct 24 16:35:45.000 [notice] Heartbeat: Tor's uptime is 6 days 0:00 hours, with 2 circuits open. I've sent 47.17 MB and received 237.75 MB. Oct 24 16:35:45.000 [notice] Average packaged cell fullness: 66.463% Oct 24 16:35:45.000 [notice] TLS write overhead: 8% Oct 24 16:35:45.000 [notice] Circuit handshake stats since last time: 0/0 TAP, 0/0 NTor. However there's also a lot of this in that file: Oct 24 16:55:45.000 [warn] Your server (24.132.17.230:9001) has not managed to confirm that its ORPort is reachable. Please check your firewalls, ports, address, /etc/hosts file, etc. Oct 24 16:55:45.000 [warn] Your server (24.132.17.230:9030) has not managed to confirm that its DirPort is reachable. Please check your firewalls, ports, address, /etc/hosts file, etc. I added the log line to my torrc and sent a SIGHUP signal. Entries are being added to the log file, so that worked. Regards, Joep On Oct 23, 2017 22:59, "David Goulet" <dgoulet(a)torproject.org> wrote: On 23 Oct (22:49:55), rasptor 4273 wrote: > My relay has gone off the consensus. > Fingerprint: E7FFF8C3D5736AB87215C5DB05620103033E69C3 Interesting. And it is still running as of now without any problems? Can you give me the IP/ORPORT tuple? You think you can add this to your torrc and then HUP your relay (very importatnt to NOT restart it). Log info file <FULL_PATH_TO_LOG_FILE> And then after a some hours (maybe a day), we'll be looking for "Decided to publish new relay descriptor". If it appears, we know that your relay keeps uploading to the directory authorities so thus chances are that there is a problem on the dirauth side not finding you reachable. Thanks! David > Alias: rasptor4273 > Am running Tor 0.2.5.14 on Debian, Raspberry Pi 2B. I upgraded to that > version on September 3rd. > > I grepped through these: > https://collector.torproject.org/archive/relay-descriptors/consensuses/ and > the latest entry I found for my alias is in the file > ./17/2017-09-17-13-00-00-consensus. > > Not sure what other information I can provide. Do let me know if I can do > anything else to help troubleshoot. > > Best, > Joep > > On Mon, Oct 23, 2017 at 9:14 PM, George <george(a)queair.net> wrote: > > > David Goulet: > > > Hello everyone! > > > > > > Since July 2017, there has been a steady decline in relays from ~7k to > > now > > > ~6.5k. This is a bit unusual that is we don't see often such a steady > > behavior > > > of relays going offline (at least that I can remember...). > > > > > > It could certainly be something normal here. However, we shouldn't rule > > out a > > > bug in tor as well. The steadyness of the decline makes me a bit more > > worried > > > than usual. > > > > > > You can see the decline has started around July 2017: > > > > > > https://metrics.torproject.org/networksize.html?start= > > 2017-06-01&end=2017-10-23 > > > > > > What happened around July in terms of tor release: > > > > > > 2017-06-08 09:35:17 -0400 802d30d9b7 (tag: tor-0.3.0.8) > > > 2017-06-08 09:47:44 -0400 e14006a545 (tag: tor-0.2.5.14) > > > 2017-06-08 09:47:58 -0400 aa89500225 (tag: tor-0.2.9.11) > > > 2017-06-08 09:55:28 -0400 f833164576 (tag: tor-0.2.4.29) > > > 2017-06-08 09:55:58 -0400 21a9e5371d (tag: tor-0.2.6.12) > > > 2017-06-08 09:56:15 -0400 3db01d3b56 (tag: tor-0.2.7.8) > > > 2017-06-08 09:58:36 -0400 64ac28ef5d (tag: tor-0.2.8.14) > > > 2017-06-08 10:15:41 -0400 dc47d936d4 (tag: tor-0.3.1.3-alpha) > > > ... > > > 2017-06-29 16:56:13 -0400 fab91a290d (tag: tor-0.3.1.4-alpha) > > > 2017-06-29 17:03:23 -0400 22b3bf094e (tag: tor-0.3.0.9) > > > ... > > > 2017-08-01 11:33:36 -0400 83389502ee (tag: tor-0.3.1.5-alpha) > > > 2017-08-02 11:50:57 -0400 c33db290a9 (tag: tor-0.3.0.10) > > > > > > Note that on August 1st 2017, 0.2.4, 0.2.6 and 0.2.7 went end of life. > > > > > > That being said, I don't have an easy way to list which relays went > > offline > > > during the decline (since July basically) to see if a common pattern > > emerges. > > > > > > So few things. First, if anyone on this list noticed that their relay > > went off > > > the consensus while still having tor running, it is a good time to > > inform this > > > thread :). > > > > > > Second, anyone could have an idea of what possibly is going on that is > > have > > > one or more theories. Even better, if you have some tooling to try to > > list > > > which relays went offline, that would be _awesome_. > > > > > > Third, knowing what was the state of packaging in > > Debian/Redhat/Ubuntu/... > > > around July could be useful. What if a package in distro X is broken and > > the > > > update have been killing the relays? Or something like that... > > > > > > Last, looking at the dirauth would be a good idea. Basically, when did > > the > > > majority switched to 030 and then 031. Starting in July, what was the > > state of > > > the dirauth version? > > > > > > Any help is very welcome! Again, this decline could be from natural > > cause but > > > for now I just don't want to rule out an issue in tor or packaging. > > > > (Replying to OP since it went OT) > > > > As some of you know, TDP did a little suite of shell scripts based on > > OONI data to look at diversity statistics: > > > > https://torbsd.github.io/oostats.html > > > > With the source here for further tinkering: > > > > https://github.com/torbsd/tdp-onion-stats/ > > > > Maybe something we could look at is "exception reports", which in some > > industries means regular reports that look at anomalies or "exceptions" > > which display out-of-the-ordinary statistics, generally prompting some > > sort of action. > > > > In other words, daily reports would be run on, say, bw consensus by > > country, and if there was some statistically significant change over N > > periods of time, it would be noted. Or if a particular OS drops or > > jumps. Or if a particular AS jumps or declines for relays, bridges, > > whatever. > > > > If done right, a bunch of these reports could point to particular > > changes to the network that need further investigation, and in some > > cases, might quickly point to the related issue. Eg, countryX shutdown > > ISP with a particular AS number, etc. > > > > The more reports coupled with careful optimization over time could > > become an alarm system for Tor network changes, instead of just "er, > > such-and-such distro didnt update their packages then, I just found out > > in git." > > > > Thoughts? > > > > 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 > > > > > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays -- HiTVizeJUSe9JPvs6jBv/6i8YFvEYY/NZmNhD2UixVY= _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

2 2

Tor t-shirts
by Vasilis 24 Oct '17

24 Oct '17

Hello, During the last Tor meeting I asked some people about the Tor t-shirt situation and the big delays to processing and response and it seems that the situation has been resolved and person eligible for a t-shirt have either been notified or have already received them. Has everyone eligible for a Tor t-shirt got one already? Are there still people that are still waiting? Thank to everyone running/run Tor relays. Cheers, ~Vasilis -- Fingerprint: 8FD5 CF5F 39FC 03EB B382 7470 5FBF 70B1 D126 0162 Pubkey: https://pgp.mit.edu/pks/lookup?op=get&search=0x5FBF70B1D1260162

11 17

Just got my first Abuse email :-)
by Paul Templeton 22 Oct '17

22 Oct '17

It makes me happy but alas it was forwarded to me by the provider and didn't include an email address... so now I can not reply, SIGH Question: this has come from port 22 usage - how important is this port to the general population? Thoughts... Regards, Paul

6 6

Tor 0.3.1.7 - bug report
by diffusae 21 Oct '17

21 Oct '17

This instance is running forward. Oct 21 00:44:20.989 [notice] Tor 0.3.1.7 (git-6babd3d9ba9318b3) running on FreeBSD with Libevent 2.1.8-stable, OpenSSL 1.0.2j-freebsd, Zlib 1.2.8, Liblzma 5.2.2, and Libzstd 1.3.2. Oct 21 01:08:34.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. Oct 21 01:08:47.000 [notice] Performing bandwidth self-test...done. Oct 21 01:09:10.000 [warn] tor_bug_occurred_: Bug: src/common/compress.c:576: tor_compress_process: Non-fatal assertion !((rv == TOR_COMPRESS_OK) && *in_len == in_len_orig && *out_len == out_len_orig) failed. (on Tor 0.3.1.7 6babd3d9ba9318b3) Oct 21 01:09:10.000 [warn] Bug: Non-fatal assertion !((rv == TOR_COMPRESS_OK) && *in_len == in_len_orig && *out_len == out_len_orig) failed in tor_compress_process at src/common/compress.c:576. Stack trace: (on Tor 0.3.1.7 6babd3d9ba9318b3) Oct 21 01:09:10.000 [warn] Bug: Unable to generate backtrace. (on Tor 0.3.1.7 6babd3d9ba9318b3) Regards, --

2 2

"Removed 1565259696 bytes by killing 1 circuits"
by tor 21 Oct '17

21 Oct '17

In a relay's logs: Oct 20 10:31:47 XXXXX Tor[YYYY]: We're low on memory. Killing circuits with over-long queues. (This behavior is controlled by MaxMemInQueues.) Oct 20 10:32:11 XXXXX Tor[YYYY]: Removed 1565259696 bytes by killing 1 circuits; 40008 circuits remain alive. Also killed 0 non-linked directory connections. Tor removed ~ 1565 MB by killing 1 circuit? Seems like that can't be right? Earlier in the log I see "Based on detected system memory, MaxMemInQueues is set to 1500 MB." So either it's dumping the entire queue here, or the output is misleading. Or perhaps I don't understand how it works. It doesn't seem to be impactful; I'm just curious what's going on.

3 4

AccountingMax 48 GBytes is not working
by Artur Pędziwilk 20 Oct '17

20 Oct '17

Hi Tor operators, I have relay with AccountingMax 48 GBytes AccountingStart day 09:00 MaxMemInQueues 512 ServerTransportPlugin obfs4 exec /usr/local/bin/obfs4proxy managed The accounting seems stopped working since upgrade to tor-0.3.0.10 or enabling obfs4proxy. I am not fully sure, what do you think? https://atlas.torproject.org/#details/DFBF5EA4F70DC6639156BB71593F2A2E8FDA8… Oct 16 09:00:00 venator Tor[3519]: Configured hibernation. This interval began at 2017-10-16 09:00:00; the scheduled wake-up time was 2017-10-16 09:00:00; we expect to exhaust our quota for this interval around 2017-10-17 09:00:00; the next interval begins at 2017-10-17 09:00:00 (all times local) Oct 16 09:00:00 venator Tor[3519]: Hibernation period ended. Resuming normal activity. Oct 16 09:00:00 venator Tor[3519]: Opening Directory listener on 45.76.39.74:8080 Oct 16 09:00:00 venator Tor[3519]: Opening OR listener on 45.76.39.74:9090 Oct 16 09:00:00 venator Tor[3519]: Opening Extended OR listener on 45.76.39.74:46396 Oct 16 09:46:11 venator Tor[3519]: Heartbeat: Tor's uptime is 0:46 hours, with 11 circuits open. I've sent 192.00 GB and received 192.01 GB. Oct 16 09:46:11 venator Tor[3519]: Heartbeat: Accounting enabled. Sent: 5.42 MB, Received: 6.82 MB, Used: 6.90 MB / 48.00 GB, Rule: max. The current accounting interval ends on 2017-10-17 09:00:00, in 23:13 hours. Oct 16 09:46:11 venator Tor[3519]: Average packaged cell fullness: 12.851%. TLS write overhead: 2% Oct 16 09:46:11 venator Tor[3519]: Circuit handshake stats since last time: 12/12 TAP, 66/66 NTor. Oct 16 09:46:11 venator Tor[3519]: Since startup, we have initiated 0 v1 connections, 0 v2 connections, 0 v3 connections, and 35405 v4 connections; and received 16 v1 connections, 17 v2 connections, 1 v3 connections, and 29675 v4 connections. Oct 16 14:45:03 venator Tor[3519]: Bandwidth soft limit reached; commencing hibernation. No new connections will be accepted Oct 16 14:45:07 venator Tor[3519]: Going dormant. Blowing away remaining connections. Oct 16 15:46:11 venator Tor[3519]: Heartbeat: Tor's uptime is 6:46 hours, with 0 circuits open. I've sent 239.99 GB and received 239.98 GB. We are currently hibernating. Oct 16 15:46:11 venator Tor[3519]: Circuit handshake stats since last time: 27077/27077 TAP, 747536/747536 NTor. Oct 16 15:46:11 venator Tor[3519]: Since startup, we have initiated 0 v1 connections, 0 v2 connections, 0 v3 connections, and 44017 v4 connections; and received 17 v1 connections, 22 v2 connections, 2 v3 connections, and 37042 v4 connections.

5 7

my relay 'alnsn' died
by Alexander Nasonov 19 Oct '17

19 Oct '17

B9A41AD7AE8B2A4E6DE96EE77E3C8C04BADA8AC0 is currently down because harware died this morning. I will either reinstall it or move to a different AS. In any case, it won't happen tomorrow. I hope to have it up and running on the weekend. Master key is safe because it's on a different machine. Alex

2 1