- tor-relays - lists.torproject.org

is it possible to relay using ipv6?
by Flavio Leitner 18 Dec '16

18 Dec '16

Hi, I am trying to configure a relay for the first time but I am behind a cgnat for IPv4. I have a public and open IPv6 though. However, ORPort doesn't accept [ipv6]:443 and it doesn't automatically bind to :::443 either. This is running LEDE tor 0.2.8.9-1. I couldn't find if worth to run over IPv6 or not. Thanks, -- Flavio

10 25

"Up-and-coming" Ticket - 33C3
by pa011 17 Dec '16

17 Dec '16

Have Juniors interested in our work, likely to follow our steps or build new ones...need tickets for Hamburg 33C3 "Up-and-coming" would be great, but would consider "Standard" as well... Hopefully :-) Thanks and regards Paul

1 0

zencurity.dk relays: MyFamily update required
by nusenu 17 Dec '16

17 Dec '16

Hi, thanks for adding an additional relay to the tor network, please do not forget to update your MyFamily setting - especially because your new relay is outside of the /16 netblock of your other relays. And maybe update your tor version (0.2.7.6 is fairly old). https://raw.githubusercontent.com/ornetstats/stats/master/o/potentially_dan… +---------------------+--------------+---------------+ | first_seen | nickname | MyFamilyCount | +---------------------+--------------+---------------+ | 2016-07-25 22:00:00 | kramse3 | 3.0000 | | 2016-01-07 22:00:00 | kramse | 3.0000 | | 2016-01-07 23:00:00 | kramse2 | 3.0000 | | 2016-12-16 14:00:00 | kramseturris | NULL | +---------------------+--------------+---------------+ regards, nusenu

1 0

Netflix overblocking non-exit Tor relays
by Gero Kuehn 16 Dec '16

16 Dec '16

tl;dr: Even paying customers sharing IPs with non-exit Tor relays are now blocked from accessing Netflix Hello everyone ! After two very fruitless attempts to get the issue silently resolved through proper Netflix support channels, the time has come to make this public. As some of you have probably already read in the news, Netflix recently announced a crackdown on what they call "VPN Pirates" and what I call "paying customers using the same benefits of globalization that global companies like Netflix (ab)use for their taxes". They have now obviously changed their strategy regarding the Tor network. I am operating (among others) a middle-relay on a German residential fixed-ip VDSL-50 line (dc6jgk1/486740353B905AA4731F82C0B4CC25821A62C6E3) behind a NAT. Until 2 days ago, none of the devices sharing the same external IP address had any problem connecting to Netflix and there never was a Tor exit relay on that IP as far as I can tell. It is also obviously not possible for users of the Tor network to connect to Netflix through middle relays. As a consequence they should not be classifying such IP addresses as VPNs/Proxies and they should not be blocking them. This has been escalated and explained twice to "technical supervisors" in their callcenters. They did however not leave the impression that they a) care or b) intend to fix this at some point by parsing the Tor network information properly instead of using whatever cheap&wrong hack they use now. The official response from Netflix is that you now need to make a choice between operating that Tor relay (of any type) and the ability to watch Netflix. They also strictly refuse to refund any remaining credit in the customer account. My personal choice with regards to that blackmailing is as clear my next steps (conditional cancellation, 14 day deadline for refund and a legal challenge of their German AGB with regards to this issue). I am allergic to being blackmailed like that and being called a pirate by a service I legitimately paid for. For those of you who just would like to contribute to the Tor network without having trouble like that, please do not let this nonsense stop you. A more diversified Tor network is a more healthy network and I would really like to see more normal users operating tor relays operating in as many different locations as possible - including DSL lines "that are there anyways". If you do not want to be put into a position where you have to choose between your contribution to the network and some legal and paid-for entertainment, you might want to operate only a bridge until the issue has been resolved. If you already have the same problem, make it as expensive for Netflix as possible and spread the word about why this block (and geoblocking in general) is wrong. Thanks ! Kind regards, Gero / dc6jgk

14 21

Re: [tor-relays] Tor relay from home - end of experiment?
by balbea16 15 Dec '16

15 Dec '16

Hi Peter unfortunately your message is empty, it only shows the signature. This occurs with all signed messages. I have no idea how to solve the problem.Mike -------- Ursprüngliche Nachricht -------- Von: Peter Ludikovsky <peter(a)ludikovsky.name> Datum: 15.12.16 07:22 (GMT+01:00) An: tor-relays(a)lists.torproject.org Betreff: Re: [tor-relays] Tor relay from home - end of experiment? _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

2 1

Re: [tor-relays] Tor relay from home - end of experiment?
by balbea16 15 Dec '16

15 Dec '16

Hi J. I know. But I need a fan on top of the sinks. Just the heat sinks are not efficient enough. -------- Ursprüngliche Nachricht -------- Von: Rana <ranaventures(a)gmail.com> Datum: 15.12.16 11:19 (GMT+01:00) An: tor-relays(a)lists.torproject.org Betreff: Re: [tor-relays] Tor relay from home - end of experiment? I meant aluminum heat sink, not a fanHeat sinks do not make noise, they are flat pieces of metal with rib structure for improved heat radiation. You glue them on the chips that tend to become hot as they crunch your Tor relay traffic. But hey, whatever turns you on J

1 0

Re: [tor-relays] Tor relay from home - end of experiment?
by balbea16 15 Dec '16

15 Dec '16

J, TNX for the recommendation. Just used a spare one. Temperature dropped to 41 C. Didn't like the noise, because it's running permanentely. However, you are right :-) -------- Ursprüngliche Nachricht -------- Von: Rana <ranaventures(a)gmail.com> Datum: 15.12.16 09:34 (GMT+01:00) An: tor-relays(a)lists.torproject.org Betreff: Re: [tor-relays] Tor relay from home - end of experiment? Well I do suggest that you get a set of Pi heat sinks on ebay for $0.70 (including postage from China, adhesive and sinks for all 3 chips on the Pi). And if you are as extravagant as I you will even shell out an additional $1.20 for a Pi case. Your 20 mbps relay has some value, you do not want to step on it accidentally J From: tor-relays [mailto:tor-relays-bounces@lists.torproject.org] On Behalf Of balbea16 Sent: Thursday, December 15, 2016 10:24 AM To: tor-relays(a)lists.torproject.org Subject: Re: [tor-relays] Tor relay from home - end of experiment? You are totally right. Besides the "cost" for the PI, I pay some additional Euros per month for the 40 MBIT upload, that's it. I really can recomment to run a relay on a Pi 3. Let's see how the Tor authorities handle this. By the way the CPU temperature levels around 60 Celsius (without running arm). I don't cool it. Mike Von meinem Samsung Gerät gesendet. -------- Ursprüngliche Nachricht -------- Von: Rana <ranaventures(a)gmail.com> Datum: 15.12.16 08:53 (GMT+01:00) An: tor-relays(a)lists.torproject.org Betreff: Re: [tor-relays] Tor relay from home - end of experiment? OK then let me summarize. 1. You are running a Pi from Cologne, at 21 mbps (measured) peak, 900 kbps (measured) average utilization by Tor, with 1300 connections.2. Your Pi is under-utilized, probably limited by your ISP’s peering with those to which DirAuths are connected. 20% CPU utilization, 50% memory utilization. 3. Given that part of the memory is used by Linux kernel, and that the PI Ethernet interface is nominally 100 mbps, the Pi is probably able to sustain up to 3000 connections. Bottom line: the $35 Pi is a killer and running a Tor node with up to 3000 connections on another computer is probably a big waste of money. Comments welcome. From: tor-relays [mailto:tor-relays-bounces@lists.torproject.org] On Behalf Of balbea16 Sent: Thursday, December 15, 2016 9:04 AM To: tor-relays(a)lists.torproject.org Subject: Re: [tor-relays] Tor relay from home - end of experiment? Pls. refer to may answers after each of your questions. -------- Ursprüngliche Nachricht -------- Von: Rana <ranaventures(a)gmail.com> Datum: 15.12.16 07:44 (GMT+01:00) An: tor-relays(a)lists.torproject.org Betreff: Re: [tor-relays] Tor relay from home - end of experiment? >Hi There>This is a pretty interesting topic. I have been running a Rasp Pi 3 based relay since August this year. By now, I am up to about 1,300 incomming and outgoing connections, and a max of >about 21mbps. This is about 50% of the max. upload speed. Consensus weight is between 3,000 and 6,000. The CPU is running at 20% max. However, my local ISP disconnects me after 24 >to 36 hours. From my point of view this is the only disadvantage. > >For a home based relay, is that good, bad, or just average? Is there a chance for me to get a stable, or even guard flag? What are your experiances?>MikeMy experience is bad, the relay is not taking off at all, I have consensus weight of 19 and am sending less than 20 MB every 6 hours despite having bandwidth measured by Tor of between 70 and 120 KB/s. The total up bandwidth I have in ISP connection is 1.5 mbps and this is probably the issue. I also run this on Pi 3. I did, however, get a stable flag after 5 days, and have had it since then. My IP is dynamic and did not change in these 5 days or in the 4 days that passed since I got the Stable flag. My relay nickname is ZG0.Based on your experience I think your are doing fabulously well for a home relay, and that what really counts is the ISP bandwidth, and the Stable flag does not have much to do with how much traffic you get. Moreover, your 20% cpu util confirms my opinion that Pi is the perfect, most cost efficient way to run a relay and that running it on a larger computer is a waste of resources and money (up to the point Raspi chokes which we are yet to discover J)Moreover, clearly Pi’s cpu power will never be the bottleneck, only its memory size. You have a total of 1GB of memory on your Pi 3, what’s your memory utilization? about 513 MB What’s the total traffic the Pi sends every 6 hours (reported in the Tor log file /var/log/tor/notices.log and, for the previous time window, in /var/log/tor/notices.log.1)? About 19 GB in the last 6 hour period, with a total sent 2671.53 GB and received 2625.31 GB. What’s your relay’s nickname? Balbea16

