- tor-relays - lists.torproject.org

Fwd: Re: Multi-core Support
by 12xBTM 02 Jun '15

02 Jun '15

-------- Forwarded Message -------- Subject: Re: [tor-relays] Multi-core Support Date: Tue, 02 Jun 2015 11:55:31 -0400 From: 12xBTM <12xBTM(a)gmail.com> To: Roman Mamedov <rm(a)romanrm.net> Some multicore support (at least 4 cores) should be a priority. Going beyond doesn't cater to many node operators at this time. Don't quote me on the numbers, but having decent 4-core support would let someone run a node with the same bandwidth on an Atom/i5 that currently runs on one thread of a Xeon. Or, if someone has a Xeon, such as a collocation center, would let them fully utilize the processor they are paying for, which would be a good morale boost for node operators. But, honestly, the very minimum that can be done to improve the situation (which I know is being worked on as of 0.2.7) is improving a 2-thread program, to further utilize 2 threads of a cpu. That way, we can get by with 2 processes on one 4-thread CPU, instead of being tempted to jumped to 4 processes. On 2.6.15 11:31, Roman Mamedov wrote: > On Tue, 02 Jun 2015 11:13:13 -0400 > 12xBTM <12xbtm(a)gmail.com> wrote: > >> Improving multi-core support can allow users to saturate high bandwidth >> connections with cheaper processors, less setup, and just more efficient >> deployment of high-capacity nodes in general. Improving multi-core >> support should be a major priority. > Sure but I doubt anyone contests that it's better to have multicore support, > than to not have it. However that work doesn't get automatically done. > > One quick and simple stop-gap alternative that I suggested some time ago would > be to stop ignoring more than two relays per IP address. > > With the IPv4 shortage and abundance of multi-core CPUs, raising that limit to > let's say 4, would at least allow many people to run a Tor process per core on > the same single IPv4 that they have (utilizing up to four cores, not just two). > > Considering that Tor is already somewhat multi-threaded (each process can use > up to "120-130%" CPU), that might be just enough in most circumstances, since > true 6-8-core CPUs are rare, and what's seen more often beyond 4 cores is > either Intel HT or AMD's "light" core technologies. > > Of course the management (and memory) overhead of multiple processes is still > there, so proper multi-core scaling is the ideal final goal. >

1 0

Re: [tor-relays] Multi-core Support
by teor 02 Jun '15

02 Jun '15

> Thomas White: > Have there been any updated ETAs concerning the development/support > of multi-core for the core tor workloads? If not, is there anything > in particular that I could do to speed the process up? Scaling the > capabilities of the Tor process would be a huge relief and help for > my upcoming project so I am keen to push it through should it be > possible to bring up the priority list. t T > > On 1.6.15 9:11, Tor-Admin wrote: > I have to agree with that, multicore support is really important and > should be on the top of the priority list. > > On Tue, 02 Jun 2015 11:13:13 -0400 > 12xBTM <12xbtm(a)gmail.com> wrote: > Improving multi-core support can allow users to saturate high bandwidth > connections with cheaper processors, less setup, and just more efficient > deployment of high-capacity nodes in general. Improving multi-core > support should be a major priority. > > Date: Tue, 2 Jun 2015 20:31:56 +0500 > From: Roman Mamedov <rm(a)romanrm.net> > Sure but I doubt anyone contests that it's better to have multicore support, > than to not have it. However that work doesn't get automatically done. The work is currently listed in Trac in: https://trac.torproject.org/projects/tor/ticket/1749 https://trac.torproject.org/projects/tor/ticket/7572 teor teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7

1 0

Re: [tor-relays] Multi-core Support
by teor 02 Jun '15

02 Jun '15

