Re: [tor-relays] How to use our own TOR relay as entry node for local network hosts

> Date: Sun, 24 May 2015 08:47:20 +1000 > From: Zenaan Harkness > >> 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 y

Re: [tor-relays] Multi-core Support

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. -12xBTM On 1.6.15 9:11, Tor-Admin wrote: ---

Re: [tor-relays] Auto-detect and enable IPv6 // Re: Please enable IPv6 on your relay!

> Date: Fri, 22 May 2015 19:29:43 +0500 > From: Roman Mamedov > > On Fri, 22 May 2015 13:31:02 + > Speak Freely 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

Re: [tor-relays] Multi-core Support

On Tue, 02 Jun 2015 11:13:13 -0400 12xBTM <12x...@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

[tor-relays] Improving Node Connection Testing

This is a little write-up on the quality of data connections involving nodes, and some thoughts on that. So, as of today, the quality of nodes is determined by their bandwidth, uptime, and not being malicious. There are two major missing factors from this, and I wanted to bounce some ideas arou

Re: [tor-relays] Improving Node Connection Testing

> > Date: Tue, 02 Jun 2015 11:58:25 -0400 > From: 12xBTM <12x...@gmail.com> > > This is a little write-up on the quality of data connections involving > nodes, and some thoughts on that. So, as of today, the quality of nodes > is determined by their bandwidth, uptime, and not being malicious. The

Re: [tor-relays] Multi-core Support

> Date: Tue, 2 Jun 2015 20:31:56 +0500 > From: Roman Mamedov > > On Tue, 02 Jun 2015 11:13:13 -0400 > 12xBTM <12x...@gmail.com> wrote: > >> Improving multi-core support can allow users to saturate high bandwidth >> connections with cheaper processors, less setup, and just more efficient >> depl

Re: [tor-relays] Multi-core Support

> 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 > m

Re: [tor-relays] Improving Node Connection Testing

I once ran a node on a college network for just a few weeks. Then I found out at peak hours, packet loss was >90%. My measured bandwidth never reflected that. Now, scale that up. An enemy makes a ton of nodes like that, and now has a large portion of circuit going through them. That will crippl

[tor-relays] Fwd: Re: Multi-core Support

Forwarded Message Subject:Re: [tor-relays] Multi-core Support Date: Tue, 02 Jun 2015 11:55:31 -0400 From: 12xBTM <12x...@gmail.com> To: Roman Mamedov Some multicore support (at least 4 cores) should be a priority. Going beyond doesn't cater to many node ope

[tor-relays] IPv6 slows BW?

I have two relays that I set up last night to test. They're at the same datacenter, same spec server, and configured identically. The only difference is one is set up for IPv6 and the other isn't. With IPv6 BW is at: 75kB/s Without IPv6 BW is: 110kB/s Is this normal behavior or has anyone else e

Re: [tor-relays] IPv6 slows BW?

On 06/02/2015 07:31 PM, torelay wrote: > I have two relays that I set up last night to test. They're at the same > datacenter, same spec server, and configured identically. The only > difference is one is set up for IPv6 and the other isn't. > With IPv6 BW is at: 75kB/s > Without IPv6 BW is: 110kB/

Re: [tor-relays] Improving Node Connection Testing

(Ugghhh, top posting. /rant) > On 2.6.15 12:26, teor wrote: > >> Date: Tue, 02 Jun 2015 11:58:25 -0400 > >> From: 12xBTM <12x...@gmail.com> > >> > > Since, as far as I know, Tor connections are in-order delivery, > > dropping packets will cause retransmits, and back up (parts of) the > > trans

Re: [tor-relays] Bridge Usage and Setup

Hello everyone, I'm new here. So just wondering: why would IPv6-to-IPv4 tunnel providers like HE enjoy having extra loads of traffic for no extra profit? Or, perhaps, I'm missing somehing... On 1 червня 2015 р. 20:14:53 GMT+02:00, Steve Snyder wrote: > > >On Monday, June 1, 2015 1:28pm, "Rom

[tor-relays] Updated: Running Tor When OS X Boots

I've recently updated the OS X launchd instructions for OS X Yosemite: https://trac.torproject.org/projects/tor/wiki/doc/MacRunOnBoot They were starting to show their age - they were originally written in 2011, and were based on V

Re: [tor-relays] Bridge Usage and Setup

* Tom Ritter schrieb am 2015-06-01 um 18:34 Uhr: > Earlier this month I set up an obfs3/obfs4 bridge that (as far as I > can tell) has never been used. Is this normal? My bridge is at I'm running several bridges (plus obfs3, obfs4 and other PTs). However most of them are never used (something lik

Re: [tor-relays] tor network "loses" ~50 relays/day due to bw auth problem

Hi all, thanks for your answer and the point to the BwAuth specs, Tom - I’ll definitely get into that, or at least try to. The proposal sounds interesting and I think it would be a good thing to have the whole voting mechanism a bit more transparent. But I guess that might not happen in the ne

Re: [tor-relays] tor network "loses" ~50 relays/day due to bw auth problem

On Mon, Jun 01, 2015 at 11:02:53AM -0500, Tom Ritter wrote: > Hrm. So this gets into the inner workings of the bwauth system which > is... complicated.[0] Honestly, I'm not actually sure how the > individual data from the different bwauths is combined into a single > value for the consensus. The