2 1

Re: [tor-relays] Tor relay from home - end of experiment?
by balbea16 15 Dec '16

15 Dec '16

You are totally right. Besides the "cost" for the PI, I pay some additional Euros per month for the 40 MBIT upload, that's it. I really can recomment to run a relay on a Pi 3. Let's see how the Tor authorities handle this. By the way the CPU temperature levels around 60 Celsius (without running arm). I don't cool it. Mike Von meinem Samsung Gerät gesendet. -------- Ursprüngliche Nachricht -------- Von: Rana <ranaventures(a)gmail.com> Datum: 15.12.16 08:53 (GMT+01:00) An: tor-relays(a)lists.torproject.org Betreff: Re: [tor-relays] Tor relay from home - end of experiment? OK then let me summarize. 1. You are running a Pi from Cologne, at 21 mbps (measured) peak, 900 kbps (measured) average utilization by Tor, with 1300 connections.2. Your Pi is under-utilized, probably limited by your ISP’s peering with those to which DirAuths are connected. 20% CPU utilization, 50% memory utilization. 3. Given that part of the memory is used by Linux kernel, and that the PI Ethernet interface is nominally 100 mbps, the Pi is probably able to sustain up to 3000 connections. Bottom line: the $35 Pi is a killer and running a Tor node with up to 3000 connections on another computer is probably a big waste of money. Comments welcome. From: tor-relays [mailto:tor-relays-bounces@lists.torproject.org] On Behalf Of balbea16 Sent: Thursday, December 15, 2016 9:04 AM To: tor-relays(a)lists.torproject.org Subject: Re: [tor-relays] Tor relay from home - end of experiment? Pls. refer to may answers after each of your questions. -------- Ursprüngliche Nachricht -------- Von: Rana <ranaventures(a)gmail.com> Datum: 15.12.16 07:44 (GMT+01:00) An: tor-relays(a)lists.torproject.org Betreff: Re: [tor-relays] Tor relay from home - end of experiment? >Hi There>This is a pretty interesting topic. I have been running a Rasp Pi 3 based relay since August this year. By now, I am up to about 1,300 incomming and outgoing connections, and a max of >about 21mbps. This is about 50% of the max. upload speed. Consensus weight is between 3,000 and 6,000. The CPU is running at 20% max. However, my local ISP disconnects me after 24 >to 36 hours. From my point of view this is the only disadvantage. > >For a home based relay, is that good, bad, or just average? Is there a chance for me to get a stable, or even guard flag? What are your experiances?>MikeMy experience is bad, the relay is not taking off at all, I have consensus weight of 19 and am sending less than 20 MB every 6 hours despite having bandwidth measured by Tor of between 70 and 120 KB/s. The total up bandwidth I have in ISP connection is 1.5 mbps and this is probably the issue. I also run this on Pi 3. I did, however, get a stable flag after 5 days, and have had it since then. My IP is dynamic and did not change in these 5 days or in the 4 days that passed since I got the Stable flag. My relay nickname is ZG0.Based on your experience I think your are doing fabulously well for a home relay, and that what really counts is the ISP bandwidth, and the Stable flag does not have much to do with how much traffic you get. Moreover, your 20% cpu util confirms my opinion that Pi is the perfect, most cost efficient way to run a relay and that running it on a larger computer is a waste of resources and money (up to the point Raspi chokes which we are yet to discover J)Moreover, clearly Pi’s cpu power will never be the bottleneck, only its memory size. You have a total of 1GB of memory on your Pi 3, what’s your memory utilization? about 513 MB What’s the total traffic the Pi sends every 6 hours (reported in the Tor log file /var/log/tor/notices.log and, for the previous time window, in /var/log/tor/notices.log.1)? About 19 GB in the last 6 hour period, with a total sent 2671.53 GB and received 2625.31 GB. What’s your relay’s nickname? Balbea16

2 1

Re: [tor-relays] Tor relay from home - end of experiment?
by balbea16 15 Dec '16

15 Dec '16

Pls. refer to may answers after each of your questions. -------- Ursprüngliche Nachricht -------- Von: Rana <ranaventures(a)gmail.com> Datum: 15.12.16 07:44 (GMT+01:00) An: tor-relays(a)lists.torproject.org Betreff: Re: [tor-relays] Tor relay from home - end of experiment? >Hi There>This is a pretty interesting topic. I have been running a Rasp Pi 3 based relay since August this year. By now, I am up to about 1,300 incomming and outgoing connections, and a max of >about 21mbps. This is about 50% of the max. upload speed. Consensus weight is between 3,000 and 6,000. The CPU is running at 20% max. However, my local ISP disconnects me after 24 >to 36 hours. From my point of view this is the only disadvantage. > >For a home based relay, is that good, bad, or just average? Is there a chance for me to get a stable, or even guard flag? What are your experiances?>MikeMy experience is bad, the relay is not taking off at all, I have consensus weight of 19 and am sending less than 20 MB every 6 hours despite having bandwidth measured by Tor of between 70 and 120 KB/s. The total up bandwidth I have in ISP connection is 1.5 mbps and this is probably the issue. I also run this on Pi 3. I did, however, get a stable flag after 5 days, and have had it since then. My IP is dynamic and did not change in these 5 days or in the 4 days that passed since I got the Stable flag. My relay nickname is ZG0.Based on your experience I think your are doing fabulously well for a home relay, and that what really counts is the ISP bandwidth, and the Stable flag does not have much to do with how much traffic you get. Moreover, your 20% cpu util confirms my opinion that Pi is the perfect, most cost efficient way to run a relay and that running it on a larger computer is a waste of resources and money (up to the point Raspi chokes which we are yet to discover J)Moreover, clearly Pi’s cpu power will never be the bottleneck, only its memory size. You have a total of 1GB of memory on your Pi 3, what’s your memory utilization? about 513 MB What’s the total traffic the Pi sends every 6 hours (reported in the Tor log file /var/log/tor/notices.log and, for the previous time window, in /var/log/tor/notices.log.1)? About 19 GB in the last 6 hour period, with a total sent 2671.53 GB and received 2625.31 GB. What’s your relay’s nickname? Balbea16