> Date: Tue, 2 Jun 2015 20:31:56 +0500 > From: Roman Mamedov <rm(a)romanrm.net> > > On Tue, 02 Jun 2015 11:13:13 -0400 > 12xBTM <12xbtm(a)gmail.com> wrote: > >> Improving multi-core support can allow users to saturate high bandwidth >> connections with cheaper processors, less setup, and just more efficient >> deployment of high-capacity nodes in general. Improving multi-core >> support should be a major priority. > > Sure but I doubt anyone contests that it's better to have multicore support, > than to not have it. However that work doesn't get automatically done. > > One quick and simple stop-gap alternative that I suggested some time ago would > be to stop ignoring more than two relays per IP address. > > With the IPv4 shortage and abundance of multi-core CPUs, raising that limit to > let's say 4, would at least allow many people to run a Tor process per core on > the same single IPv4 that they have (utilizing up to four cores, not just two). This was suggested in https://trac.torproject.org/projects/tor/ticket/13414 But the concern was that any increase to 2 relays per IP would make it much easier for sybil attacks. Perhaps we could try an increase to 3 or 4 per IP? teor teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7

1 0

Multi-core Support
by Thomas White 02 Jun '15

02 Jun '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Have there been any updated ETAs concerning the development/support of multi-core for the core tor workloads? If not, is there anything in particular that I could do to speed the process up? Scaling the capabilities of the Tor process would be a huge relief and help for my upcoming project so I am keen to push it through should it be possible to bring up the priority list. t T - -- Activist, anarchist and a bit of a dreamer. Keybase: https://keybase.io/thomaswhite PGP Keys: https://www.thecthulhu.com/pgp-keys/ Current Fingerprint: BA81 407C BD61 CD15 E5D9 ADA9 5FA2 426F F34E 0FD4 Master Fingerprint: DDEF AB9B 1962 5D09 4264 2558 1F23 39B7 EF10 09F0 Twitter: @CthulhuSec XMPP: thecthulhu at jabber.ccc.de XMPP-OTR: 77E6C8C6 95FDE863 1172A1E1 8C114C01 691398AC -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVbFLfAAoJEF+iQm/zTg/UxTgP/2iB0gqd1R/h7ME6Zq6DQubM elmg7rtquh9H0NfTJ6/l5y2Y5ipLLZiN9dda+NxAl3RMD0ge0lwawoS8JjVcTsOP p+umbSJi2cy5/d2YWJXqLukLH6KITdza+5d5BMGZvOV9MkQNuPBXpQj9m0QH8lti K4zWH9bNEDWp9w+EHJSz5FcqwvpWhEPYipYdnBUEUO4lfaUlOJOfdHyrktrjD70b jIsz+OaFn7RyV85yMbpfMBH4TvSrdbhpshUKqy5TOPGww2Uupsf2EbAK3jYyelFA ZhENY8c0h39WNtamPImxsrN4dvyrKNt9SXGlGPoVZVCYvNH0/8/2MEPtdr9xYt3+ ntarnmDFi5+nqUHlzYn8flJv7h4o01CCNaueirE3IQJr7RC5sYBIIY38+ejO0sXq 4iAXraB2YeOhRvOLDrMMdAQP+6811/1bgH4tSNHV1XxW4BQJAjPxi5KSLe/+13S1 MaVoBvpxURT2O/QFQN8SOKKv5IY0/i78jEOjQpKgdvXMRxlpgycEpMKSRupBntZR OGFof1Hu22IYH6SGwnTBPeM+6Y7VV5VnX2fbPtMEH02Lplok3RZPciAXWtkhQGBn PN1TxLOm6NUtkwc8hEPulHDBamLLKNbQqAbdNfd7G0Bia7KBPQ1WM37FFTHyqaPz 7L4JuvUJ6iHLFob2CQAj =1DfQ -----END PGP SIGNATURE-----

4 4

Re: [tor-relays] Auto-detect and enable IPv6 // Re: Please enable IPv6 on your relay!
by teor 02 Jun '15

02 Jun '15

