- tor-relays - lists.torproject.org

Multithreading
by Sebastian Urbach 17 Sep '14

17 Sep '14

Hi, Is someone able to provide a timetable for the multithreading implementation into the alpha branch ? I'll take anything ;-) Thanks -- Mit freundlichen Grüssen / Sincerely yours Sebastian Urbach ----------------------------------------- Definition of TOR: 10% luck, 20% skill, 15% concentrated power of will, 5% pleasure, 50% pain and 100% reason to remember the name! -----------------------------------------

4 4

Port-Based Best-Fit Circuit Selection
by Paritesh Boyeyoko 16 Sep '14

16 Sep '14

Hello -- First of all, let me apologise if this has been covered before on this list. A couple years ago I took more than a passing interest in Tor and decided to run a non-exit relay on a VPS, which lasted until an upstream provider complained. I've recently set up another one, and while it settles into the network, it got me thinking about utilization. Much has been made of the fact that Tor is circuit-based rather than packet-based, and also of the fact that faster relays attract more traffic. So, I was thinking that in the same way that Tor relays have port-based exit policies, could they not also have port-based entrance policies? In other words, cause deliberate selection of a "slow" path based on the protocol intended to be used. So for example, HTTP would favour faster circuits, while the likes of email (POP, IMAP, SMTP), XMPP and IRC would favour slower circuits (being mostly text-based). Perhaps the entrance policies could be maintained on-network (perhaps with "authority servers", with clients downloading the policies when they start up, rather than having them hard coded or configured client-side? Just some ideas. :) Best, -- Paritesh Boyeyoko parity.boy(a)gmail.com

2 2

Understanding Reduced Exit Policies..?
by Jeremy Olexa 13 Sep '14

13 Sep '14

Hello, I've setup a non-exit node so that I can contribute and understand the TOR network somewhat better. I've only had my node (jolexarelay1) up for a few weeks so it is still becoming a part of the network at guard status. So, as I understand my ISP, I can run an exit node if I "handle" abuse complaints to their standards. Now, since I have more idle bandwidth than idle time to "handle" complaints, I've often wondered about the reduced exit node strategy as seen at https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy - I'd like to allow ports in a methodical fashion such that I can test to see if a port generates complaints easily/quickly. My question: If I want to "try" being an exit node and add allowed exit ports slowly, does that help the network or not? For example, month 1: allow port 22, month 2: allow IRC ports, and so-on. How does the client path selection work in this case - is it smart enough to pick my exit when needed? Thanks for any insight, Jeremy

3 3

request at Hetzner
by Toralf Förster 13 Sep '14

13 Sep '14

3 things: 1. ========= This is what I get few days ago from Hetzer Support: >Guten Tag Herr Förster, > >laut Deutschem Recht sind Tor Server im Moment nicht verboten. >Aus diesem Grund sind Tor Server bei uns auch nicht verboten. >Aus Erfahrung raten wir jedoch vom Betrieb eines Tor Exit Node ab. >Leider wird oft ueber Tor Server Content verbreitet welcher laut >Deutschem Recht >nicht erlaubt ist. Dies kann Ermittlungen von Behoerden nach sich >ziehen. Maybe worth to update https://trac.torproject.org/projects/tor/wiki/doc/GoodBadISPs ? 2. ========= I'm planning to setup there a dedicated server now soon (with Gentoo Linux if possible) within next days - or are there too much servers already at the ISP Hetzner ? 3. ========= And for the following days I do want put the line "ExitPolicy reject *:*" before all subsequent liens like "ExitPolicy accept *:20-23 # FTP, SSH, telnet" of the reduced exit policy to just look how the system behaves as a simply relay. Worth or superflous ? Am I right, that later just commenting out that reject line enhance the Tor server from relay to "relay + exit node" ? Or does this mean that -- Toralf pgp key: 0076 E94E

6 9

What to change for v0.2.5.x?
by Steve Snyder 13 Sep '14

13 Sep '14

So now Tor v0.2.5.x Release Candidates are available. Can someone give an overview of what's new for those who don't follow the development process? What can/or should be changed in a working v0.2.4.x relay config to accommodate the changes made in the new code? Are there particular areas (IPv6, multi-threading, etc.) that one should be aware of when moving from v0.2.4 to v0.2.5? The changelogs do a great job of describing the changes between point releases but are somewhat overwhelming when attempting to determine the differences between major releases. If would be great if someone could give a brief(-ish) description of those changes. Thanks.

3 3

IPv6 - status
by Marcin Gondek 12 Sep '14

12 Sep '14

Hi, What is the current state of IPv6? ==cut== Relays to relays Relays talk to other relays. The work with relays talking to other relays over IPv6 has not been started. ==cut== Is there any plans to start? How I can help? ==cut== Directory authorities on IPv6 Clients and relays talk to directory authorities. The work with making directory authorities reachable over IPv6 has not been started. This work will be tracked in #6027. ==cut== Same as above? Clue is when it will be possible to run pure IPv6 relay/guard. Regards, -- Marcin Gondek / Drixter http://fido.e-utp.net/ AS56662

3 4

Re: [tor-relays] boost CPU on a Tor relay
by Harold Naparst 09 Sep '14

09 Sep '14

I'll just throw in my datapoint on this subject because it might be of interest. My relay (torpoint) is currently advertising a bandwidth of 58 MB/s according to Globe. Arm reports that it is pushing 50 MB/s and has 12,500 open clients. It has a Xeon E3/1220 with 8 GB ram. The load average is 0.75, and the four cores are at about 20-25% each. About 2GB of ram is being used. On the whole, this relay is probably bandwidth constrained. The ISP guarantees 150 Mbps, but I sometimes get more, like now.

1 0

Gentoo overlay
by Harold Naparst 09 Sep '14

09 Sep '14

Sorry Jeremy, I didn't realize you were a Gentoo dev. I have added the comment to the Gentoo bug discussion per your wishes.

1 0

Re: [tor-relays] enable-ec_nistp_64_gcc_128
by Harold Naparst 09 Sep '14

09 Sep '14

I thought about this also, but I decided not to do it. Gentoo has clearly decided not to include the Elliptic Curve algorithms until they can get confirmation that it works on all archs. Funtoo has taken the opposite position. >From the looks of the Gentoo thread, they should add the flag in the near future, and I think it would be more diplomatic to just let the process play out. My hope is that a Google search would lead most people to this post. I just created the ebuild in my overlay because I wanted it now and I thought some other enthusiasts would also want it now. I hope it works for you, and would be interested if it makes a difference. > Thanks for your contribution, can you also add some note to the > underlying bug report https://bugs.gentoo.org/469976 so others may see > it easier? > -Jeremy > On Mon, Sep 8, 2014 at 2:52 PM, Harold Naparst <harold(a)alum.mit.edu> wrote: >> If you want a version of openssl compiled with the >> enable-ec_nistp_64_gcc_128 option and you are using Gentoo Linux, >> you can grab it from my overlay:

1 0

enable-ec_nistp_64_gcc_128
by Harold Naparst 09 Sep '14

09 Sep '14

If you want a version of openssl compiled with the enable-ec_nistp_64_gcc_128 option and you are using Gentoo Linux, you can grab it from my overlay: layman -f layman -a hnaparst emerge openssl The new flag "nist" is turned on by default. I have 1.0.1i and 1.0.2_beta2 in the overlay. Hope it helps.

2 1