- tor-relays - lists.torproject.org

Getting drops with iptables "-m state --state INVALID" in INPUT and OUTPUT chains on relay
by fr33d0m4all 07 Apr '16

07 Apr '16

Hi… I've noticed that the iptables rule "-m state --state INVALID -j DROP" applied both to INPUT and OUTPUT chains on my raspbian Tor relay drops some connections… is it normal and should I avoid dropping "—state INVALID" connections when the destination or source is the Tor process on the relay? It's strange to have them also in the outgoing chain (i.e. produced by the relay), unless its is related to how Tor works (I'm almost sure that the connections dropped by the OUTPUT rule are related to the Tor process). It's not a matter of conntrack entries, it's using only 61 entries and has a lot of them free. Drop log in the OUTPUT direction => why is my relay sending a packet with ACK PSH FIN flags? iptables-OUT-INVALID-DENIED: IN= OUT=eth0 SRC=10.x.x.x DST=37.x.x.x LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=24372 DF PROTO=TCP SPT=33423 DPT=9001 WINDOW=321 RES=0x00 ACK PSH FIN URGP=0 Drop log in the INPUT direction => This could be a correct drop due to a new connection with RST flag, I think: iptables-IN-INVALID-DENIED: IN=eth0 OUT= SRC=91.x.x.x DST=10.x.x.x LEN=40 TOS=0x00 PREC=0x00 TTL=54 ID=0 DF PROTO=TCP SPT=15754 DPT=9090 WINDOW=0 RES=0x00 RST URGP=0 Best regards, Fr33d0m4All -- _____________________________________________________________ PGP Key: 0DA8 7293 D561 3AEE A3C0 7F63 101F 316A F30E ECB4 IRC Nick: fr33d0m4all (OFTC & Freenode) _____________________________________________________________

1 0

Re: [tor-relays] Relays by AS Names
by Tor-Node.net 06 Apr '16

06 Apr '16

ng0 wrote: > Could you upload the .txt of this list to > a network/filepublishing service which > does not require your email > address? I apologize, I was not aware that you had to provide your email to download. Here you can fetch them without providing your email: http://wikisend.com/download/498630/ExoticVPS.ods http://wikisend.com/download/894542/ExoticVPS.xlsx http://wikisend.com/download/789008/ExoticVPS.txt

1 0

Relays by AS Names
by SuperSluether 06 Apr '16

06 Apr '16

I want to host an exit relay, but at the same time I don't want to use a service that already hosts multiple Tor relays. Is there a website that lists relays by AS Names so I can find a service that isn't already populated with Tor?

10 10

Blocking Tor - A case for more accuracy
by Eran Sandler 06 Apr '16

06 Apr '16

https://blog.perimeterx.com/blocking-tor-a-case-for-more-accuracy/ There are certainly other ways of handling Tor traffic and measuring the real intention of a user. Disclaimer: The guys at PerimeterX are friends of mine. I sent them the CloudFlare post (as well as the post from the Tor blog) because I know their methods are much better in detecting intention and not just blocking Tor IPs. Eran

1 0

Relay request
by runner7272 04 Apr '16

04 Apr '16

Sent from my Sprint Phone.

2 1

Re: [tor-relays] tor-relays Digest, Vol 63, Issue 5
by d3part3d＠tuta.io 04 Apr '16

04 Apr '16

? -- Securely sent with Tutanota. Claim your encrypted mailbox today! https://tutanota.com 4. Apr 2016 15:31 by tor-relays-request(a)lists.torproject.org: > 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. Tor Weather has been discontinued (Karsten Loesing) > 2. Re: Tor Weather has been discontinued (Eran Sandler) > 3. Re: Tor Weather has been discontinued (Eran Sandler) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 4 Apr 2016 16:48:39 +0200 > From: Karsten Loesing <> karsten(a)torproject.org> > > To: > tor-relays(a)lists.torproject.org > Subject: [tor-relays] Tor Weather has been discontinued > Message-ID: <> 57027EC7.9010802(a)torproject.org> > > Content-Type: text/plain; charset=utf-8 > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Dear relay operators, > > as of April 4, 2016, Tor Weather has been discontinued. > > Tor Weather [0] provided an email notification service to any user who > wanted to monitor the status of a Tor node. Upon subscribing, they > could specify what types of alerts they would like to receive. The > main purpose of Tor Weather was to notify node operators via email if > their node was down for longer than a specified period, but other > notification types were available, including one where operators would > be informed when their node was around long enough to qualify for a > t-shirt. > > The main reason for discontinuing Tor Weather is the fact that > software requires maintenance, and Tor Weather is no exception. Tor > Weather was promising t-shirts for relays that have not been around > long enough or that provided too little bandwidth to be useful to the > network, and it was almost impossible to deny a t-shirt after Tor > Weather has promised it. Apart from that, Tor Weather was likely not > offering t-shirts to people who have long earned it, thereby confusing > them. An unreliable notification system is worse than not having a > system at all. Relay operators shouldn't rely on Tor Weather to > notify them when their relay fails. They should rather set up their > own system instead. > > We have tried to find a new maintainer for Tor Weather for years, but > without success. We started rewriting Tor Weather [1] using Onionoo > [2] as data back-end in 2014, and even though that project didn't > produce working code, somebody could pick up this efforts and finish > the rewrite. The Roster developers said that they're planning to > include an email notification function in Roster [3]. And we > developed a simple Python script that provides information about a > relay operator's eligibility for acquiring a t-shirt [4]. None of > these alternatives is a full replacement of Weather, though. > > We encourage you, the community of Tor relay operators, to step up to > start your own notification systems and to share designs and code. > Tor Weather is still a good idea, it just needs somebody to implement it. > > Tor Weather is discontinued in two steps. For now, new subscriptions > are disabled, new welcome messages are not sent out anymore, and > existing subscriptions continue working until June 30, 2016. From > July 1, 2016 on, Tor Weather will not be sending out any emails. > > Sorry for any inconvenience caused by this. > > All the best, > Karsten > > > [0] > https://weather.torproject.org > > [1] > https://trac.torproject.org/projects/tor/wiki/doc/weather-in-2014 > > [2] > https://onionoo.torproject.org > > [3] > http://www.tor-roster.org > > [4] > https://gitweb.torproject.org/metrics-tasks.git/tree/task-9889/tshirt.py > > -----BEGIN PGP SIGNATURE----- > Comment: GPGTools - > http://gpgtools.org > > iQEcBAEBAgAGBQJXAn7HAAoJEC3ESO/4X7XBmhEIAKxWEwex5pyp5RBHkE4+1IC2 > WaKjcvIT0WiZJ8prZASNSxF7ART6r2trG50+Pd2GCdu0SOjIz3eeQNSkx251RaqF > xF7dw2RVhExcYOar4FG5+KkXu6X3k0svMvNeMGzcRd51yaaVeW8OaAgV0NC+CHgE > ZkA7bg26jCvG8EFrKCg4fuZ3JW3+O3mvcquea+aB4q6gbuQFjgoxzfH5+XkmpA5i > gDZnsIRuBDYuUW8V1ior/7DG2wGlCjWZUotoTysfsFW2FSMUrTBZOlvhpHicMfER > VpLxY8+b3ZGC6Olit50ISZql8l12yO3Hik32eKIcgK2fpx6vgKE+T83I8voIpOU= > =LVj8 > -----END PGP SIGNATURE----- > > > ------------------------------ > > Message: 2 > Date: Mon, 04 Apr 2016 14:58:20 +0000 > From: Eran Sandler <> eran(a)sandler.co.il> > > To: > tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] Tor Weather has been discontinued > Message-ID: > <> CALR3k-G0DoeRB-baVw+uvGUeMdDRVMORwEgAjDgCg6kE3n1cGQ(a)mail.gmail.com> > > Content-Type: text/plain; charset="utf-8" > > I have played quite a bit with onionoo and wrote a wrapper in Go for it. > > I am willing to rewrite Tor Weather using Go (or python if you like). > > I'll go over the old code and this email again to make sure I understand > the full scope of the project. > > As an operator I have relied on the Tor Weather alerts to know if one if my > nodes were down and while it's wasn't quick enough in sending alerts it was > a good tool. > > I have some ideas about the t-shirts alerts so that we won't miss sending > to those that need it and wouldnt send to those that don't need it. > > Eran > > On Mon, Apr 4, 2016, 17:49 Karsten Loesing <> karsten(a)torproject.org> > > wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Dear relay operators, >> >> as of April 4, 2016, Tor Weather has been discontinued. >> >> Tor Weather [0] provided an email notification service to any user who >> wanted to monitor the status of a Tor node. Upon subscribing, they >> could specify what types of alerts they would like to receive. The >> main purpose of Tor Weather was to notify node operators via email if >> their node was down for longer than a specified period, but other >> notification types were available, including one where operators would >> be informed when their node was around long enough to qualify for a >> t-shirt. >> >> The main reason for discontinuing Tor Weather is the fact that >> software requires maintenance, and Tor Weather is no exception. Tor >> Weather was promising t-shirts for relays that have not been around >> long enough or that provided too little bandwidth to be useful to the >> network, and it was almost impossible to deny a t-shirt after Tor >> Weather has promised it. Apart from that, Tor Weather was likely not >> offering t-shirts to people who have long earned it, thereby confusing >> them. An unreliable notification system is worse than not having a >> system at all. Relay operators shouldn't rely on Tor Weather to >> notify them when their relay fails. They should rather set up their >> own system instead. >> >> We have tried to find a new maintainer for Tor Weather for years, but >> without success. We started rewriting Tor Weather [1] using Onionoo >> [2] as data back-end in 2014, and even though that project didn't >> produce working code, somebody could pick up this efforts and finish >> the rewrite. The Roster developers said that they're planning to >> include an email notification function in Roster [3]. And we >> developed a simple Python script that provides information about a >> relay operator's eligibility for acquiring a t-shirt [4]. None of >> these alternatives is a full replacement of Weather, though. >> >> We encourage you, the community of Tor relay operators, to step up to >> start your own notification systems and to share designs and code. >> Tor Weather is still a good idea, it just needs somebody to implement it. >> >> Tor Weather is discontinued in two steps. For now, new subscriptions >> are disabled, new welcome messages are not sent out anymore, and >> existing subscriptions continue working until June 30, 2016. From >> July 1, 2016 on, Tor Weather will not be sending out any emails. >> >> Sorry for any inconvenience caused by this. >> >> All the best, >> Karsten >> >> >> [0] >> https://weather.torproject.org >> >> [1] >> https://trac.torproject.org/projects/tor/wiki/doc/weather-in-2014 >> >> [2] >> https://onionoo.torproject.org >> >> [3] >> http://www.tor-roster.org >> >> [4] >> https://gitweb.torproject.org/metrics-tasks.git/tree/task-9889/tshirt.py >> >> -----BEGIN PGP SIGNATURE----- >> Comment: GPGTools - >> http://gpgtools.org >> >> iQEcBAEBAgAGBQJXAn7HAAoJEC3ESO/4X7XBmhEIAKxWEwex5pyp5RBHkE4+1IC2 >> WaKjcvIT0WiZJ8prZASNSxF7ART6r2trG50+Pd2GCdu0SOjIz3eeQNSkx251RaqF >> xF7dw2RVhExcYOar4FG5+KkXu6X3k0svMvNeMGzcRd51yaaVeW8OaAgV0NC+CHgE >> ZkA7bg26jCvG8EFrKCg4fuZ3JW3+O3mvcquea+aB4q6gbuQFjgoxzfH5+XkmpA5i >> gDZnsIRuBDYuUW8V1ior/7DG2wGlCjWZUotoTysfsFW2FSMUrTBZOlvhpHicMfER >> VpLxY8+b3ZGC6Olit50ISZql8l12yO3Hik32eKIcgK2fpx6vgKE+T83I8voIpOU= >> =LVj8 >> -----END PGP SIGNATURE----- >> _______________________________________________ >> tor-relays mailing list >> tor-relays(a)lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> >

1 0

I would like to help.
by Generalgrievous 03 Apr '16

03 Apr '16

I have a Banana Pi that I would like to use to help the TOR network. I have installed Debian-Jessie and started researching the process for setting up relay, even an exit. I am a total noob, but willing to learn. If someone is willing to help me step by step, I would be excited to help. I've tested my internet speed, Download average 60 mbps, Upload avreage 6 mbps, If I would be more of a hindrance than a benefit, please say so, no hard feelings. Located Central CA. General G. Sent from [ProtonMail](https://protonmail.com), encrypted email based in Switzerland.

6 6

Earned T-shirt and no email response for months
by Dimitar Milkov 01 Apr '16

01 Apr '16

Hello, My relay earned me a Tor T-shirt a couple of months ago. I emailed the team responsible for them on the email given in the T-shirt descriprion page (https://www.torproject.org/getinvolved/tshirt.html) with size, shipping address and everything, and the notification email from Tor Weather also included. However, there is still no response. I asked in IRC after the first month or so and some people said that they are overloaded with work because of some campaign/conference sort of thing. How long it usually takes for a T-shirt request to be processed? What is your experience?

4 4

Re: [tor-relays] Relays with broken DirPorts
by starlight.2016q1＠binnacle.cx 01 Apr '16

01 Apr '16

These relays all appear at least somewhat overrated by BWauths and are not rate-limiting with BandwidthRate. DirPort performance is bad due to a saturated physical link or 'tc' bandwidth limit, so TCP congestion back-off kicks in. If BandwidthRate were the limiting factor DirPort would return a 503 (busy) error. Reason for the overrating is a serious bug in Torflow resulting in relays going unmeasured for extended periods, possibly more than 30 days at which time a BWauth will cease listing an affected relay. I'm planning to work on fixing this, but have not had the time and presently don't see getting to it before early summer. >Dear Relay Operators, > >Also while working on #17158, I found some relays whose DirPort >responses made my python script hang. It wouldn't even respond >to ^C, but that might just be an OS X thing, or a stem thing. > >I'm not sure what to do about these relays. I'd like to do a >tcpdump / Wireshark check, but I don't have time at the moment. >Would anyone like to follow this up? > >This is an incomplete list of broken relay IPs and DirPorts, >starting with those with the highest consensus weight: >217.23.14.190:1194 >151.80.164.147:80 >148.251.255.92:80 >78.142.19.59:80 > >Thanks > >Tim > >Tim Wilson-Brown (teor)

3 2

Relays with very slow DirPorts
by Tim Wilson-Brown - teor 30 Mar '16

30 Mar '16

Dear Relay Operators, While I was checking fallback directory mirrors for #17158, I encountered some relays that took more than a minute to serve a consensus. Most took 150 seconds, which could be caused by a RelayBandwidthRate of 10 kilobytes a second. One solution to this issue is to disable the DirPort on relays with a RelayBandwidthRate less than 50 kilobytes a second, or more than 30s to serve a consensus. https://trac.torproject.org/projects/tor/ticket/18688 (This ticket also contains the python / stem code that I'm using to check the consensus download speed.) But I don't actually know if it's the relays' torrc configuration that's causing the issue, or if their provider is limiting their speeds, or if there's some other issue. If you're the operator of one of the relays listed below, can you let me know? And if someone wants to investigate further, or contact these operators on their ContactInfo, that would be great. (I don't have time right now, I'm trying to pull together a list of fallback directories before the 0.2.8-rc.) This is an incomplete list of slow relay IPs and DirPorts, starting with those with the highest consensus weight: 217.198.117.122:80 212.47.250.44:80 158.69.112.86:80 50.7.178.34:80 191.101.251.172:80 51.254.249.177:80 188.165.232.40:80 104.236.38.231:8080 89.163.225.184:9030 185.31.230.69:9030 81.7.14.227:9030 62.210.238.33:9030 164.132.56.137:9030 212.107.149.145:9030 94.23.165.33:9031 Thanks Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F

1 1

Re: [tor-relays] Relays with broken DirPorts
by Tim Wilson-Brown - teor 30 Mar '16

30 Mar '16

> On 31 Mar 2016, at 11:23, Michael McConville <mmcco(a)mykolab.com> wrote: > > You'll probably get through to more people if you include nicknames with > IP addresses, and if you send an email to the operators who listed their > address in ContactInfo. I was actually hoping that someone else would do that for me, I'm a little snowed under at the moment. Tim > > Thanks for this, > Mike > > Tim Wilson-Brown - teor wrote: >> Dear Relay Operators, >> >> Also while working on #17158, I found some relays whose DirPort responses made my python script hang. It wouldn't even respond to ^C, but that might just be an OS X thing, or a stem thing. >> >> I'm not sure what to do about these relays. I'd like to do a tcpdump / Wireshark check, but I don't have time at the moment. >> Would anyone like to follow this up? >> >> This is an incomplete list of broken relay IPs and DirPorts, starting with those with the highest consensus weight: >> 217.23.14.190:1194 >> 151.80.164.147:80 >> 148.251.255.92:80 >> 78.142.19.59:80 >> >> Thanks >> >> Tim >> >> Tim Wilson-Brown (teor) >> >> teor2345 at gmail dot com >> PGP 968F094B >> >> teor at blah dot im >> OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F >> > > > >> _______________________________________________ >> tor-relays mailing list >> tor-relays(a)lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F

1 1

Relays with broken DirPorts
by Tim Wilson-Brown - teor 30 Mar '16

30 Mar '16

Dear Relay Operators, Also while working on #17158, I found some relays whose DirPort responses made my python script hang. It wouldn't even respond to ^C, but that might just be an OS X thing, or a stem thing. I'm not sure what to do about these relays. I'd like to do a tcpdump / Wireshark check, but I don't have time at the moment. Would anyone like to follow this up? This is an incomplete list of broken relay IPs and DirPorts, starting with those with the highest consensus weight: 217.23.14.190:1194 151.80.164.147:80 148.251.255.92:80 78.142.19.59:80 Thanks Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F

1 0

Tor Exclude Nodes Misbehaving
by stealth＠nym.mixmin.net 30 Mar '16

30 Mar '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have edited my torrc file on my Tor Client to exclude several countries, but I keep getting the United Kingdom in my pathway. My torrc file is below: DataDirectory C:\Users\Myname\Tor Browser\Browser\TorBrowser\Data\Tor GeoIPFile C:\Users\Myname\Tor Browser\Browser\TorBrowser\Data\Tor\geoip GeoIPv6File C:\Users\Myname\Tor Browser\Browser\TorBrowser\Data\Tor\geoip6 ExitNodes {PL}, {RO}, {LU}, {DK}, {CH}, {NO}, {AN}, {LI}, {IS}, {FI}, {NL}, {HU}, {BG} ExcludeNodes {US}, {CN}, {FR}, {UK}, {ES}, {IT}, {AU}, {HK}, {RU}, {PT}, {IL}, {IE}, {DE}, {CA}, {BE}, {NZ}, {PR}, {MX}, {KP}, {KR}, {GR}, {DJ}, {JP} StrictExitNodes 1 When I click on the green onion after selecting a web site, I keep getting the United Kingdom as one of my nodes. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (MingW32) iQIcBAEBAgAGBQJW9eAMAAoJEH1gNwhiMDZusekP/jXnkAkTIHEvytXkoRsPKvYv NY9DG0eX/n6nE4ufBAczoRgaZMCwF5BPlBio9CyiSlL4qiI0xZ9zqY1vV5+kIrYS cewQH62JvS2rj3DRykVytyHXrdRE+zvnhqqY0fqD/7+WehXkG9dQmu5TT8qfmS35 bw12EpVs6yyAR7Rfhnaha0D1fqK1ekOFkpi+bo6j7X6LMW6zPnWhzROZeqEakFtP slcGJlF+OIk2f2pTkYzhq5MHwollZ+bUqkljFLzvzl1HvK2lHMtLLSgnLcU/88hC 7bhJiOfkh7+jmpi+GMzoCRFGWLq75bufJ34acxap3P4bRnYduJ72RvUQ40+LITcj dNmtFTC/+psrdvjHBJP9XDO8FPhmVIOlEr588tjgOPQwDNHbe5t7TMEYk/8S5EzH +7ahYd9MbT03oNnVrQKbSut66LmuukDyIuvR8gP9UU2+VNmKubxVcsRlOQvDmIDR /zqT6nYrc7uCimE37Ny0K8v2R0NSwE/rVPZeP2i0dzgyHOkSPLitRDvkyLgDI+kr Wwn0cAkdzjs4428PdOnEyu+b2vLtXDcV3Q1aH32wQbMXR/o2uaY4VB6iVTjU6tlb bexKHehLYmaK0c0LKLb91mxjequDe4QEdJBUQg/vVvmwPzcvVBHXJgPmPf9uJ9W/ Szr3idQyUm4QZ6WvCAvD =FURP -----END PGP SIGNATURE-----

5 4

Who operates the bridge with nickname antirio?
by Karsten Loesing 27 Mar '16

27 Mar '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi everyone, does anybody here know who operates the bridge with nickname antirio? https://atlas.torproject.org/#details/16609212922F6F1077A1BBA299709E19F9A3F… I'm asking, because that bridge has a nice distribution of IPv4 and IPv6 clients: bridge-ip-versions v4=48,v6=64 bridge-ip-versions v4=56,v6=72 We have a bug where IPv6 addresses are included in bridge-ip-versions statistics but where consensus downloads via IPv6 addresses are not counted. It would be very valuable to test the patch for this bug on the antirio bridge or on another bridge with at least 1/2 of clients connecting via IPv6. (When looking yesterday I didn't find another bridge with that property.) The patch is commit b79d859 in my task-18460-2 branch: https://gitweb.torproject.org/karsten/tor.git/log/?h=task-18460-2 In theory it should be sufficient to cherry-pick that commit from any other recent tor branch. It just changes three lines of code. More details on the ticket: https://trac.torproject.org/projects/tor/ticket/18460 Thanks! All the best, Karsten -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJW94evAAoJEC3ESO/4X7XBs5UH/jTAcsuOl6sCJO21WuOLcMmI csq/b1IPsBvoh6YT8HBh4h07+mJSwMuWXcm3nReJsmdvjlDP4watlsEbqMgX+oxo 6GSSOX4ySS4C5bscywxXWvZIDFWPC6rToYcyfyFDmP5I+nkPNyVqsc9fBXjGJvpN uJ15bixc0iZaespKG6mQwgX8ZHi9Hf+s089voQyMEe09SscKqXHe3/50ZrLHmLPl d8BJ8Ij6WxD9ndG6FOVAUOoTunsWL8NbVSHSCJf93LOUsM6XmPjIPERyvcvnL54M uvg3kqIFTdngvLwFqzB4cETREnJtXuPIPMt8eAMLsDGtcDAuSZiqKhs1dEpJLQE= =7cQU -----END PGP SIGNATURE-----

2 2

Minimum Relay/Bridge Bandwidth
by SuperSluether 26 Mar '16

26 Mar '16

Our family recently downgraded our internet connection, which limited our upload speed to 1Mbps. According to the Tor relay doc, a minimum of 2Mbps is recommended, yet a relay is considered "fast" if it has 1Mbps. Will I be hurting more than helping if I run a relay on this connection speed? Should I run a bridge instead? SuperSluether

3 2

Weird relay outage
by Xza 26 Mar '16

26 Mar '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Suddenly my relay lost all it's flags plus weird bandwidth drops while the network is fully intact. Tor version 0.2.7.6 - Ubuntu server 14.04 - -- PGP : 29A4CE52 -----BEGIN PGP SIGNATURE----- iQI4BAEBCgAiGxxEbyA8eWFuZGVyZXNvbkByaXNldXAubmV0PgUCVvaCxAAKCRBI of/XNyszStdfD/9KFIGLcxSUS0gmfHjJFPEgxHqBYunI4wSehrSve+ZcA5D66u7J FaYDaA3BB3+q2OuDsz4/3yb2ArGObkzV6sTZi4ti1zT3knU11Zw7zYvtZ7kFnfjD BFz6N7wY1tu+crrBLmM53ycyURlZxMYQieK5bpgUdz4S8WBm9LIGN1A2uV6Ifnjc Hn7cke64b0iij5QVIp0v04CjzhhxywvYqcu5U/1Z/nnxt53bGW5gtaaacz4y0fVf qFVUaBXiJR0usxoX0yvE3t+qfGVyUNAHbbB4nO3tVxQJqqaOiGcqwLoMVDCbmQlm 2ZXnbC0dgA12votJVHthZ0EGNH75+IthGic/+3LvcDoalVruohNVhXNj5WJhe5w8 J8G8KDJ+ZgnOstDwd3yJnogX0BuFB3fovopMzuWf+AJB3MVODzDbTE2md4bk1/QT If1jLLLWxhVCJJg3f7WzM1+L8glo7NUVCS6rL1DXKiFpEHP2Gw9fo8HKYxwiPar/ wvVchOL3FimbphMqKBd9o1o8CeYB9VZFUMt+cm3tfRimpotn3WNgNOWJw2Udlvpu 9l+582Vs1Y6ebZ7KfKETmsbF6iI00tA/kX9MBJu0X6TICDK31vXHR77d5HvZ1Ql6 bv7u/QBeBmGiUCy/w5utq1RZ7MxO9MDtY22dkakim4nYw8fpJL3fgWjn1g== =Bo8A -----END PGP SIGNATURE-----

3 4

Tor Exclude Nodes Misbehaving
by stealth＠nym.mixmin.net 26 Mar '16

26 Mar '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have edited my torrc file on my Tor Client to exclude several countries, but I keep getting the United Kingdom in my pathway. My torrc file is below: DataDirectory C:\Users\Myname\Tor Browser\Browser\TorBrowser\Data\Tor GeoIPFile C:\Users\Myname\Tor Browser\Browser\TorBrowser\Data\Tor\geoip GeoIPv6File C:\Users\Myname\Tor Browser\Browser\TorBrowser\Data\Tor\geoip6 ExitNodes {PL}, {RO}, {LU}, {DK}, {CH}, {NO}, {AN}, {LI}, {IS}, {FI}, {NL}, {HU}, {BG} ExcludeNodes {US}, {CN}, {FR}, {UK}, {ES}, {IT}, {AU}, {HK}, {RU}, {PT}, {IL}, {IE}, {DE}, {CA}, {BE}, {NZ}, {PR}, {MX}, {KP}, {KR}, {GR}, {DJ}, {JP} StrictExitNodes 1 When I click on the green onion after selecting a web site, I keep getting the United Kingdom as one of my nodes. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (MingW32) iQIcBAEBAgAGBQJW9uefAAoJEH1gNwhiMDZuNNMQAIXhg1yq0Fq4pC2PsQ5jrOSh AtI3CnsUYg1+CtzAQtqksfb7PDwhTVAXFu7l2Ap1PrPBc+LcFrzZ4HAbqTPpGaYP DPokmhIlTgAzgAmu0n7RDJPSJmFXRJWdW6wULI4GsAPFHE9gU036Hd+1R9agIxrt oleizTVRAXpFqQgjLtGfiIYGQUh5vlWIiVCWOr6CGE5GkWLOC5oYPU7wKDzIE25o 7L56y6AyiUcA7abRMCDQCnVQ2AAY4dZwJ8ESK+j+ZJMGZIK2CbBeJF2QwlkjSFdn Mtjbctl4qwQqgcBhcVKuK3dMsdVnpj1YqEa8mGeMVTje74R1E2HULsJHq1UPLvkr /h8HTspIf45KvcDL1F1PoHpr9B2zWW/LJxvBL2VJiNIDRjZscuIQdzNJe2GE3P51 ImUozWR1+BHhn0h+y9zq/Pcq0dlmHGdrf7v/QgSLPq9g5RbNsyRKA6j0KhIC9efX 71DVclpgwAVC9itgpEnc1wHMkZZwcs+JWYJjvgcJ2UFR/CY79ZWfQePAn2bCledN AOkBfDclPvKZMXy9cXh9SgPWTesonOp4CubhvFXH6ReBBWfU9RYjCRhqy9w6XPaB OiYObQEYgoodftNZoqo8HVDdHLq0S+mwUPEM2x1UQDga40F8LqR3SB0BKySalG6K Mlc+6qOy65PvE6OGt94Z =kUjp -----END PGP SIGNATURE-----

2 1

OrNetRadar spots botnet joining the tor network? (79 relays, 38 countries, 67 ASes)
by nusenu 25 Mar '16

25 Mar '16

Hi, this smells like a botnet to me: http://article.gmane.org/gmane.network.onion-routing.ornetradar/1073 http://article.gmane.org/gmane.network.onion-routing.ornetradar/1074 all relays with that bitcoin adress: https://gist.githubusercontent.com/nusenu/fb19034a7860dba6c203/raw/5531768e…

4 10

Starting an exit node from spain
by f4aRelay 24 Mar '16

24 Mar '16

Im spanish and i want to start a tor exit relay. I have thoght about using this hosting: Pulse Servers (http://www.pulseservers.com/) Also i would like to know if there is any legal thing i should know for running a relay in spain Thanks -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2 mQENBFb0BYIBCADE1jSLjOOb0sVZBAHpbItjWoqJamG+mlrR4936upHz2m2r7D2L pzOoYF/Gn4Iytk3IGVZT3Hfci18+nymidYl0L9guGLYGU1Z/T+v7wFKMOJCbty6p TNm9lOYDc1d8AVEGMMj2rmcHwP2ON98CRxKgGJscVgA7xno2PVeQSGqBgLv2UB/0 rqZsJnbsSHPH9+qxfxNuNh8DoByClf2S/Fx/WYbqyaoJBofv7FAVjWSVJTB/KSBO 2rDt9IRD3cLnFjGsGS7MBPvimPPgJQRkPrXPTWP3v5RNvUhd03PkLcPEcKF1fans MR1ywzxGxMQninSLw4oxpTm5H5xfqDfmRH/tABEBAAG0IkY0QXJlbGF5IDxmNGFy ZWxheUBwcm90b25tYWlsLmNvbT6JATkEEwEIACMFAlb0BYICGwMHCwkIBwMCAQYV CAIJCgsEFgIDAQIeAQIXgAAKCRCG6H1KC64jxZOhCADEHjEI+XkhmsNd67NjywIw aiaIfClVOrr5qnwhmZ77Wz7cmOcUsVJCNiKeYcG7WSOhNLeVEg7F6qeLyne5VHnJ Ncbb7+6YeD2bz04PcwDAyrkWRYdKhjIuNxbx1qoMzTkuenXa6qd+hj4yObYJlful 3zw5x49Vky6lxU3rHL+pKq2F2Hb6fyOkJd9uXP/I1muk98GMWK3WcLXGGY0TRo+7 CrlCvZBCtJ6laOo9hmt25KiuYq8xctT5Y7G3W+xc8yva0rQ+7D3wrCjFZIZAk6qt isn65zKBaGaTeMn+OfzWAsLsNyXCqvUT3BqQ4gd6Iu4VFtpWgetc1CehMkgaptYW uQENBFb0BYIBCACu2eXrkf+E1OE3zzXlJkG8GSL16F7qlOSqmezYGyJiPjLCSSiS WhG5s/7vbP90iM/LT9MRWExeae4JFesobPjt3TWF6vJflIL168uc6H8uKoncFET8 yN6eaayGNnhLYNef4dd+2qvU91qKZke1rRkBb7KQRUN7lTmFGOdsbYXk1OcUfS/p uZeF2QfdKhanWuDl42oQz+aB69UcDwwPbwplb329wR/I7AV+KFr1qTIIilq6qRek xOQOqzVF8mBMVS5EMjr3SQZaK9Ch21njZJr3pQ+hLI5RAx8a6k8vHn8muJEFxDTo hcPuOJ1Z8eBNKs7HA/XypJr56DCYt9nHE6GhABEBAAGJAR8EGAEIAAkFAlb0BYIC GwwACgkQhuh9SguuI8VNuQgAnuAN6UfxN55bCaTNWwJA0hietSNjKlM1TEzmjHmR 4Ch18lW2o4DT2dxCyoC+tRCjrLOxeKl7+MxGRF3mVl1tHSasjFkWFd6BohFutlJd 8r52RvdR2cPgEY+R9VLw6onQFEyMiTKxypwrCMKrB+R5qH6AvrBkGMjfZDdTqybi 8Kq4ZpqomnIsK85X+Kvr9SKuk4j4dkh244kk/8GAsZqhSKyP8D4JnylAhD/ZTSiT nXsXs0QIi1fntt6xxVx72UgR0pKEyl2koN76Mvew8qSZBALyp+o1cqaFOQXsO+gt Ri2gEEfL7Eors/Nl2+BGCHcWHXhY9F4nNz6fsq5DN+2Wzw== =LfjJ -----END PGP PUBLIC KEY BLOCK-----

3 2

Re: [tor-relays] Minimum Relay/Bridge Bandwidth
by Michael Armbruster 24 Mar '16

24 Mar '16

> Our family recently downgraded our internet connection, which limited > our upload speed to 1Mbps. According to the Tor relay doc, a minimum of > 2Mbps is recommended, yet a relay is considered "fast" if it has 1Mbps. I think you misread the documentation. 2Mbps is a recommended minimum, but a relay is considered fast if it has 1 Megabyte/sec and Megabit (Mb) and Megabyte (MB) are not the same. > Will I be hurting more than helping if I run a relay on this connection > speed? Should I run a bridge instead? With 1Mbps, you have 125 Kilobytes/sec upload rate. I would say yes, run a bridge instead. But let's see what other pepole say, eventually. Michael Armbruster

2 2

intense DDOS of exit relay from China
by Dhalgren Tor 22 Mar '16

22 Mar '16

FYI tor-relays Exit was DDOSed yesterday at 18:00 UTC. The attack was intense enough that the ISP null-routed the server for 16 hours, which has never happened before. Have seen a handful of brief DDOS attacks (about 15 minutes) in the past but none were so intense as this one. All traffic originated from China.

4 3

Running 5000 relays...
by nusenu 21 Mar '16

21 Mar '16

Moritz wrote: > Maybe this is better taken to tor-relays. Ok. url to the tor-dev thread: https://lists.torproject.org/pipermail/tor-dev/2016-March/010473.html Brian didn't say anything about planed deployment locations, but if _all_ relays are within a single /16 network you might skip MyFamily altogether, but I assume they are not. > In my case machines have a lifecycle. They come and they > go out of curiosity: What percentage of them do you expect to be online concurrently? (starting when) Are planing to rekey when "coming back" or resume with the former? > On 03/05/2016 10:31 PM, Brian "redbeard" Harrington wrote: >> "Lets say you are about to deploy 100 relays within the next week." - >> Take this an order of magnitude greater and we're on the right track >> with the correct scale. It is a regular occurrence for our users to >> deploy 500 to 5000 nodes at a time. This is why I said "and maybe set yourself an upper boundary as to how big you want to grow" A single entity deploying 5000 relays isn't very sane at the current network size I guess, but instead of speaking of relay counts using CW fraction/exit/guard probability as upper boundaries makes more sense. <10% might be a worthy upper boundary for exit/guard probability. The biggest (known) exit operator is currently at 7-8% exit probability. teor wrote: > And there's likely some limit on MyFamily or on descriptor size that would stop > you listing 1000 fingerprints. That is actually another good use-case for replacing the current MyFamily design with something that scales better with family size like Mike's proposed design (#5565), but we did not see declared families that big so far. It was no problem in practice. https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n364 > Server descriptors may not exceed 20,000 bytes in length; [...] If they do, the > authorities SHOULD reject them. So the max family size would be something around 400 relays? (20000 - 1250) / 42 = 446 (1250 bytes was the size of a non-exit sample descriptor without family) > generating 1000 relay keys and coordinating that key > distribution dance across the same number of nodes (more than likely in > highly distributed environments) seems to bring more questions than it > answers (securing the keys for those nodes, securely distributing them, > etc) What problems do you expect when generating and transferring 1000 relay keys? (besides the descriptor limit) ... but before trying to solve any problems it is probably best to answer the question whether a single entities should run >5% CW fraction at all. > There are about 7000 relays in > total, with over 1000 of them (almost 40% of the capacity) at only three > ASes. Top 3 ASes currently account for 32% cw fraction. https://compass.torproject.org/#?exit_filter=all_relays&links&sort=cw&sort_… but the top 1000 relays account for >72% cw fraction https://compass.torproject.org/#?exit_filter=all_relays&links&sort=cw&sort_…

7 18

TheOnionBox v2.1 released!
by Ralph Wetzel 20 Mar '16

20 Mar '16

1 0

Exitmap module to count CloudFlare CAPTCHAs
by Philipp Winter 20 Mar '16

20 Mar '16

I wrote an exitmap module [0] that can tell us how many exit relays see a CloudFlare CAPTCHA when connecting to a given site. First, I ran the module for coreos.com because it uses CloudFlare, but the owner configured it to whitelist Tor. Indeed, only one out of 864 exit relays saw a CAPTCHA: <https://atlas.torproject.org/#details/7DD29A65C370B86B5BE706EA3B1417745714C…> Next, I ran the module for cloudflare.com, which does not seem to whitelist Tor. 638 (75%) exit relays saw a CAPTCHA and 211 (25%) didn't. [0] <https://gitweb.torproject.org/user/phw/exitmap.git/tree/src/modules/cloudfl…> Cheers, Philipp

3 3

GoDaddy null-routing Tor Exit IPs
by Dhalgren Tor 20 Mar '16

20 Mar '16

FYI Tor-Relays GoDaddy AS26496 is null-routing selected Tor Exits, presumably in response to abuse originating from them. Know of two thus far FE67A1BA4EF1D13A617AEFB416CB9E44331B223A 2016/01/26 ashtrayhat3 A0F06C2FADF88D3A39AA3072B406F09D7095AC9E 2016/03/16 Dhalgren though probably more exist. Appears to affect faster relays. Affected relays running 'unbound' for DNS may experience total DNS request freeze and should switch to 'named' to mitigate the failure. Null-route seems to be manual and persist for indeterminate time. Null-routed IPs will not be able to ping or connect to address listed in the report at http://www.cidr-report.org/cgi-bin/as-report?v=4&as=AS26496 Information on how this was discovered can be found at #18580: exit relay fails with 'unbound' DNS resolver when lots of requests time-out https://trac.torproject.org/projects/tor/ticket/18580

1 0

please send me the hosters you use
by harvie josh 20 Mar '16

20 Mar '16

Hello! I'm spending quite some time in finding new cost-efficient VPS hoster in "unpopular" countries (non-exit). The relay community would actually have a lot information to provide in that regard - I think. I would really appreciate if you can share any hoster that provides VPSes with the following properties: * cost efficiency: at least 4 MBit/s per $ / month (min 20MBit/s) * not located in NL, FR, DE, US, GB, AS16276, Digital Ocean ASes * KVM or Xen based (no OpenVZ) * unmetered or at least 7TB/month outbound * proper https for customer area (reboot functionality, console access, ...) * English customer area You can also help by adding hoster information to your contactinfo field: ISP:<url to hoster> so others can find that (sometimes it isn't easy to find the hoster based on IP/AS information). So far I made good experience with itldc.com + price + reliable + SSH pub key pre-polulated in VPS + custom ISO possible + greate CPU performance in UA DC - plaintext root password in email mixed experience with seflow.it - almost regular outages - poor support (response time and know-how) - unable to provide correct billing information for hourly billed VPSes (start-stop times) ~ CPU performance + price (especially memory) + root password not disclosed via plaintext email unusable hoster ----------------------- alexhost.md Unreliable; to many outages serverastra.com no https coolhousing.net no https server.ua no https prohoster.info OVH reseller layeronline.com OVH reseller vmline.pl polish interface only unixhost.pro poor CPU/network performance (<15MBit/s) www.hosteasy.eu passport copy required ablenet.jp passport copy required albahost.net simply failed to provide working VPS vinahost.vn international traffic limited to 10MBit/s www.infiumhost.com no proper https (self-signed cert) alphavps.bg metered <1TB/month xserver.ua customer area language vps.ua customer area language Rx-name.ua no reaction to email request If you can not suggest specific hoster but good sites to find new hoster that is also great, like: https://www.exoticvps.com/ https://www.lowendtalk.com/ https://www.webhostingtalk.com -- harvie josh

5 7

What IPs does Torbrowser need?
by Martin Kepplinger 19 Mar '16

19 Mar '16

Hi Imagine a router that want to only whitelist the IP addresses that Torbrowser needs to work. What IPs would it need (for start up and browsing) ? * Guards * Authorities * HSDir flagged relays (?) and would such a whitelisting of IPs even work? At least I think DNS can be ignored as it is routed over Tor too. Any more thoughts? ps: please leave me in CC as I'm not on the tor-talk list. thanks!! martin

2 1

fast exits running 'unbound' should switch to 'named'
by Dhalgren Tor 19 Mar '16

19 Mar '16

Bug #18580: exit relay fails with 'unbound' DNS resolver when lots of requests time-out https://trac.torproject.org/projects/tor/ticket/18580

2 2

unbound bogs down strangely, degrading exit relay
by Dhalgren Tor 18 Mar '16

18 Mar '16

Hit a repeat of an earlier incident: https://lists.torproject.org/pipermail/tor-relays/2016-January/008621.html message from tor daemon is Resolved [scrubbed] which was already resolved; ignoring About 5400 of these messages over 37 hours, during which the relay dropped down to 30% of usual load and did not work for Tor Browser when the exit was specifically set. Unlike the earlier incident, DNSSEC was disabled. Probably the IP address for root-server H was incorrect because it changed in December and 'unbound' was built in September. Just installed and configured the current 'named.root' hints file. Both "iterator" and "validator" modules were loaded, though validation was disabled. Changed the config to load only "iterator". Unbound 1.5.4, tor 0.2.6.10. Running 164 days. If I see this again I'm planning to attempt purging the 'unbound' request queue with unbound-control dump_requestlist >reqlist.snap unbound-control flush_requestlist and if that doesn't work, bouncing 'unbound' without stopping the 'tor' daemon. Interesting stats were recorded, starting with the good pre-incident entries: Mar 11 05:53 notice: sendto failed: Invalid argument notice: remote address is 0.0.0.1 port 53 ...repeated 4 times Mar 15 17:45 server stats for thread: 1029423 queries, 415824 answers from cache, 613599 recursions, 0 prefetch server stats for thread: requestlist max 132 avg 22.5692 exceeded 0 jostled 0 average recursion processing time 4.070100 sec Mar 16 05:46 Resolved [scrubbed] which was already resolved; ignoring Mar 16 17:45 server stats for thread: 1162172 queries, 287662 answers from cache, 874510 recursions, 0 prefetch server stats for thread: requestlist max 421 avg 198.684 exceeded 0 jostled 0 average recursion processing time 25.833646 sec Mar 16 21:08 notice: sendto failed: Invalid argument notice: remote address is 0.0.0.1 port 53 ...repeated 4 times Mar 17 16:52 notice: sendto failed: Invalid argument notice: remote address is 0.0.0.1 port 53 ...repeated 4 times Mar 17 17:45 server stats for thread: 1078496 queries, 144557 answers from cache, 933939 recursions, 0 prefetch server stats for thread: requestlist max 459 avg 296.668 exceeded 0 jostled 0 average recursion processing time 40.621863 sec service stopped (unbound 1.5.4). Mar 17 19:28 server stats for thread: 53991 queries, 3455 answers from cache, 50536 recursions, 0 prefetch server stats for thread: requestlist max 342 avg 290.977 exceeded 0 jostled 0 average recursion processing time 35.947563 sec If anyone has seen this or knows anything please comment. Tried searching but came up with nothing but thread referenced above.

2 5

Re: [tor-relays] Bandwidth Fallen Off Drastically
by stealth＠nym.mixmin.net 15 Mar '16

15 Mar '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 14 Mar 2016 19:29:58 +0000, you 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. Bandwidth Fallen Off Drastically (stealth(a)nym.mixmin.net) > 2. Re: Bandwidth Fallen Off Drastically (Daryl Styrk) > 3. Re: Bandwidth Fallen Off Drastically (s7r) > 4. Re: Bandwidth Fallen Off Drastically (Sebastian Niehaus) > 5. Re: Running 5000 relays... (Brian 'redbeard' Harrington) > > > ---------------------------------------------------------------------- > > Message: 3 > Date: Mon, 14 Mar 2016 19:45:06 +0200 > From: s7r <s7r(a)sky-ip.org> > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] Bandwidth Fallen Off Drastically > Message-ID: <56E6F8A2.5030903(a)sky-ip.org> > Content-Type: text/plain; charset="windows-1252" > > Hello, > > Your relay seams fine on atlas: > > http://atlas777hhh7mcs7.onion/#details/A290A9E71ADFC2FB1C80E64EF851A4B90545… > > > It has an observed bandwidth of 582.23 KB/s > Advertised bandwidth of 512 KB/s > and burst 716.8 KB/s > > Which is exactly as per your configuration. > > The consensus weight is 613, which is totally normal for this value of > observed bandwidth. > > Tip: if you are on a limited bandwidth plan, better set AccountingMax > and do not cap the speed via RelayBandwidthRate / RelayBandwidthBurst. > Instead let it run at its maximum speed for less than an entire month > rather than capping it to few KB/s to ensure maximum n GB/TB are > consumed within a month. > In a previous post someone recommended that I try to reduce my bandwidth to allow my relay to stay active 24/7 x 31 days. This is why I removed the AccountingMax setting and reduced my RelayBandwidthRate to 500kb/s and RelayBandwidthBurst to 700kb/s. What concerns me is that while running arm in graph mode, I rarely see the bandwidth rate steadily flow around 500kb/s. With a 3tb bandwidth limit per month, following your recommendations, would you recommend that my AccountingMax be set to 55gb per day up and down and turn off RelayBandwidthRate and RelayBandwidthBurst? This will probably mean that the bandwidth will be used up within the first 10-12 hours of each day and my relay will be in hibernation for the remaining portion of that 24 hours. This hibernation period appears to affect the uptime statistics, which means my middle consensus numbers will drop as a consequence. I'm trying to figure out what's the secret sauce here to keep the relay running 24/7 and stay within my 3tb bandwidth limitation. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (MingW32) iQIcBAEBAgAGBQJW5yi+AAoJEH1gNwhiMDZubTgQAJuj6EdfLZsyPsLxfeiLA2nh w52jJLO3yXg+InJ4IzoSaHzbXsqdUuSmj7RxOsgTr9K1xflX3XkdNmlWYkhs005F JNMGyglnOb3LlSbJ9fxspZH1KOhwJwy9ZJrHGRqVRXrAC7VBMpJ016TEcFNL3daL J98LhZuyN5Iecm0k9LhuxoZ0YfnCc03qpkUJDMiM0khsXfoesFWd+Zdss/Igj2aC mVcE+BMKvO8gHATdVytvHvqqZ07unIAV6mRkw/c/NBqRh07xX6qEJwoDANCEvfS6 7NGQZpgEVWw2lT2GPj5T4WGmEPN6CAfCJTE7fJG1IA1j4iLNgHwRM7kKxQpFWpVa CAwE8wgc9BxFYCVg8Kzjr/PDJO7mNLFRH3yXXJ9dTo6qS+GRxdZEYTH6FaNc9ERP W9/hnv18bo0IuQ+o8+sMtzDbAbyyPXDeSbx2qHOzxuTJkzLPkq2t8W2HX5kiurZ8 MIkdkJH+bc71EwV1YBzb/Ca4/kdqTRqEMJzXFtn8wq6fa1uRxDC1S7Su374y4fTy C1OmTfURhKhK39yVFVJrKqINsgE1GQnKikE2DCMlbrp+IFaItrDOg+gx81mO7WkK /KbpxnKJotLxIxBX12j0T6CYyGKQio6SSTbI0iObsXJNpEkQCX+jPp3GDDcWPzlK p/XtNor8MXQS1u96hpwP =z+T6 -----END PGP SIGNATURE-----

2 2

Bandwidth Fallen Off Drastically
by stealth＠nym.mixmin.net 14 Mar '16

14 Mar '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have been watching my middle relay for the past four days and I can't figure out why my bandwidth has gone to hell. I have RelayBandwidthRate at 500 KB and RelayBandwidthBurst at 700 KB, but my bandwidth has fallen almost down to zero. I have removed the AccountingMax setting so it should be available for service, but it appears to be sitting idle. fingerprint is 'stealth A290A9E71ADFC2FB1C80E64EF851A4B905450105' Tor Version 0.2.7.6 Debian 7.0 1 Meg of Memory on VPS -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (MingW32) iQIcBAEBAgAGBQJW5t3wAAoJEH1gNwhiMDZuSasQAKQ0PQrNqqVl2x0nhKUPvZTz xCffMMmDeE+xU3QvMhGDxuliIJVgxuP0jqtXzZ6Vrxr9QQ4f7XwuK057O8PD9nnq B5UsYXjoV/2VsDgv0n+mOv3LmQB2CJv/GJzSnl4/ZYaW8k76P0FavS6HHpZKnM6T g5ybxnscpiSbP6GO1ZuK3cRxDfTFtoh80HsShgDG7VAOHPzyFNz4diKQJ3J5LQe5 1QDvFB6l4VUZTCN9++2NvwLkvIGS9xMeX4TOOVwwV9lZDmU+aE0zH3EkIJrnhjv4 tToyypxCCTLkgTN6BkFTF7Ug07H4oqs0J09SWkLT6XUsvm+QSf7dL2Nzujp1KkYl yuZLqkpxgtgUPde3Ejcdgzy9Zv3y+j89f+JavAWy5VAQ5779V8nKonYclINROpcX 2PlOuE4GvrOrurUQzQJJfvSkWEF3NNJjvrAZGyM6X79v/F6/zod1QV5a0/ASUY5g vNUbLQfjGHExf86UZRak1un1x4/yzESnddZPHWALcNR/JHQHgra7+283RHqVNxeX 7zggM+HNxIxKYngC4B4V+9hZnuXE8Ty2444ykXNrZibQSDiFf5RIBBffmbRtJxzJ K/Jrdw9VyajNPx4AnV+gnh611+bgNw9Rpo1WKHd0KOdeLhKUC8js1ZvZpiPpqojR CPkUwxBAh8Ydt4HEp3Mw =jZnl -----END PGP SIGNATURE-----

4 3

Re: [tor-relays] tor-relays Digest, Vol 62, Issue 13
by stealth＠nym.mixmin.net 09 Mar '16

09 Mar '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 09 Mar 2016 01:16:18 +0000, you wrote: > > Message: 3 > Date: Wed, 9 Mar 2016 12:08:31 +1100 > From: Tim Wilson-Brown - teor <teor2345(a)gmail.com> > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] Hibernation Expectations > Message-ID: <6449D528-F52E-49E6-8331-0F3276365348(a)gmail.com> > Content-Type: text/plain; charset="us-ascii" > > > > On 9 Mar 2016, at 05:29, stealth(a)nym.mixmin.net wrote: > > > > Signed PGP part > > I am allocating 100gb of bandwidth up and down every day. When my > > middle relay goes into hibernation, should I expect my stats to go > > to hell? Should I also expect my flags my stable and guard flags to > > be removed? > > Yes, but they'll come back eventually. > > > > > If I reach my bandwidth restrictions 10 hours before it is reset, > > is this the reason why the relay would lose guard and stable flags? > > I may need to restrict my bandwidth to 60gb up and down as I only > > have 3tb of bandwidth to donate on a monthly basis. > > This is another question we see frequently. > Until we get a FAQ or wiki entry for it, I'd encourage you to search the list archives for previous answers. > > There are good reasons to run a relay that's always on. > Then again, there are also good reasons to run a fast relay. > If you're very close to your bandwidth cutoff, why not decrease it slightly, and run all the time? > > Tim I have changed my AccountingMax to 60gb and my RelayBandwidthRate to 5mb and my RelayBandwidthBurst to 10mb. I will monitor these settings for the next couple of days to see, if I reach my AccountingMax number. If I do reach the AccountingMax number then I will reduce the RelayBandwidthRate and RelaybandwidthBurst down until my server can run 24/7. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (MingW32) iQIcBAEBAgAGBQJW4G4MAAoJEH1gNwhiMDZu8bsP/3j4GYhUKZMZbnm2+i+7XJ5C vGWxQgHC/7bMe5zuQY7CjHuPZRjqNImbQTy8FPLb1NGKuutVS1RcQafDvTVBUJiL a64dTCAAbf12AScSxCzhqgBpWQ1nW2mKRPTeGUOrkeCPgx3o/Cqby5U3fL0Hcy3R lhrTWOlca3waJDnpNzlslMgXVLhoR+cspflKoi+NzFoanHDveipkcZEr65cIBoWJ QlYcfH0CE1070W68DatwtNzyQW7Mm9bMULX8aWJQpjMIvd/GKZ6OGGysXjgLDbDN x2b7/VcHuxNXaVJSbhdenoA2GoF1h02Sl9K1QUMVo46LqVfsJiZduSmvB4EJz9VA KsMmTc3C51Mp3EgdH538gP9lfNA/PhT/1KrHFz9ILnC0sy9E8zxHzpk9+Lt7652/ PTaeVE0+1epAVG3namxaMLiK36gOUD4xuGi3UP18U2s7UzlaesEusSie6j+wHZid /D3pQTE50Mj7eb4yxLziBU/DS3UB4FwhRphCKqnB/ZdJWbMZ88hAfwfcgxmTjvB0 7fZ6wtZDsdAqWPOTzRlkEVifS1ZcS0WgT2FGSmzBbUH7/hT9YTuKdHelUNrYBJy+ 3b5A+6/kMCBUV0bJjiUirINATG0XJDGoYmSjFm/Z7ac/vfOh+TXzTwiG+yITJ1cA FuaKL42rov2Ier2nWnYu =BnNF -----END PGP SIGNATURE-----

1 0

Hibernation Expectations
by stealth＠nym.mixmin.net 08 Mar '16

08 Mar '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am allocating 100gb of bandwidth up and down every day. When my middle relay goes into hibernation, should I expect my stats to go to hell? Should I also expect my flags my stable and guard flags to be removed? If I reach my bandwidth restrictions 10 hours before it is reset, is this the reason why the relay would lose guard and stable flags? I may need to restrict my bandwidth to 60gb up and down as I only have 3tb of bandwidth to donate on a monthly basis. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (MingW32) iQIcBAEBAgAGBQJW3w91AAoJEH1gNwhiMDZuPo0P/2jKTt3DAX6pFIU70nTl55IE RxgP45KZnv7RmqLPN5T4UAKl7BmuhWLDY7uIRzfoagersXNXbWrcvRZrpGR8Eycf OS4jNjw0WPX3AgzmU0XeIkPypu2vJ1Qdz3dfRsNiguwUPwPHvGE9d6yKp/3DztYs rtBcWQ0yiCn3vDLgEHSjyUop35lJla9Rg1l7DWgfJEKc+6zqOMsLod5Ie0ZVETOY b8gmP0Ct9Bqyzj9zHlXbEgk0M9t7f2g/cOkX1G3ABBQVMe83rcssNPodDy8xFpYm AA0K6LmUzz94kxhmu/wzph48PRsm5cdr4mAXbDkKkVlQxszHCGZqbMR2Zdff6txh GGSb8AdXX7eTzsIAJ8eDN2ZsWsneuKiofvXY2oSyuOpgl+jeHxivXJoYunXvEQER rikVhoZkn0X4hotNzIAWdEQgifmfxhGXuphytHNphCFkCY5I6UY+HNLjcZTl+9OH vytFYvpy/zc5zEjHhrM6FWxXYSgBCL34jo0L9Hr6dqDYD4pPBf/Td2CiBXdNEliK tD+JYlH9gFQ/TmNePef9za1vWF0t+8QlpsZYqTZ3xuHYN24Znjdnklr+nbIlrUTp 9tpibQ4MisX781wadp0OCqePmxZjyiwnZEHxHNlW6KcrvP37kXTmIFdybUZV6eYx equ2uTmOQ9EzuJidfxO4 =zOMH -----END PGP SIGNATURE-----

3 2

Ticket #18489
by Felix 08 Mar '16

08 Mar '16

Hi I stumbled over [1]. As I operate Doedel26 I checked DownloadExtraInfo was default. After change in torrc to 1 and reload 'cached-extrainfo' showed up in /var/db/tor/. Can someone please advice how to deal with it ? Best regards, Felix [1] https://trac.torproject.org/projects/tor/ticket/18489

3 2

relay maintenance without losing consensus weight?
by Zwiebel 08 Mar '16

08 Mar '16

Hello, is there a way to shut down Tor relays for a short time without losing consensus weight or bandwidth? Last week I installed a newer Tor version and added more RAM and now my relays lost a third of their bandwidth. Last time I've upgraded the hardware was in January and the relays didn't fully recover from the downtime in the last two months. I'd gladly provide 200Mb/s+ of relay bandwidth if I could, but Tor won't let me. - Zwiebel

5 6

Northeastern University Relays
by nusenu 07 Mar '16

07 Mar '16

Thanks for adding relays! Maybe set a contactinfo? (Whenever a university adds an unusual amount of relays it reminds me of the CMU case though.) http://article.gmane.org/gmane.network.onion-routing.ornetradar/1030 (I'm not implying they are doing anything bad)

2 2

misconfig resolution for Tor startup on linux?
by torserver＠datakanja.de 06 Mar '16

06 Mar '16

Last week, i had been erroneously assuming, the daily reassigned external IP addresses from my provider would kill Tor, as someone suggested in the IRC. So i ran a quick "sudo update-rc.d tor disable". Only later, when i learned, the IP change doesnt cause too much trouble, i reenabled Tor. Since then, the tor service doesnt come up on computer startup any longer. I tried all kind of things, like: sudo update-rc.d tor enable sudo update-rc.d tor defaults i even reinstalled Tor completely, but the service does not start automatically any longer. After finding this to be true, i began to start it manually after each reboot like so: sudo service tor start # this does in fact cause the service to run as debian-tor user, as it should! Unfortunately, it is necessary to reboot from time to time, to prevent acceleration in memory fragmentation caused by several programs i use on a daily basis. If not prevented, the latter causes system instabilities and introduces severe risk of data corruption. So back to the basics: i am just a simple Ubuntu user with a machine, that is connected and running basically 24/7 (except for the daily disconnect, as can be seen from the logs). And i would certainly appreciate any suggestion to check for, why upstart doesnt pick up Tor, as it should. From my own understanding, eveything looks pretty normal, like: find /etc -name ?20tor | xargs ls -l lrwxrwxrwx 1 root root 13 Mär 4 04:19 /etc/rc0.d/K20tor -> ../init.d/tor lrwxrwxrwx 1 root root 13 Mär 4 04:19 /etc/rc1.d/K20tor -> ../init.d/tor lrwxrwxrwx 1 root root 13 Mär 4 04:19 /etc/rc2.d/S20tor -> ../init.d/tor lrwxrwxrwx 1 root root 13 Mär 4 04:19 /etc/rc3.d/S20tor -> ../init.d/tor lrwxrwxrwx 1 root root 13 Mär 4 04:19 /etc/rc4.d/S20tor -> ../init.d/tor lrwxrwxrwx 1 root root 13 Mär 4 04:19 /etc/rc5.d/S20tor -> ../init.d/tor lrwxrwxrwx 1 root root 13 Mär 4 04:19 /etc/rc6.d/K20tor -> ../init.d/tor Sorry for asking such an unadorned question here, i simply ran out of ideas. :-( NewTorKidOnTheBlock

1 0

Re: [tor-relays] Guard Status vs Middle
by starlight.2016q1＠binnacle.cx 04 Mar '16

04 Mar '16

>If your relay has been given guard status does this mean that >one's middle status is put on hold or can a relay be in guard >and middle status at the same time? Guard-flagged relays are both middle and guard nodes. Take a look at the relay in https://atlas.torproject.org/ and https://globe.torproject.org/ to see graph-lines of the probabalities

1 0

Guard Status vs Middle
by stealth＠nym.mixmin.net 04 Mar '16

04 Mar '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 If your relay has been given guard status does this mean that one's middle status is put on hold or can a relay be in guard and middle status at the same time? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (MingW32) iQIcBAEBAgAGBQJW2homAAoJEH1gNwhiMDZuGMAP/335WjiHWFV0XAmUYjowrwwM griNn3j13mUEQXYlNCDeL7lH8QUCf4DYM7zywgJm4VSz/sJyPl8lzO4hJeS09fte Emf4adSxMTrj5/jh+/S8zbVY5iDVfCZISw/5jOsBm3CR7QgarvhSFLOHhPQukr9O gQDo90ViVdz6NeVaDqYFzaFFvN3buN7kkuuN9ZGjNHttfY3AG3Rrx5X4LktkMmRH ZE0Y3B3aYBUlxvdG3oXrPo6JMaSd5ABMxWaj/LucRG2zvOPgUE8v8i4RaFNgnrFB oSCJYFLP8GpLrEUS50WUH5wiM915oWif3Y4TPSsrFanxAeFpboudaqfE7H1GjjBs 7tio+bbzMISjIdI9JFrd4GnOrLSqpe+44ooEA0pjNajiIaYhsOEXhTP4A+vktkcg lmAjK/SrjrNyuSwnpkKx24mw9H9JCWDmm15VFk+t0mloTsxnT0242YrChtAtcEft Qiv+f0Yo3Iek9FP573iq131xDg8/V10GvJnlSo7Zl/IJiQQW9KOzdOaQrIOlSjPr Aw9PWLlBoyeMd4LlRtwFUIKjpJMbSh2QXb+EbLwqoHDK0UAHyjKp+UXMvzb8WKoE rIiu9SV/X0QPmJEYw9HBy9ZDihYaWg69ndE37lb9lvPECDtmrRmcLhY0/1aSKnSU UG8ybdzEVLkfspNWjfex =JSaf -----END PGP SIGNATURE-----

1 0

Release of TheOnionBox v2!
by Ralph Wetzel 04 Mar '16

04 Mar '16

1 0

biggest guard operator apparently left the tor network
by nusenu 03 Mar '16

03 Mar '16

4 4

Network Bandwidth Fine Tuning
by stealth＠nym.mixmin.net 02 Mar '16

02 Mar '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I ran the speedtest on my VPS which gave the results below: root$ speedtest-cli Retrieving speedtest.net configuration... Retrieving speedtest.net server list... Testing from ProServe B.V. (81.4.111.251)... Selecting best server based on latency... Hosted by NFOrce Entertainment B.V. (Amsterdam) [0.00 km]: 4.817 ms Testing download speed........................................ Download: 711.10 Mbit/s Testing upload speed.................................................. Upload: 449.12 Mbit/s My Bandwidth results are averaging around 1.5mbs to 3.0mbs via the Tor Globe Stats page. Can someone tell me how to increase my network bandwidth based on what I am capable of uploading and downloading. I am allocated 2TB of bandwidth per month from my VPS Right now the Advertised Bandwidth is 1.7MB/s and when I scroll down further on the page in the Bandwidth section my "mean written bytes" are 226.15 kb/s and my "mean read bytes" are 227.1 kbs/s I see several sites averaging 50MB/s-60MB/s on the Top Ten Relays list -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (MingW32) iQIcBAEBAgAGBQJW0iFwAAoJEH1gNwhiMDZuT60P/jt6YmdvtjR48zhe/fQ2sx4z Uw76B+vjonWqKOaCqyJFBM/buFoXUixTJJ6ksj/KjiVVEdTU4/7WhbwwYTUWGYyc tYhB7nWCxdCNKPy4YMNUG3r+pIaMp1gF+k6wfnHHU+Pqq0H9tTMPNS0Ey44fM0bN BaX2NjuDYpOXDkmKO8xAzKv+KQr9a6pR/DBgC73LniqiZejV3iyMvof7/hypvltq h3QJoFZ8DYjCgk+W0qEWhjCky5RFze1f8ihFsVaM7U8WH6hGcULgXAYZl8Q/MAmN 4jlSogFDSh/e/+0DqVyrkgpyxIPZ43/4y2sn2WYfR8egeocVi6NO9VHtiiygUtcn jOAzaGROGtW6oXNQtGvfeJRwAEsoPmfHF09TJANRB++/KjjSm+cM/ALT1O4b3t5U ZMC5rkoJOUX2jyo3kZpBpobLOW012BnnbGyVV5KNM/BpVkM1sIxOnFhoSfYWij5c QziOvk5wtDXFta2ow12lgruW9wT2moier1WxAxib6u9V05jxckXrpmb3V9yvWBOz SzXh05lh7pEuAfPb2RQXKjGjmkqCweOI2cGhu4B3vDFNKRBhjdXYFZP7/aFe4DRh +J4su48cYVWcnav0c14/27oHxeoYUD8NQV2gBcs7/dCSa1iWHV+PORjBSe+l+IGG R2qL40EDeIgC9TVJqriD =c73J -----END PGP SIGNATURE-----

6 9

Stopping the censoring of tor users (via exit bridges / proxies / OpenVPNs)
by grarpamp 29 Feb '16

29 Feb '16

On 2/25/16, blacklight . <pandakaasftw(a)gmail.com> wrote: > hello there! i don't know if this mailing list works but i thought of > giving it a try. > > i was lately reading an article ( > http://www.pcworld.com/article/3037180/security/tor-users-increasingly-trea… > ) > and it was about tor users getting blocked from accessing alot of website. > but after giving this some thought i think i came up with a possible > solution to the problem :there is a thing called bridges, they are used to > access the tor network without your isp knowing that you use tor, but if > you can use those proxies to enter the network, it might also be possible > to exit the network with them. But then we face a second challenge, the > exit nodes have to be configured in such a way that it will relay traffic > to such a bridge, so the exit node owners also need to know the ip of the > bridge. While this doesn't seem difficult to do, it can become difficult. > You see if the bridges are published on a public list(like normal bridges > are) then the blocking sites in question will be able to block those > address too. While this also posses a problem, a possible solution could be > found in something called flashproxies, flashproxies are bridges with a > really short life span, they are created and destroyed fairly swiftly, when > this is done in a rapid pace, they become really hard to block because the > ip changes all the time. So if the exit nodes can be configured to make use > of such flash proxies, then the problem could be solved. I Must admit that > not an expert on this or anything, and it needs alot of more thought, but > it could work. so i was wondering if there are any experts who could help > me with thinking out this subject and maybe confirm if this idea could > work. Skipping that whoever wants to enumerate, test, block, and share lists of the IP of your final hop will find a way to do so... "flashproxies" - are essentially illegal to use as the operator got stupid, and didn't gave permission. - are unstable as were never intentionally provisioned, and the operators get smart when abuse reports and shut them off. - proxy lists are going to be a pain for you to scrape and maintain Options - run your own volunteer network of last hop "proxies" / bridges - buy them from AWS or wherever "meek" style - partner with or plug into already existing networks of those - get tor relays or bridges to do this I previously wrote in archives that exit relays could bind OpenVPN to extra IP's they configure on their exit relay boxes. Tor daemon has nothing to do with those IP so they never appear in tor's easily blacklistable consensus. Users then OpenVPN over tor to those via use of the relay fingerprint to reach vpn terminator IP over relay localhost to save bandwidth, and on out to clearnet. You can OpenVPN to some list of onions if you don't feel like listing the relay fingerprints / extra input IP's on wikis. But it's not going to stop dedicated blacklisters, and onion doubles bandwidth use. However it could also be used by non-exits that for whatever reason didn't want to be a tor-exit but did want to offer exit via some remote third party vpn service. And strictly social sharing on forums etc could happen for distribution. There are already some exits that for various reasons, intentional or other, do not exit from their OR IP. That is a feature that some tor users do now find and use. And relays don't offer OpenVPN yet which would also give users more than just IPv4-TCP exit scheme. Though it is integrated somewhat, I2P has this manual sort of exit offering model with false.i2p and a few other nodes. [Doesn't seem to require daemon dev work, updated subject, continuing thread reply to relays and talk.]

1 0

What do the huge providers have to do within tor circuits?
by torserver＠datakanja.de 29 Feb '16

29 Feb '16

Hello, slowly getting acquainted with running a Tor relay, i am wondering: >From my gathering, tor is - at times - connecting to many instances of akamai CDN services, amazonaws, and other similar services simultaneously. When i say many instances, i mean: a saw a peak exposure of 30 outgoing ports from my server all going to the above 2 alone (as gathered by iftop. I didn't set up snort just yet). This is seen on a NON-Exit-relay and is troubling me: I am aware of Akamai being the premier CDN provider, serving around 30% of internet traffic alone. Their server power, manpower and know-how is huge. And their ability to draw information from any sort of internet traffic is unparalleled. >From my outsider's perspective, they are in the process of building the tools to effectively dismantle the means and purpose of the Tor network at large. That is what is giving me chills, when i watch them acting from inside the circuits. Clearly, they would be able to hide their identity while doing so. And since they aren't, i may be getting something wrong. So that is why i am asking you: Does anyone KNOW, what is going on? NewTorKidOnTheBlock

2 1

default exit notice
by Markus Koch 29 Feb '16

29 Feb '16

Does anyone have the exit notice in japanese? markus

1 0

Any known Tor relay seizures (in Germany)?
by Thomas 28 Feb '16

28 Feb '16

Hello everybody, do you know of any relay seizures of non-exit relays? In the legal FAQ [1] this "risk" is only listed below exit relays. Have there been any of such events in Germany (either exit- or any other nodes)? Would I have to worry about seizures if I run a guard or middle relay in Germany? Regards, Thomas [1] https://www.torproject.org/eff/tor-legal-faq.html.en

4 3

Re: [tor-relays] tor-relays Digest, Vol 61, Issue 43
by stealth＠nym.mixmin.net 28 Feb '16

28 Feb '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, 28 Feb 2016 20:21:45 +0000, you wrote: > > > On 28 Feb 2016, at 21:17, stealth(a)nym.mixmin.net wrote: > > > > > Is your OpenSSL compiled optimised for your processor and for the encryption that Tor uses? > > > > > > > I am using the OpenSSL that was compiled for my version of > > Mixmaster as I am running a middle remailer on the same VPS. It is > > OpenSSL: 1.0.1e > > Does Tor log a message when it starts recommending an optimised version of OpenSSL? > There are no references in my notices.log and my .log file is empty. I will temporarily change my log level to debug and see what it shows. > > > How much RAM does your VPS have? > > 512KB > > This is likely to be your issue. 512 MB is not enough for a large relay. > Tor will limit its memory and connections to stay under about 3/4 of the memory you have. > Try 1GB. > > Tim Thanks for advice. Unfortunately upgrading to 1gb is not an option for me. Right now it appears that Tor is not using anywhere near what is available in memory as evidenced by my top command. top - 12:49:36 up 5 days, 20:32, 2 users, load average: 0.05, 0.09, 0.08 Tasks: 70 total, 1 running, 69 sleeping, 0 stopped, 0 zombie %Cpu(s): 1.3 us, 0.5 sy, 0.0 ni, 98.2 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem: 524288 total, 198400 used, 325888 free, 0 buffers KiB Swap: 524288 total, 0 used, 524288 free, 37620 cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2535 debian-t 20 0 99116 69m 2980 S 3.3 13.5 125:37.86 tor 2422 root 20 0 131m 5108 1080 S 0.3 1.0 5:04.66 fail2ban-server 16014 debian-t 20 0 107m 22m 2516 S 0.3 4.5 6:21.65 arm > > Tim Wilson-Brown (teor) > No response necessary. Thanks for your feedback Tim. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (MingW32) iQIcBAEBAgAGBQJW01+NAAoJEH1gNwhiMDZuctQQAKtZM7sQpue4+SpW+o0hdvpO I6XLk9YWHTszJehj5Gk3ik01yBdBiOgD2SJ2rx/cjR4AnRkRyjN6LOt3g/KxnTYI 4FNGo4fygYn4Oeu+HXmtEey3wyCVxWAzsmCXGNO6LhZhupfdmlv/ftcvcGI9VrJQ wNZTW7QeHpUCJLBt9fbh7Drw+MNwLycwHdmV5kvCWWGK1vqzpWOK44Wmk4lz5+lv ung5/HRHpt865SkXp0l/+w+p4qgTSgZ3thXpqtH1mHQPt52n4PKdUDF3Mf1yXYuf JdOTBNThzZ4s4KNj3cdWH4Wf3wPwpIZ5zCZQ2O+osMpTeOSTOZHwPmStNFdM/CuH OtLxJQb5TaVoUjOqzfcetMbx/5JlT1cutDOL5fVCiGSJ7j6q+FekknkrtKxtIKdU gUobGBJ1u8Ei7axaR7rwcL3egouugQYfDHEEFZdYBBW0tgeNx8l6SCEt7IfqEqhW Fmy58WUBs27ei9dnl9I/xq2V9FYBjdN4tpis22wctife/hth8hJWsMTLJYqP7qj9 9jqcJCgs7b7tkQsem72ApWMAgYnXVCMYscnPKTWdCEw9rdiarmArgPfE0AYuo6Lq NIVg4IADmc/X4Y1SUKq/bYW5vkfIhHKA4aoZUZRj2AL6dcLtj5clAL9MnmyKDB7a 1Ie9DF8NEKkTldYHh5IN =o3VV -----END PGP SIGNATURE-----

1 0

Tor Process Being Killed on VPS
by Stephen R Guglielmo 28 Feb '16

28 Feb '16

Hello, I have a VPS with 512 MB RAM. I run nothing on it except nginx and a Tor relay. The relay is an entry guard and moves about 20 MB/s. It seems that the kernel is killing the Tor process with "out of memory" errors. Are there any tips for mitigating this? I don't have the money right now to upgrade to the next higher VPS plan which has more RAM, unfortunately. Maybe there's some config settings that I can modify to limit the RAM usage? Or, am I just out of luck? Thanks, Steve

10 12

Re: [tor-relays] tor-relays Digest, Vol 61, Issue 41
by stealth＠nym.mixmin.net 28 Feb '16

28 Feb '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, 28 Feb 2016 13:49:20 +0000, you wrote: > > > Message: 2 > Date: Sun, 28 Feb 2016 12:02:13 +0100 > From: Tim Wilson-Brown - teor <teor2345(a)gmail.com> > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] Network Bandwidth Fine Tuning > Message-ID: <A09CFFB4-5ACA-44B4-B813-7DC0B30A4C06(a)gmail.com> > Content-Type: text/plain; charset="us-ascii" > > > > On 28 Feb 2016, at 02:14, stealth(a)nym.mixmin.net wrote: > > > > What processor is on your VPS? Here is my lscpu output: root$ lscpu Architecture: i686 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 8 Vendor ID: GenuineIntel CPU family: 6 Model: 58 Stepping: 9 CPU MHz: 3300.152 BogoMIPS: 6600.30 Virtualization: VT-x > How fast is it? See above > Does it have AES-NI? I believe so. Here's the output from: grep -o aes /proc/cpuinfo aes aes and here's the output from: grep -ml -o aes /proc/cpuinfo aes > Is your OpenSSL compiled optimised for your processor and for the encryption that Tor uses? > I am using the OpenSSL that was compiled for my version of Mixmaster as I am running a middle remailer on the same VPS. It is OpenSSL: 1.0.1e > How much RAM does your VPS have? 512KB > > Have you read the torservers.net Tor tuning advice? Yes I have made several modifications to my RelayBandwidthRate and RelayBandwidthBurst. I have also modified my AccountingMax number. Here's the pertinent information from my torrc file: RelayBandwidthRate 50 MB # Throttle traffic to 100KB/s (800Kbps) RelayBandwidthBurst 80 MB # But allow bursts up to 200KB/s (1600Kbps) AccountingMax 100 GB > (And similar articles?) Any additional links would be welcomed. > > Tim > > Tim Wilson-Brown (teor) > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (MingW32) iQIcBAEBAgAGBQJW00AMAAoJEH1gNwhiMDZu2wYQAImPETHwRvlxrlAclulMlB+n WwPB/fMSjiVwA9Rllb7w8NvSbf2Tu9FmeGoYOUDYTWuq93RsUuQFtVvcw3MXkzBR X/TXAdP9WSDlNiOZajaRNR1hcYQJ0gJqJ9/6oyC1XoDNTK7bcE3FOY5ui10M+fFL rXgM/qBmu+toaqA2vL4DKp3eFYMYDgVmesQLEI6edUvHjK4+itdV9pRwXAvQaFjJ M7We374Siw6izM6cJqXtW3XytUCfIbVyzL+Al93fEJnJDaO5V3kIlHDkjcWJn9ev Ogvg1/zZouwfFFJfC1p29NTsEzy8aF+w3obtq6NWQ0/pzTXJ/sPYIE21EHRIuMJo J2Rk9YPVwp5ckIKH48Eg6jdGjNCI6rs59hhNJfvismvJES+NjgLoqJ+Y59ZnhMjr q4rUssRxyzDFqDdBM60llXfTOh0qEFeHDkeBMfR+F4TJH8SZeEBXW3kyFnG6TH6R D/BoV9ItHi7qXiP9zDIMHTSCz7NNJ210uVdHbMUkMH1He+5bB/auCNRcjXmPwbYg kwbzJlgumSSd4kKufEnvC9KQComniYph90yDr8pOBnCE5E/o8+yVfB7XmTLidNEG Ii/xhSKpdt+E7wQX3ISR2pbJ73tk+FaSd2iPVK0jPWab/zoGqVzZr41VFAWi8n6S tuuLxJ5Lum3gu7EH6M0X =h78g -----END PGP SIGNATURE-----

2 1

Hidden Service on several relays + same .onion
by Pierre L. 27 Feb '16

27 Feb '16

Hey all, Thinking about having fun with hidden-service webhosting on few relays. If I'm not wrong : Host DNS name .onion of a server is stored in the file /var/lib/tor/hidden_service/hostname, there's another file private_key... So my idea is to host the same website on 2 relays with different WAN IP, fingerprint, etc....... But if I copy those 2 files "hostname" + "private_key" on 2 or 3....... relays, will it be ok ? With this set up, if 1 relay is down, the 2nd can be reachable with the same .onion DNS name ? Will this failover method work, or will be it a mess with 2-3 relays with the same .onion name ? Do someone have tried this ? Thx all!

2 2