2 1

Re: [tor-relays] Tor relay from home - end of experiment?
by balbea16 15 Dec '16

15 Dec '16

Hi ThereThis is a pretty interesting topic. I have been running a Rasp Pi 3 based relay since August this year. By now, I am up to about 1,300 incomming and outgoing connections, and a max of about 21mbps. This is about 50% of the max. upload speed. Consensus weight is between 3,000 and 6,000. The CPU is running at 20% max. However, my local ISP disconnects me after 24 to 36 hours. From my point of view this is the only disadvantage. For a home based relay, is that good, bad, or just average? Is there a chance for me to get a stable, or even guard flag? What are your experiances?Mike

2 1

Tor relay from home - end of experiment?
by Rana 15 Dec '16

15 Dec '16

After 9 days of running a relay with a stable IP address (with "Stable" flag during the last 4 days) and consensus bw steadily oscillating around 20 despite the 100 Kbyte/s bandwidth measured by Tor and 200 Kbyte/s bandwidth measured on the Internet connection, I guess it is time to quit. My relay is consistently sending less than 20MB every 6 hours, which probably means that is not making a noticeable contribution to Tor network. I have also been running another relay for the last 5 days from a friend's home - he has a static IP, a different ISP from mine and twice the bandwidth. His consensus is bw dead locked at 31 and never changes. He is getting Fast flag on and off, no Stable flag, his Atlas measured bandwidth is 150 KB/s. The traffic it relays is only slightly larger than mine, so I guess it is time to quit for this one, too. Any other advice / ideas welcome. Rana

6 17

Did you recently start >750 bridges?
by nusenu 14 Dec '16

14 Dec '16

Hi, If you recently added >750 bridges (without malicious intend) or know anything about it, please read this thread: [1] https://lists.torproject.org/pipermail/tor-project/2016-December/000851.html and get in contact with them (without disclosing the location of your bridges to the public). regards, nusenu

1 0

Does the "Advertised bandwidth" correlates with the "Consensus Weight"
by Toralf Förster 13 Dec '16

13 Dec '16

2 2

FW: Relay Shirt
by I 12 Dec '16

12 Dec '16

1 0

Draft Fallback Directory List
by teor 12 Dec '16

12 Dec '16

(This is a copy of the email I BCC'd to each relay operator on the draft fallback directory list. Please email me to add your relays.) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Dear Tor Relay Operator, One or more of your relays have been selected as fallback directory mirrors[0] for the next tor release. Please keep the relay available on the same addresses, ports, and identity key (fingerprint) for the next 2 years. This is a draft list.[3] I can make changes for the next week. Next weekend, I will send another email to those operators whose relays have been added or removed. (Otherwise, you're on the list.) We are taking 3 relays per operator, if you only have 1 or 2 on the list, please email me to add more. Wondering why your relay didn't make the list? Search the selection log[4] for its fingerprint. If the log says: * in neither blacklist nor whitelist, email me to add your relay. (I run a script that checks relays, then outputs a list.) If it says: * not a candidate: version delivers stale consensuses, * not a candidate: version not recommended, * not a candidate: changed address/port recently (on 0.2.7.6 or earlier), or * outdated consensus, upgrade to 0.2.8.9 or later, or 0.2.9.5-alpha or later. If it says: * bandwidth too low, * download too slow, * HTTP Error 503: Directory busy, * or some sort of download connection error, it might help to give your relay more memory or bandwidth. (And please make sure it's still running!) If it says: * not a candidate: changed address/port recently, * not a candidate: guard avg too low, * not a candidate: running avg too low, or * not a candidate: v2dir avg too low, your relay needs to be consistently up with high bandwidth to help clients. Try keeping it stable for 6-12 months, and it might be selected next time. But don't worry, your relay(s) are still helping the tor network, even if they are not selected as a fallback. Tim [0]: https://trac.torproject.org/projects/tor/wiki/doc/FallbackDirectoryMirrors [3]: https://trac.torproject.org/projects/tor/attachment/ticket/18828/draft_fall… (or [8] if you want to see what the git commit will look like) [4]: https://trac.torproject.org/projects/tor/attachment/ticket/18828/draft_fall… [8]: https://github.com/teor2345/tor/blob/new-fallbacks-028-v2/src/or/fallback_d… From: teor <teor2345(a)gmail.com> Subject: Call for Tor Fallback Directories Date: 4 December 2016 at 21:44:39 AEDT To: tor-relays(a)lists.torproject.org Dear Tor Relay Operator, Your relay(s) can help tor clients find the tor network by becoming a fallback directory mirror.[0] These mirrors are hard-coded into tor's source code, like the directory authorities. We have 80 fallbacks, but we want 200 for the next release. Fallbacks need to have: - - the same IP address(es) and ports for the next 2 years, - - the same relay identity key for the next 2 years, - - good uptime (at least 95%), and - - good bandwidth and network connectivity (we estimate an extra 25GB per month). Please email me to add your relays that fit these criteria to the list. If you are BCC'd on this email, it looks like you have at least one relay that could become a fallback. You can also email me if you know your relay will be changing address or key, and I'll make sure we don't choose it. We are keeping the fallback lists from the last release[1][2]. So if you have emailed me before about becoming a fallback, there is no need to email again. But please let me know if your relay details have changed. (I did not BCC relay operators who are already on the fallback lists, unless their relay details changed.) In a week or two, I will run a script to select the hard-coded list for the release. If you're interested, here's some background to this request: The latest list[3] and log[4] of candidates was generated using the instructions in [5] from scripts/maint/updateFallbackDirs.py on my GitHub branch[6]. (This branch has some bug fixes compared to what's in master.) We're tracking this work in [7]. (links updated to the latest code and relay list) [0]: https://trac.torproject.org/projects/tor/wiki/doc/FallbackDirectoryMirrors [1]: https://github.com/teor2345/tor/blob/fallbacks-201612-v4/scripts/maint/fall… [2]: https://github.com/teor2345/tor/blob/fallbacks-201612-v4/scripts/maint/fall… [3]: https://trac.torproject.org/projects/tor/attachment/ticket/18828/draft_fall… [4]: https://trac.torproject.org/projects/tor/attachment/ticket/18828/draft_fall… [5]: https://trac.torproject.org/projects/tor/wiki/doc/UpdatingFallbackDirectory… [6]: https://github.com/teor2345/tor/blob/fallbacks-201612-v4/scripts/maint/upda… [7]: https://trac.torproject.org/projects/tor/ticket/18828 T -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYTT+RAAoJEEUMun+WjwlLjdMP+gNwaBXpxrBy5e/0DJKoqpna /exFMCaLk1UNh5sko6IgCY+C4NbjCqwZ2NX78iJsLNzEyy+mXS/SoAeygSgiGIea d7ZgLlsj0z6JHYV/vqvKp3xs0lSUJIhd3tsaJWSZqylZVdDVzeE4o+kJtXMlOrk9 lnb+Xo9HzBKiWjSObnnli6+I4v5Z6SHidR7SYGe1N4bavDTrjnl6BCpS64QlrGwp mnM9iPNmv491soVMAKvgDX0dx6UncO6x+88jWa9OBHvkFPjNw7YQVMHsa4ltDfZQ kR2XinhpSYrvP/JFieXSP0DYNgaSdMhaKApStPs8xxP/RPfqioAcV3BopRVi0SpA jie9Z7wHUbtAZEobKpb4a8cnkfwB2j4GmVIlnSwXHmEipwCOI+Eat2qfFL6Z2xMo 0qLE7YDa3Fmjl9fbyU5H7fDgJUGMiSipEmKeC32wXfTVY424Fb3V4SXHS2qTCuQc QsfoW+12gXBemGSGAJRhvG46iG6u7+Xg/K8El+URU0Tk+QfRIGDzyLVNNQxuAuyl PtXBgxAbERh5uC8cyiKi9EugMx6NzRFtxto74XLdAuCGzbSD3HfNOEh43i/JwScO mo4bUC/bPXgtQGLCtbP8j+ieneSZom10vjspahrhasyNpFntaPor7+PvZ1vuA0JR rTv/DEYIjv6oKAstwT+C =APJ7 -----END PGP SIGNATURE----- T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------