> Date: Fri, 22 May 2015 19:29:43 +0500 > From: Roman Mamedov <rm(a)romanrm.net> > > On Fri, 22 May 2015 13:31:02 +0000 > Speak Freely <when2plus2is5(a)riseup.net> wrote: > > > Uhh, I would like to point out that it would be exceptionally stupid > > to have Tor autoconfigure IP addresses, regardless of whether it's > > IPv4 or IPv6. > > On IPv4 it currently does. There is zero rationale as to why IPv6 must be > different from IPv4 in this aspect. IP address autodetection is a useful feature for those servers which are dynamically assigned IP addresses. But it's not appropriate in every circumstance, which is why the ORPort and DirPort config options allow an IP address to be specified. It's only in the absence of a configured IP that autodetection is performed. Here are the enhancement requests in trac that need to be completed for IPv6 address autodetection: The enhancement request for Tor autodetecting IPv6 addresses is here: https://trac.torproject.org/projects/tor/ticket/5940 Since Tor normally autodetects its IPv4 address via its first directory request, this requires the directory authorities and/or fallback directories to be on IPv6 answering directory requests: Directory Authorities on IPv6 https://trac.torproject.org/projects/tor/ticket/6027 Fallback Directories on IPv6 https://trac.torproject.org/projects/tor/ticket/8374 Fallback Directories Initial Release on IPv4/IPv6 https://trac.torproject.org/projects/tor/ticket/15775 Clients/Relays will also need to query directory servers on both IPv4 and IPv6 to autoconfigure both addresses. Currently, directory requests are only made using the default IP protocol, or IPv4 (I'm not sure which). Once these client and server changes are in place, we then need to test clients to ensure they will bootstrap correctly: * When clients are on IPv4 only, mixed IPv4/IPv6, and IPv6 only; (3) Combined with: * On first run and subsequent runs; (2) Combined with: * When the directory authorities are available on IPv4 only, IPv4/IPv6, and IPv6 only; * When the directory authorities aren't available, and Fallback Directories are available on IPv4 only, IPv4/IPv6, and IPv6 only; (6) Combined with: * Using HTTP (DirPort) and Tunneled (ORPort) directory fetches. (2) 4 4/6 6 a4 Y Y f a4/6 Y Y Y a6 f Y Y f4 Y Y N f4/6 Y Y Y f6 N Y Y Y = Yes, Tor should bootstrap f = Tor should use other authorities or fallback directories with matching IP version(s) N = Tor should fail to bootstrap if it doesn't have access to any directories with matching IP version(s), and it doesn't have a recent consensus. Otherwise, it should find a directory with a matching IP version. This may involve a tunneled directory request if DirPorts are not available but ORPorts are, and Tor has enough information to tunnel over an ORPort (this might not apply in the first run case). That's a lot of different combinations that we need to test and ensure they work as intended. And I am concerned about the complexity of the "N" case. We'd appreciate any help on these IPv6 enhancements, particularly coding the server-side changes, as it's difficult to code and test the client-side changes without them. teor teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7

1 0

Re: [tor-relays] How to use our own TOR relay as entry node for local network hosts
by teor 02 Jun '15

02 Jun '15

> Date: Sun, 24 May 2015 08:47:20 +1000 > From: Zenaan Harkness <zen(a)freedbms.net> > >> 3. Disable the polipo proxy on the Tor relay in your network, you do >> not need that. Run a bridge instead of a relay. Make it a non public >> bride (PublishServerDescriptor 0) and run Tor Browser on all the >> computers in your network with UseBridges 1 and define the ip:port of >> your bridge and connect it directly, no proxy setting. This way other >> 'strangers' won't be able to use your bridge and you will also not >> need the Guard flag or uptime and bandwidth requirements. > > That last bit (UseBridges 1, configure bridge IP), looks like it does > the job needed here, no new Tor config options required. There are 3 different ways to set up your local bridge, each with their own pros and cons: 1. Configure a private bridge * Only your clients use this bridge * No cover traffic 2. Configure a bridge distributed by BridgeDB * Your clients and other clients may use your bridge as the first hop * BridgeDB doesn't distribute all bridges straight away, so you may or may not get cover traffic * You can't separately rate limit external and local traffic at the bridge itself - RelayBandwidthRate includes all bridge traffic 3. Configure the server as a relay, but configure the clients to connect to it as a bridge * If you configure a client with a mandatory guard relay using EntryNodes and StrictNodes, the relay must have and maintain the guard flag. But configuring clients with a relay server in a "bridge" config line avoids the need for a guard flag. * Your clients use this bridge, as do other clients as at least a middle hop, and a guard or exit hop depending on flags * You get the most cover traffic this way * You can't separately rate limit external and local traffic at the bridge itself - RelayBandwidthRate includes all relay and bridge traffic * This mode of operation is less common, and may reveal some bugs in Tor. In my experience it has worked fine for months with 0.2.5 - 0.2.7-alpha, but please report any issues on https://trac.torproject.org/projects/tor/ticket/1776 * As a precaution, if you ever reconfigure a relay Tor node as a bridge Tor node, please delete the keys so it appears as a new bridge in BridgeDB. teor teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7

