- tor-relays - lists.torproject.org

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 07 Dec '16

07 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