3 7

Re: [tor-relays] Second relay on same ESX
by balbea16 12 Dec '16

12 Dec '16

Hi Are you actually talking about identical relays, i.e. with the same fingerprint? That would be interessting for me, as I'd like to run a second Rasp Pi in parallel for redundency reasons.Mike -------- Ursprüngliche Nachricht -------- Von: Patrick DERWAEL <patrick(a)derwael.be> Datum: 12.12.16 06:41 (GMT+01:00) An: tor-relays(a)lists.torproject.org Betreff: Re: [tor-relays] Second relay on same ESX John, The host has 32GB RAM& 4 CPUs I have allocated 2GB & 2CPUs to my VM As the VM CPU usage is +/-40%, I'm not sure if I should reduce to 1CPU (would it then be used at 80% average?) P. 2016-12-11 18:22 GMT+01:00 John Ricketts <john(a)quintex.com>: Patrick, I run all of my relays under VMware and I don't have any issues at all. How many CPUs do you have in the physical server and how many virtual CPUs do you have assigned to the VM? John On Dec 11, 2016, at 11:19, Patrick DERWAEL <patrick(a)derwael.be> wrote: Hi guys, I'm running a relay in a VM on a physical server which is largely under used Current advertised bandwidth 26MB, consensus 76500 I'm considering running a second relay (2nd VM) on the very same hardware, but this brings a few questions: - is there any issue running it at the same geographical place? - would the current total BW effectively consumed (26MB) be divided in 2 (i.e. no added value in BW)? - basically, would it have any significant added value to the network? Thanks _______________________________________________ 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 -- Patrick Derwael Rue de la fontaine, 3 4210 Burdinne G:0479.80.50.79

3 2

Re: [tor-relays] Second relay on same ESX
by balbea16 12 Dec '16

12 Dec '16

Hi Tim,TNX for your fast response. That was more or less what I thought already. Mike -------- Ursprüngliche Nachricht -------- Von: teor <teor2345(a)gmail.com> Datum: 12.12.16 07:28 (GMT+01:00) An: tor-relays(a)lists.torproject.org Betreff: Re: [tor-relays] Second relay on same ESX > On 12 Dec. 2016, at 17:08, balbea16 <balbea16(a)gmx.de> wrote: > > Hi > Are you actually talking about identical relays, i.e. with the same fingerprint? That would be interessting for me, as I'd like to run a second Rasp Pi in parallel for redundency reasons. > Mike Please don't run a second relay on the same fingerprint. Your relay won't get much traffic, because it will look like its address and ports are changing all the time. Instead, run two relays with different keys, and let the network load-balance between them. Tim > -------- Ursprüngliche Nachricht -------- > Von: Patrick DERWAEL <patrick(a)derwael.be> > Datum: 12.12.16 06:41 (GMT+01:00) > An: tor-relays(a)lists.torproject.org > Betreff: Re: [tor-relays] Second relay on same ESX > > John, > The host has 32GB RAM& 4 CPUs > I have allocated 2GB & 2CPUs to my VM > As the VM CPU usage is +/-40%, I'm not sure if I should reduce to 1CPU (would it then be used at 80% average?) > > P. > > 2016-12-11 18:22 GMT+01:00 John Ricketts <john(a)quintex.com>: > Patrick, > > I run all of my relays under VMware and I don't have any issues at all. > > How many CPUs do you have in the physical server and how many virtual CPUs do you have assigned to the VM? > > John > > On Dec 11, 2016, at 11:19, Patrick DERWAEL <patrick(a)derwael.be> wrote: > >> Hi guys, >> >> I'm running a relay in a VM on a physical server which is largely under used >> Current advertised bandwidth 26MB, consensus 76500 >> I'm considering running a second relay (2nd VM) on the very same hardware, but this brings a few questions: >> >> - is there any issue running it at the same geographical place? >> - would the current total BW effectively consumed (26MB) be divided in 2 (i.e. no added value in BW)? >> - basically, would it have any significant added value to the network? >> >> Thanks >> >> _______________________________________________ >> 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 > > > > > -- > Patrick Derwael > Rue de la fontaine, 3 > 4210 Burdinne > G:0479.80.50.79 > > > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------ _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

1 0

Second relay on same ESX
by Patrick DERWAEL 12 Dec '16

12 Dec '16

Hi guys, I'm running a relay in a VM on a physical server which is largely under used Current advertised bandwidth 26MB, consensus 76500 I'm considering running a second relay (2nd VM) on the very same hardware, but this brings a few questions: - is there any issue running it at the same geographical place? - would the current total BW effectively consumed (26MB) be divided in 2 (i.e. no added value in BW)? - basically, would it have any significant added value to the network? Thanks

4 5

network scan results for CVE-2016-5696 / rfc 5961
by dawuud 11 Dec '16

11 Dec '16

Greetings Tor relay operators, First of all, if you operate non-Linux Tor relays then good job! Thanks! This notice isn't for you. Only Linux is affected. This morning I scanned the tor network for vulnerability to CVE-2016-5696 [1], again so that I could compare the results with the scan from last month. Linux implemented RFC 5961 [2] using a global counter which can be used as a side channel allowing blind TCP injection and other consequences as well. I used this collector consensus file for my scan: https://collector.torproject.org/recent/relay-descriptors/consensuses/2016-… That's 7080 relays. The scan produced: 246 relays had connection timeouts and were not scanned. 60 relays had connection refused. 6795 relays scanned. 2034 relays are vulnerable according to the rationale I used a month ago to categorized the results as vulnerable (if the probe response receives between 90 and 220 Challenge ACKs). These results should be reproducible. The source code to the scanner is here: https://github.com/david415/scan_tor_rfc5961 Last month's scan showed 4069 vulnerable relays. Each probe does a TCP handshake and then sends 500 in-window packets and counts the resulting Challenge ACKs. (followed by a TCP connection close). However we've updated the buckets of probe results to this: "r == 0" : "zero challenge ACKs", "0 < r <= 10" : "probably new kernel", "10 < r <= 20" : "maybe new kernel?", "20 < r <= 90" : "inconclusive?", "90 < r < 100" : "probably vulnerable", "(r%100)==0 and 0<r<500" : "almost definitely vulnerable", "(r%100)!=0 and 100<r<450" : "probably vulnerable", "(r%100)!=0 and 450<=r<=490" : "inconclusive?", "490 < r < 500" : "most likely applied sysctl workaround", "r == 500" : "probably applied sysctl workaround", "500 < r" : "extra duplicate packets?", The researchers who discovered this vulnerability published an excellent paper [3]. Although they incorrectly described an attack on tor's path selection it may be possible that other attacks on the Tor network are possible. I think it would be better to upgrade and reboot your relays rather than risk the Tor network's exposure to attacks that may utilize CVE-2016-5696 in combination with other techniques. Furthermore being vulnerable to CVE-2016-5696 also implies that you have a Linux kernel which is also vulnerable to dirty COW; https://dirtycow.ninja If you operate a relay you can check to see if your relay's TCP stack has counted many TCP Challenge ACKs. Please let us know if your counters have very high values. Vulnerable Linux kernels will have snmp stat counters like this:: root:/# netstat -s | grep -i challenge TCPChallengeACK: 113338 TCPSYNChallenge: 1157 High counter values maybe indicative of attacks. Linux 4.7.x has got a per socket rate limiting feature which if it has a high value may also be indicative of attack attempts and probing:: root:/# netstat -s | grep -i challenge TCPChallengeACK: 2614 TCPSYNChallenge: 442 TCPACKSkippedChallenge: 141795 If you are too lazy to upgrade your Linux kernel and reboot then you may apply a convenient workaround: sysctl net.ipv4.tcp_challenge_ack_limit=9999999999 read more about this workaround here: https://blogs.akamai.com/2016/08/vulnerability-in-the-linux-kernels-tcp-sta… Special thanks to Least Authority for supporting my research. sincerely, David Stainton 1. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5696 2. https://tools.ietf.org/html/rfc5961 3. Off-Path TCP Exploits: Global Rate Limit Considered Dangerous http://www.cs.ucr.edu/~zhiyunq/pub/sec16_TCP_pure_offpath.pdf