1 0

IPv6 adress valid?
by tor-server-creator＠use.startmail.com 01 Jun '15

01 Jun '15

hi, is that IPv6 adress valid for example "becks" [2a01:4f8:162:7345::2]? how do i know if IPv6 is correct and reachable? thanks

4 3

[warn] Problem bootstrapping. Stuck at 10%: Finishing handshake with directory server.
by Martin Ekendahl 29 May '15

29 May '15

This morning I rebooted my relay after some patching. I was running 2.6.7 on Ubuntu 14.04.2 LTS from. The server is always a bit slow rebooting but when it came back up always check the Tor relay and now I see an excessive amount of these errors: May 29 12:20:36.000 [warn] Problem bootstrapping. Stuck at 10%: Finishing handshake with directory server. (DONE; DONE; count 906; recommendation warn; host CC23B32FA040945FF49D94AC3D4334429CB4E2CD at 62.75.241.71:1110) May 29 12:20:36.000 [warn] 905 connections have failed: May 29 12:20:36.000 [warn] 849 connections died in state connect()ing with SSL state (No SSL object) May 29 12:20:36.000 [warn] 42 connections died in state handshaking (TLS) with SSL state unknown state in HANDSHAKE May 29 12:20:36.000 [warn] 8 connections died in state handshaking (Tor, v3 handshake) with SSL state SSL negotiation finished successfully in OPEN May 29 12:20:36.000 [warn] 2 connections died in state handshaking (TLS) with SSL state SSL negotiation finished successfully in OPEN May 29 12:20:36.000 [warn] 2 connections died in state handshaking (TLS) with SSL state SSLv3 read server hello B in HANDSHAKE May 29 12:20:36.000 [warn] 1 connections died in state handshaking (TLS) with SSL state SSLv3 read finished A in HANDSHAKE May 29 12:20:36.000 [warn] 1 connections died in state handshaking (Tor, v3 handshake) with SSL state SSL negotiation finished successfully in CLOSED I still see about 7000 inbound connections and 3000 outbound, I'm not sure what my connection average is, but the current bandwidth being used is below average (from the reboot). There have been a couple DDOS alerts from my ISP the past couple days, something I never used to get. I can confirm via my dashboard nothing has been mitigated so I assume no filtering is going on, and traffic is still coming and going, but for some reason there are a lot of connections not being made it appears from the logs, and these only started appearing after I restarted my server/relay. Any ideas what would be causing all these issues?

1 0

Get bridge
by Victor Victoe 28 May '15

28 May '15

2 1

Re: [tor-relays] Leaseweb exit relay notice
by tor＠t-3.net 25 May '15

25 May '15

On 05/25/2015 08:17 PM, Rejo Zenger wrote: > ++ 25/05/15 12:48 -0400 - tor(a)t-3.net: >> >> A lot of trouble would be prevented for exit node operators if, when they >> brought their relays up for the first time, they ensured that the exit policy >> rejected port 25. Even if they desire to run as unrestricted a relay as >> possible, in my experience, that one really should be rejected. It is the > > Some (or most or even all) of the Leaseweb nodes didn't forward port 25. > So, alltough you advice is a good one, it's not applicable to some (or > most or even all) of the nodes that are discussed in this thread. > I'd be curious to know what this checker says about the IP address that ultimately got this ISPs attention: http://mxtoolbox.com/blacklists.aspx I run 2 fast exits with only ports 25 and 465 rejected. I find that the IPs are in some expected lists that target Tor, plus barracuda and spamhaus-zen. But not a gigantic pile of RBLs like was being described. No sorbs, no spamcop, no uceprotect. Nothing like a real spamming box. Doing nothing on email ports but still ending up on a meaningful number of RBLs doesn't sound right. Maybe all it took to piss the ISP off was for one of them to do it.

2 1