12 29

Inconsistent BW measurements of unused relay
by Rana 11 Dec '16

11 Dec '16

My relay remains severely under-used. One thing that bothers me are inconsistent bandwidth measurements. Here they are: Atlas "advertised" (which is actually supposed to be "measured"?: 100 KB/s = ~ 800,000 bit/s "I have sent" reported in Tor log: on the average pretty stable 17 mbytes every 6 hours = ~ 200 bit/s Atlas graphs: 1 Kbytes/s on the average ~ 8,000 bit/s Consensus BW: 26 = ~ 26,000 bit/s Average upload bw reported by arm: 100 kb/s = ~ 100,000 bit/s Makes zero sense.

3 8

ansible for tor relay ops
by nusenu 11 Dec '16

11 Dec '16

> You are quite often referring to Ansible which is new to me. Is there > a permanent free version around to let your > https://github.com/nusenu/ansible-relayor run on it? Yes ansible is free software and you can install it with your preferred package manager (depending what OS you use). > Isn’t it somehow dangerous in the area we operate, to rely on a piece > of software created more or less by a single person? Thanks for this question. Can you give a few examples for "dangerous" in the context of your question so I might be able to address your concerns more specifically? thanks, nusenu

2 1

Atlas - location of relay changed
by Duncan Guthrie 10 Dec '16

10 Dec '16

Hi folks, My Tor exit, ecntor, recently changed from being listed in the UK to being listed in Canada, without any input on our part. On the IRC channel, I was reassured that this was not a bad thing, that GeoIP is inaccurate, for example. However, I am interested in what might have caused the relay to change location listing like this? Thanks, Duncan

2 1

Connections from UNKNOWN relays
by Rana 10 Dec '16

10 Dec '16

Arm shows that my middle relay has incoming connections from UNKNOWN relays (no consensus data on them at all except locale). Are these bridges? There is also one outgoing connection to UNKNOWN but the address of that is 0.0.0.0:0

3 3

Re: [tor-relays] torworld relays in entry and exit position
by nusenu 10 Dec '16

10 Dec '16

Security TorWorld wrote (2016-11-14): > We believe that next month on the 1st of December would be a good time > to add this feature. What is the current state on this? You are still on the top of this list: https://raw.githubusercontent.com/ornetstats/stats/master/o/potentially_dan…

3 2

0.2.8.11 bridge + hidden service, restart loop
by Petrusko 09 Dec '16

09 Dec '16

Hey, Compiled current 0.2.8.11 (git-c49e563d0096aa5d) on a RPi, set up as a bridge + hidden service (http) Before update, everything was fine. Now, it's starting only fine when only bridge is enabled.... If hidden service is enabled in torrc, some problems : - restart loop - /var/log/tor/notices.log is not used. but can watch log in /var/log/syslog file... Custom hostname + private_key in hidden_service, it was nice before... Thx for your help :) Dec 9 23:48:06 XXX systemd[1]: Starting Anonymizing overlay network for TCP... Dec 9 23:48:08 XXX tor[3935]: Dec 09 23:48:08.336 [notice] Tor v0.2.8.11 (git-c49e563d0096aa5d) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1t and Zlib 1.2.8. Dec 9 23:48:08 XXX tor[3935]: Dec 09 23:48:08.342 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning Dec 9 23:48:08 XXX tor[3935]: Dec 09 23:48:08.343 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc". Dec 9 23:48:08 XXX tor[3935]: Dec 09 23:48:08.343 [notice] Read configuration file "/etc/tor/torrc". Dec 9 23:48:08 XXX tor[3935]: Dec 09 23:48:08.399 [warn] Tor is currently configured as a relay and a hidden service. That's not very secure: you should probably run your hidden service in a separate Tor process, at least -- see https://trac.torproject.org/8742 Dec 9 23:48:08 XXX tor[3935]: Dec 09 23:48:08.405 [notice] Based on detected system memory, MaxMemInQueues is set to 361 MB. You can override this by setting MaxMemInQueues by hand. Dec 9 23:48:08 XXX tor[3935]: Configuration was valid Dec 9 23:48:10 XXX tor[3941]: Dec 09 23:48:10.088 [notice] Tor v0.2.8.11 (git-c49e563d0096aa5d) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1t and Zlib 1.2.8. Dec 9 23:48:10 XXX tor[3941]: Dec 09 23:48:10.093 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning Dec 9 23:48:10 XXX tor[3941]: Dec 09 23:48:10.093 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc". Dec 9 23:48:10 XXX tor[3941]: Dec 09 23:48:10.094 [notice] Read configuration file "/etc/tor/torrc". Dec 9 23:48:10 XXX tor[3941]: Dec 09 23:48:10.151 [warn] Tor is currently configured as a relay and a hidden service. That's not very secure: you should probably run your hidden service in a separate Tor process, at least -- see https://trac.torproject.org/8742 Dec 9 23:48:10 XXX tor[3941]: Dec 09 23:48:10.157 [notice] Based on detected system memory, MaxMemInQueues is set to 361 MB. You can override this by setting MaxMemInQueues by hand. *Dec 9 23:48:10 XXX systemd[1]: tor(a)default.service: main process exited, code=exited, status=1/FAILURE** **Dec 9 23:48:10 XXX tor[3941]: Dec 09 23:48:10.165 [warn] Directory /var/lib/tor/hidden_service/ cannot be read: Permission denied** **Dec 9 23:48:10 XXX tor[3941]: Dec 09 23:48:10.165 [warn] Failed to parse/validate config: Failed to configure rendezvous options. See logs for details.** **Dec 9 23:48:10 XXX tor[3941]: Dec 09 23:48:10.165 [err] Reading config failed--see warnings above.** **Dec 9 23:48:10 XXX systemd[1]: Failed to start Anonymizing overlay network for TCP.** **Dec 9 23:48:10 XXX systemd[1]: Unit tor(a)default.service entered failed state.** **Dec 9 23:48:10 XXX systemd[1]: tor(a)default.service holdoff time over, scheduling restart.* Dec 9 23:48:10 XXX systemd[1]: Stopping Anonymizing overlay network for TCP... Dec 9 23:48:10 XXX systemd[1]: Starting Anonymizing overlay network for TCP... -- Petrusko EBE23AE5

2 1

Exit Node Geographical Location
by Chris Adams 09 Dec '16

09 Dec '16

Hello, I want to start up another exit node. I have a few choices for which country it's in. I currently live in a country with quite a high exit node/population density. Are there any advantages to distributing nodes around the globe in terms of performance/privacy? Are there some countries where you definitely shouldn't run exit nodes? (Censored internet is an obvious example) C

7 10

Belarus (finally) bans Tor
by Rana 09 Dec '16

09 Dec '16

https://ooni.torproject.org/post/belarus-fries-onion/

1 0

Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP
by Rana 09 Dec '16

09 Dec '16

-----Original Message----- From: tor-relays [mailto:tor-relays-bounces@lists.torproject.org] On Behalf Of pa011 Sent: Tuesday, December 06, 2016 1:24 AM To: tor-relays(a)lists.torproject.org Subject: Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP > I would like to hear about ONE Raspi Tor operator who was allowed by DirAuths (or bwauths or whatever) to come even near 1 mbit/s bandwidth utilization > let me tell: https://atlas.torproject.org/#details/AA44C4BE3C90DCAAC09E5CD26150710AAA80D… https://atlas.torproject.org/#details/CA9A5D5C4688F04EEC1AF810B0FD348109FA1… are sharing the same dynamic IP on a Rasp2 -cut every 24 hours day rx | tx | total | avg. rate ------------------------+-------------+-------------+--------------- 05.12.2016 27,20 GiB | 28,39 GiB | 55,59 GiB | 5,40 Mbit/s that is slight above 1 Mbit/s :-) Best regards Paul ---------------------------- Wow nice bandwidth you are pushing through Paul! You mean two Raspi 2's sharing an Internet connection, each relaying 27 Gbytes per day at 5.4 Mbit/s on the average?? Total 10.8 Mbit/s?? Or 2.7 Mbit/s each? Definitely refutes the previously claimed 1 Mbit/s Tor limit on Raspi, and means that Raspi has nothing to do with the ridiculously low utilization of my relay, just as I thought. As a matter of fact this means that whoever is NOT running a relay on a Raspi (or two, or four of them) is wasting money, unless he has a computer lying about with nothing better to do. Also, what's the max memory and CPU utilization on your Raspi (I have read somewhere that Tor is only capable of utilizing 2 of the 4 CPU cores), and what kind of Internet connection do you have? BTW the $35 Raspi 3 has 33% more CPU power than your Raspi 2 and the same amount of memory. Rana

14 36

Re: [tor-relays] All I want for Chrismas is a bloody t-shirt
by Dakota Hourie 09 Dec '16

09 Dec '16

Also been looking for a T-shirt. I would even be willing to buy it! How do I contact Jon? - Dakota Hourie Outfall Exits Operator

3 2

Is there a reason for all exit nodes being public?
by Rana 08 Dec '16

08 Dec '16

I mean, why aren't some exit nodes kept hidden, at least partially and temporarily, like bridges? This would mitigate web services denying service to Tor users (Gmail is the most recent example), plus would increase security.

10 23

Creanova hosting Finland
by Sec INT 08 Dec '16

08 Dec '16

Hi Please dont use this group if you are planning to - although they apparently support Tor they dont. I was running a reduced reduced exit policy with spamhaus listings and only got 2 complaints from security bots but they suspended the vps both times with no warning - now its offline altogether with no warning or email at all. Not to mention they are rude and over reactedto the most minor abuse reports (no dmca etc due to reduced exit policy) Support person emails like he used to be in the NKVD Cheers Mark B

2 3

Re: [tor-relays] Is there a reason for all exit nodes being public?
by myflyrybr 07 Dec '16

07 Dec '16

Trying to hide exit nodes would have little effect on censorship. I believe a more effective approach would be just do the same the vpngate guys did to beat the chinese firewall. Just mix in the published list some essential or high popularity IPs (ex. DNS servers...) as if they were relays. That would send the censors in a goose-chase when a lot of people start complaining about the block. The cost to censor is raised considerably. They would have to check every relay address before adding it to a blacklist, or risk breaking popular services. It's just not worth the trouble.

2 1

how to distribute pgp public key?
by Univibe 07 Dec '16

07 Dec '16

If I want to include a reference to my public PGP key on Atlas using the ContactInfo field on my relays, what's the best way to do it? Should I upload my key to some of the public keyservers and then list the fingerprint on Atlas? If so which keyservers are recommended? I had a thought to publish it on my relay's DirPort (using DirPortFrontPage and a simple html doc containing the public key). Then I could just provide a link to the DirPort in ContactInfo. Is there a better way to do this?

3 3

Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP
by Tristan 07 Dec '16

07 Dec '16

Stop it, both of you. This is not the place for a flame war. If this were a forum, the topic would be locked. Can we just have a normal conversation and get back to what this mailing list is actually used for? On Dec 7, 2016 5:29 AM, "Rana" <ranaventures(a)gmail.com> wrote: There's an alternative interpretation but mentioning in reply to your message would be... rude :-) -----Original Message----- From: tor-relays [mailto:tor-relays-bounces@lists.torproject.org] On Behalf Of Ralph Seichter Sent: Wednesday, December 07, 2016 12:59 PM To: tor-relays(a)lists.torproject.org Subject: Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP On 07.12.2016 10:56, Rana wrote: > Calling "rude" people who, to make a point, use a bit of obvious and > harmless humor, is rude. Your getting on other people's nerves must *obviously* be the fault of other people. Welcome to Trump World. :-) -Ralph _______________________________________________ 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

2 2

Is my exit affected by a botnet?
by Volker Mink 07 Dec '16

07 Dec '16

2 1

Re: [tor-relays] relays with dynamic IP - here Rasp2
by Roman Mamedov 07 Dec '16

07 Dec '16

On Wed, 7 Dec 2016 11:13:54 +0200 "Rana" <ranaventures(a)gmail.com> wrote: > But is it possible to tell Tor on which cores to run? I mean, install a 2nd > instance of Tor and tell it to run on the two cores not used by the first > instance? The Linux kernel will sort it out automatically. Deciding optimally which programs get to run on which cores is the kernel's job. It's also possible to pin programs to specific cores using "schedtool", but that's more of an advanced tuning trick: not something you should need as the first thing you do, but you could look into that if you get to the point when both of them use 100% CPU, and you want to micro-optimize things a bit further. -- With respect, Roman

1 0

Circuits from Tor relay?
by Rana 07 Dec '16

07 Dec '16

Arm reports that my relay has 15 circuits connected to my (middle only) relay. Some of the circuits have one middle relay and some of them have two. All the circuits are FROM my relay to exit nodes, and all have the same guard (first) relay. My relay has a small number of inbound connections and a minuscule number of outbound connections (it is a very new relay as I wiped out and restarted my old one a day and a half ago). Most of the inbound connections are from DurAuths. What are all these circuits??? Why would a middle relay build full circuits to exit nodes?

2 2

Call for Tor Fallback Directories
by teor 06 Dec '16

06 Dec '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Dear Tor Relay Operator, Your relay(s) can help tor clients find the tor network by becoming a fallback directory mirror.[0] These mirrors are hard-coded into tor's source code, like the directory authorities. We have 80 fallbacks, but we want 200 for the next release. Fallbacks need to have: - - the same IP address(es) and ports for the next 2 years, - - the same relay identity key for the next 2 years, - - good uptime (at least 95%), and - - good bandwidth and network connectivity (we estimate an extra 25GB per month). Please email me to add your relays that fit these criteria to the list. If you are BCC'd on this email, it looks like you have at least one relay that could become a fallback. You can also email me if you know your relay will be changing address or key, and I'll make sure we don't choose it. We are keeping the fallback lists from the last release[1][2]. So if you have emailed me before about becoming a fallback, there is no need to email again. But please let me know if your relay details have changed. (I did not BCC relay operators who are already on the fallback lists, unless their relay details changed.) In a week or two, I will run a script to select the hard-coded list for the release. If you're interested, here's some background to this request: The latest list[3] and log[4] of candidates was generated using the instructions in [5] from scripts/maint/updateFallbackDirs.py on my GitHub branch[6]. (This branch has some bug fixes compared to what's in master.) We're tracking this work in [7]. [0]: https://trac.torproject.org/projects/tor/wiki/doc/FallbackDirectoryMirrors [1]: https://github.com/teor2345/tor/blob/fallbacks-029-v2/scripts/maint/fallbac… [2]: https://github.com/teor2345/tor/blob/fallbacks-029-v2/scripts/maint/fallbac… [3]: https://trac.torproject.org/projects/tor/attachment/ticket/18828/potential_… [4]: https://trac.torproject.org/projects/tor/attachment/ticket/18828/potential_… [5]: https://trac.torproject.org/projects/tor/wiki/doc/UpdatingFallbackDirectory… [6]: https://github.com/teor2345/tor/blob/fallbacks-029-v2/scripts/maint/updateF… [7]: https://trac.torproject.org/projects/tor/ticket/18828 T - -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org - ------------------------------------------------------------------------ -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYQ+laAAoJEEUMun+WjwlLXd8QAMVKWrGW+N5ij5/1k1AEDQpC qMK3C3stukeuHYqLEU3GnhJFU/CWMp+iThRNueC5I96MEpcioJDQaCDK6aGEvTY3 efPnYwOJcgE7v4up+JSFWUlO4HcF5Fu5cSVl710JjRiHuZAyLOQw0rWEMzfp0OQp sZLgijbtCUCcels7IS+bE89y4KKQvLu5lz+H7cPIcsx4TJ4QHd5LbWuvtNIHE2lW zA3LlrYsO4vtrFs/0kBWku1u7l1ZhD0Un/lwY7JWaxGmwm9C6kJDFwBFCGYRlakF VLfsoVSgcdjQPkZV9jeL0X+9Wn9L6zZ5JNhM5lhYYpGVD+Rl/apPfhxHI5aOTsGe WRcDjxvgUdMD//xnk2XTmnzKCNUNMyUKGSL8Y7Fadp7+dLLkWlovEp6iOnyAffh1 ZnrV7dhRgH3NcgACDpQ2rAqVzUnhdn1//bcD1MlXjObxvZD1Io1zp7CDQHnG6IaG ydc+3qoqUoII0JQFxrRCFi2cH/E8+3x0+7fC0g91irdGG+Pcosf7IFPJvFsdilCg rN4n6Ohmm1L3KQVWLG7TcvEAcjIeyMurhCvK042Q/X7HYenVS3wVxawd8dnb/rOl 0ItMUsXBKgLVcZXhzUTOB+pNaX8aFj1sJnCB2LRDT8s8a2+zESufNxjgGYZ3Nduk FziDqhHJs7MXyX0HPJPH =omox -----END PGP SIGNATURE-----

5 11

network diversity with freeBSD
by pa011 06 Dec '16

06 Dec '16

There were some talks about network diversity recently, so I made up my mind and started a freeBSD server. On advice from here https://gist.github.com/teor2345/c6e2890c44097fd6aaceeedec08c6431 I placed a line in the torrc file "Log notice file /var/log/tor/log" Following these instructions from the TDP: "touch /var/log tor && chown _tor:_tor /var/log/tor && chmod 600 /var/log/tor" found here: https://torbsd.github.io/fbsd-relays.html I ended up getting this warning: "[warn] Couldn't open file for 'Log notice file /var/log/tor/log': Permission denied" Maybe I am to tired today to find the mistake - what is wrong please? Is there a good instruction elsewhere? Is it possible to install arm on freeBSD and if so could somebody help me with the implementation please? Thanks Paul

8 32

Updating wiki - good bad isps
by Sec INT 06 Dec '16

06 Dec '16

Hi Does anyone know a contact for updating the wiki page for good bad isps - im using five of them and one is not doing what is advertised - i.e. Shutting off an exit node each time a spam abuse emailer asks them to despite there being little evidence to back up their claims regards Mark B

3 4

Unwarranted discrimination of relays with dynamic IP
by Rana 05 Dec '16

05 Dec '16

I have been running a relay with dynamic IP for a month now and quite obviously my relay is severely punished for having a dynamic IP. The IP may change once in several days (currently running over a week with the same IP and I just got my Stable flag back again, about 3 weeks after losing it). The relay's throughput is a tiny fraction (less than 10%) of the actual capacity which I programmed the torrc file to donate. The capacity I wanted to donate is less than the uplink speed of my internet connection (the downlink speed is higher than downlink and is thus irrelevant here). I started with a consensus rating of 21, which went up to 30 and then after a couple of IP changes collapsed to 13. It is now 14, and never went above this again, with the relay running ALL THE TIME stably for a month minus a small number of restarts due to IP changes. As I said, stable IP for a week now and a Stable flag. 1. Why is the relay with dynamic IP punished? This makes zero sense to me. IMHO changing an IP once a week and running stably between such changes is stable enough for all practical purposes. And since the fingerprint of the relay does not change when the IP is changed, dirauths know that this is the same stable node. 2. The "advertised bandwidth" that I see in Atlas has absolutely nothing to do either with the bandwidth that I advertise (it is 3-4 times larger than what I see in Atlas) or with the actual data throughput of my relay (it is 20 times smaller than what I see in Atlas). Can somebody explain this?

11 34

Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP
by Pascal Terjan 05 Dec '16

05 Dec '16

On 4 Dec 2016 9:58 pm, "Rana" <ranaventures(a)gmail.com> wrote: That was exactly my point, thank you Anemoi. This is the case all over the world, not just in Germany. Unfortunately there seems to be a culture of shooting the messenger here, or accusing him of being “aggressive”, “accusatory”, “claiming entitlement” or (my favorite) “lacking programming skills”, in addition to politely phrased suggestions to ditch my relay and pay for a VPS with a fixed IP. The idea of running a volunteer based network for public good is to use every possible resource offered by volunteers, and if DirAuth algorithms need to be adapted for this, such proposal should be taken seriously. I for one am positive that a huge amount of bandwidth that could have been be donated, is lost this way. My understanding is that the DirAuth servers just measure how it would be for users near them. It seems users from several locations using your relay would not get more than 14KB/s so it would be very bad to send more people to your relay as it would make tor unusable for them. The most likely reason would be that your ISP is lacking good connectivity to a large part of internet (this happens to a number of not so small ISPs) but there could be plenty of other reasons. Still if they see your relay slow, it will be slow for many users too, so it is a good thing to not send those users, whoever the fault it is. If this does not make technical sense (which I doubt but I may be wrong), rephrasing the guidelines and officially saying on the Tor page that operators behind dynamic IP are only welcome if they run bridges would be fine – but this isn’t not the case as of now. I hope Tor developers or whoever runs the Tor project are reading this. *From:* tor-relays [mailto:tor-relays-bounces@lists.torproject.org] *On Behalf Of *anemoi(a)tutanota.de *Sent:* Sunday, December 04, 2016 9:24 PM *To:* tor-relays(a)lists.torproject.org *Subject:* Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP In Germany, it's quite usual that you have a dynamic IP and unusual that you have static IP. Not just a few relays are located in Germany. It's not just a question of frustration of owners of dynamic IP relay, but also a matter of bandwith waste. If Tor cannot handle dynamic IPs properly a lot of bandwith is not used. And bandwith is something that the Tor network can not get enough of. _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

1 0

Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP
by anemoi＠tutanota.de 05 Dec '16

05 Dec '16

In Germany, it's quite usual that you have a dynamic IP and unusual that you have static IP. Not just a few relays are located in Germany. It's not just a question of frustration of owners of dynamic IP relay, but also a matter of bandwith waste. If Tor cannot handle dynamic IPs properly a lot of bandwith is not used. And bandwith is something that the Tor network can not get enough of.

12 21

how many tor relay could run on a single machine/IP?
by Fabio Pietrosanti (naif) - lists 04 Dec '16

04 Dec '16

I'm trying to stress some very small dedicated server with ViaNano and Atoms and would like to try out multiple Tor relay with AES hw acceleration to see the limits -naif

5 5

network diversity with freeBSD - pf
by Felix 04 Dec '16

04 Dec '16

> Relays do not publish descriptors until their ORPort and DirPort are reachable. > What do I have to do - how to best set-up a decent strong firewall on a freeBSD Exit? If you run packet filter pf do you want to post the outputs to 'tor-relays' or better to 'lists.nycbug.org/pipermail/tor-bsd/': # freebsd-version -ku ## kernel and userland version # cat /etc/pf.conf and/or # pfctl -vvnf /etc/pf.conf ## n = no execution # top -ab | grep tor # sockstat -l | grep tor # cat /etc/rc.conf | grep defaultrouter # cat /etc/resolv.conf Is your ports tree up to date ? I saw you went for 0.2.9.4-alpha (depracted) on Dec 1st when a newer version was available. 'portsnap fetch update' does it. [] https:// forums.freebsd.org [] https:// www.bsdforen.de [] https:// lists.freebsd.org/pipermail

2 1

Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP
by Greg Moss 04 Dec '16

04 Dec '16

Nothing logical about it. Thats all you get with shitty connection On Dec 4, 2016 1:43 PM, "Rana" <ranaventures(a)gmail.com> wrote: OK thanks, this is beginning to sound logical. What you are saying - correct me if I am wrong - is that since 3 DirAuths gave me fast/hsdir flags while the other 5 didn't and gave me poor weight, you believe that my connectivity with the 5 auths is poor and this is the source of my trouble. If you are right then there is no problem with my relay, no problem with my ISP, and there is a problem somewhere between the countries, and this problem hits specifically my relay. This last piece does not make sense to me but who knows... -----Original Message----- From: tor-relays [mailto:tor-relays-bounces@lists.torproject.org] On Behalf Of teor Sent: Sunday, December 04, 2016 11:34 PM To: tor-relays(a)lists.torproject.org Subject: Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP > On 5 Dec. 2016, at 08:11, Rana <ranaventures(a)gmail.com> wrote: > > 5kbit/s traffic and consensus weight of 14 after running for a month, including last 9 days with the same IP and a Stable flag - you consider this normal? No, sorry, I explained poorly: Your maximum bandwidth is as expected for a middle relay with a similar config. The relay flags are as expected. Your measured bandwidth is not, and indicates an issue with your relay's connectivity to the bandwidth authorities (5 tor clients/relays spread around Europe and North America). Until you fix this issue, your relay will continue to be measured low, because it can not sustain the traffic the tor network needs. It has nothing to do with your IP address changing. Also, it's probably worth mentioning that the Tor network prioritises *client* bandwidth, latency, and security. There are engineering trade-offs between these factors. Using all available relay bandwidth is not a priority: we will happily use less bandwidth to provide better latency or better security. Tim > -----Original Message----- > From: tor-relays [mailto:tor-relays-bounces@lists.torproject.org] On > Behalf Of teor > Sent: Sunday, December 04, 2016 10:52 PM > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] Unwarranted discrimination of relays with > dynamic IP > > >> On 5 Dec. 2016, at 02:39, Rana <ranaventures(a)gmail.com> wrote: >> >>> For as little as $10.00 US there are VPS' with static ip's.. >> >> Attn: Kurt Besig >> >> Well I kind o' like my Raspberry Pi that cost me $40 including box and power supply and SD card and door to door delivery, with far more horsepower and memory than needed for running Tor relay, and my free and absolutely stable 1.5mbps that I want to donate to Tor courtesy of my ISP, and my transparent Tor proxy and my hidden service and my wireless access point that lurk on the same Pi. >> >> This is not a good reason to punish my relay. Makes ZERO sense to me and to who knows how many people like me whose relays are flushed down the drain by the current DirAuth algorithms. >> >> I can think of many an Iranian or Turkish or Chinese or Russian dissident who could use 1.5 mbps bandwidth to communicate with the free world. > > Rana, > > Your relay is actually getting about as much traffic as a middle relay of that size should expect. > > When you change the IP address, it takes a while to re-establish that traffic, as it should, due to the reasons I mentioned in my original email. > > T > > -- > Tim Wilson-Brown (teor) > > teor2345 at gmail dot com > PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B > ricochet:ekmygaiu4rzgsk6n > xmpp: teor at torproject dot org > ---------------------------------------------------------------------- > -- > > > > _______________________________________________ > 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 T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------ _______________________________________________ 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

1 0

Dir port not showing
by Sec INT 04 Dec '16

04 Dec '16

Hi On all my relays and Exits I set Dirport as 80 but when I look at Atlas or https://torstatus.blutmagie.de all of them bar one are showing 'none' as Dirport - also the one that does show Dirport 80 also has the V2Dir flag - does this have something to fo with it? If I look at the connections on arm I can see port 80 being used by a number of relays and exits but why is this showing none and have I got a setting wrong somewhere? Cheers Snap

2 2

tornodes.io relays MyFamily misconfiguration
by nusenu 04 Dec '16

04 Dec '16

Hi tornodes.io team, first of all thanks for joining the tor network and running exit relays, this is really appreciated! To help protect tor clients please set the MyFamily parameter in your torrc configuration, if you need help with that let us know. Since managing MyFamily can be a painful task, especially when operating many relays, there are tools and ansible roles to automate that [2]. As you grow please consider also the following: - network diversity (ISP and geographically) You are currently operating in the second most used exit AS, consider using other ISPs as well. We know it is not easy to find cheap reliable exit hosters, compass can help you determining whether a given AS is already used by many other (exit) operators: https://compass.torproject.org - running current tor releases 0.2.4.x and 0.2.5.x are old, consider updating to the latest stable tor release (currently 0.2.8.10). Using the torproject repo (if you are on Debian/Ubuntu [3]) can help you stay on the latest releases. thanks, nusenu [1] https://tornodes.io [2] https://github.com/nusenu/ansible-relayor https://github.com/coldhakca/sync_family [3] https://www.torproject.org/docs/debian.html.en +---------------------+-------------+-------------+----------+ | first_seen | tor_version | nickname | MyFamily | +---------------------+-------------+-------------+----------+ | 2016-11-25 01:00:00 | 0.2.4.27 | TorNodes003 | NULL | | 2016-11-25 15:00:00 | 0.2.4.27 | TorNodes002 | NULL | | 2016-11-26 01:00:00 | 0.2.4.27 | TorNodes001 | NULL | | 2016-11-27 23:00:00 | 0.2.8.9 | TorNodes004 | NULL | | 2016-11-28 20:00:00 | 0.2.4.27 | TorNodes005 | NULL | | 2016-11-28 23:00:00 | 0.2.4.27 | TorNodes006 | NULL | | 2016-11-29 03:00:00 | 0.2.4.27 | TorNodes007 | NULL | | 2016-11-29 15:00:00 | 0.2.4.27 | TorNodes008 | NULL | | 2016-11-29 18:00:00 | 0.2.5.12 | TorNodes010 | NULL | | 2016-11-30 17:00:00 | 0.2.5.12 | TorNodes011 | NULL | | 2016-12-01 16:00:00 | 0.2.5.12 | TorNodes012 | NULL | | 2016-12-02 03:00:00 | 0.2.5.12 | TorNodes009 | NULL | | 2016-12-03 00:00:00 | 0.2.5.12 | TorNodes013 | NULL | | 2016-12-03 02:00:00 | 0.2.5.12 | TorNodes014 | NULL | | 2016-12-03 16:00:00 | 0.2.5.12 | TorNodes015 | NULL | +---------------------+-------------+-------------+----------+

1 0

LLC vis-à-vis Nonprofit
by Kenneth Freeman 03 Dec '16

03 Dec '16

An Idaho nonprofit has expressed guarded interest in Tor. Ideally I'd like them to run an exit node without fuss or bother, but the Tor Project's Tips on Running an Exit Node only covers limited liability corporations (LLCs) regarding the legal/corporate set-up. Is there anything to add, or is that sufficient? Thanks in advance.

3 5

Re: [tor-relays] Outgoing Connections to middle nodes?
by balbea16 03 Dec '16

03 Dec '16

Hi MichaelThanks for the hint. I guess you are totally right! I forgot about the hidden services. Right now I have about 1100 in and out connections, makes totally sense. Mike -------- Ursprüngliche Nachricht -------- Von: Rana <ranaventures(a)gmail.com> Datum: 03.12.16 14:45 (GMT+01:00) An: tor-relays(a)lists.torproject.org Betreff: Re: [tor-relays] Outgoing Connections to middle nodes? -----Original Message----- From: tor-relays [mailto:tor-relays-bounces@lists.torproject.org] On Behalf Of Michael Armbruster Sent: Saturday, December 03, 2016 2:10 PM To: tor-relays(a)lists.torproject.org Subject: Re: [tor-relays] Outgoing Connections to middle nodes? On 2016-12-03 at 12:56, balbea16 wrote: > Hi There, > I've got a quick question. I have been running a tor relay since 3 > months. I don't have a guard flag, however many outgoing connections > to non exit relays (i.e. that should be middles than). Does that mean > I run an entry node (without having guard status)? How come? > TNX Mike Hi Mike, you forget about hidden services IN the Tor network. Not every connection tries to connect to domains or services outside the Tor network. So it could be that you are a middle relay having many outgoing connections to so-called rendezvous points. Have a look at this sentence here from [1]: "In general, the complete connection between client and hidden service consists of 6 relays: 3 of them were picked by the client with the third being the rendezvous point and the other 3 were picked by the hidden service." Best, Michael [1] https://www.torproject.org/docs/hidden-services.html.en _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

1 0