- tor-relays - lists.torproject.org

Multithreading progress
by Sebastian Urbach 22 Sep '14

22 Sep '14

Dear list members, I asked Mikhail Belous for a quick status update regarding the multithread feature for the tor-daemon. Here's what he said: Good news: My version of multi-thread tor passes the test and doesn't shows mem racing problems. Bad news: 1)Processing channel is only big enough operation to be paralysed. Tor daemon uses a lot of global variables that should be locked. I have already done this for some resources. 2) Multithread branch is behind master for over 1000 commits. What should be done before release: 1) Merge master in better_workqueue branch. 2) Find all global resources, that are available from command_proccess_cells. I already sent you a list, but it should be checked. 3) Lock all global resources. 4) Code review 5) Compare performance of one thread and multi-thread daemons. -- 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! -----------------------------------------

1 0

exit relay not receiving flag
by jason＠icetor.is 22 Sep '14

22 Sep '14

Hey All, I'm a bit embarassed here but I don't see what I'm doing wrong. I've recently inherited a VPS donation from an anonymous donor. I've configured it up like the rest of Icetor's exit relays but it never receives the exit flag. The exit in question is loki4: https://atlas.torproject.org/#details/44DB05F3AEDA5DA34BC713201DD0394418C7D… An external Nmap scan of the IP shows the DirPort and ORPort open and accessible, so what gives? -Jason

3 3

Re: [tor-relays] Mac OS X configuration problem(s)
by Tim 21 Sep '14

21 Sep '14

On 21 Sep 2014, at 22:00 , Surf Norway <surfnorway(a)gmail.com> wrote: > > I've installed the tor package via homebrew, and cofigured > /usr/local/etc/tor/torrc according to the documentation. > > My problem is that every time I try to use launchctl I get an error, > both as an admin user and via sudo. > > As an admin user: > > Could not open job overrides database at: > /private/var/db/launchd.db/com.apple.launchd.peruser.502/overrides.plist: > 13: Permission denied > launch_msg(): Socket is not connected > > When run via sudo it complains about "dubious owbership on file" and > says "nothing found to load". > > I followed whatever documentation I could find. The torrc config is on > torproject.org under "configuring a relay graphically" (I know this > isn't graphically), the homebrew info is linked to in the same article > and looks to be from a mailing list discussion. > > I wanted to set up a simple relay to run automatically when the (OS X) > machine boots. It's a home server on a 30MB/sec symmetrical fiber > line. Since I run the machine as a file server anyway, I figured I > could allocate some bandwidth and help support the community. > > Thanks, > Surf Norway Hi Surf, A few pointers: 1. On OS X, launchctl has to be run as root/superuser in order to start system-wide services. You can do this using sudo. 2. launchd plist files can't be writable by anyone other than the superuser. If you've installed the tor launchd plist file as your admin user, it will have permissions based on your user, not root. You have a few options here: A. Disk Utility's "Fix Permissions" might automatically fix ownership for you, but it might also leave the file alone because it wasn't installed by the OS X Installer. B. You could try (re-)installing the launchd plist file as root using "sudo". This will make sure the owner is "root". C. Or you could use the "ls -l", "chown" and/or "chmod" commands in the Terminal to investigate and fix the ownership and permissions yourself. 3. It's hard to tell what torrc instructions you're following, but instructions for other platforms will require modifications. OS X launchd works differently to both Linux/BSD and Windows services. For example, you can't use "RunAsDaemon 1" on OS X, or launchd will think tor has crashed. A. You might want to try the OS X-specific instructions at: https://trac.torproject.org/projects/tor/wiki/doc/MacRunOnBoot By the way, if this is your first tor relay, and since it's at home, you probably want to run a relay with no exit ports open. And if you have multiple IPs, on its own IP. This is a much safer option than running an exit on a shared IP. If you're still having problems, can you please include URL(s) of the instructions you're following, copies of your torrc and launchd plist files, and the exact output from the launchctl and tor programs? This really helps us help you, because then we can see exactly what you're seeing. A final question: can you manually launch tor without using launchd? It sounds like you're not even getting to the point where launchd tries to run tor. But it can be helpful to make sure that tor will run without the added intermediary of launchd. T

1 0

obfs3 not recognised by tor 0.2.5.7-rc ?
by Nick Sheppard 20 Sep '14

20 Sep '14

I'm running tor 0.2.5.7-rc and obfsproxy 0.2.6, and everything seems to work perfectly with these PT lines in torrc: ServerTransportPlugin obfs2 exec /usr/bin/obfsproxy managed ExtORPort auto However, if I try to use obfs3 as well: ServerTransportPlugin obfs2, obfs3 exec /usr/bin/obfsproxy managed then on tor start I get: [warn] Strange ServerTransportPlugin type 'obfs3' [warn] Failed to parse/validate config: Invalid server transport line. I thought my versions would be recent enough to handle obfs3? Is this a bug, or am I missing something obvious? Nick Sheppard

2 3

Re: [tor-relays] Port-Based Best-Fit Circuit Selection
by Tim 20 Sep '14

20 Sep '14

[Edit: Convert to end-posting & fix quote levels] On 18 Sep 2014, at 10:40 , Paritesh Boyeyoko <parity.boy(a)gmail.com> wrote: > On Wednesday 17 Sep 2014 22:40:36 Tim wrote: > >> On 17 Sep 2014, at 22:00, Paritesh Boyeyoko <parity.boy(a)gmail.com> wrote: >> >>> On Tuesday 16 Sep 2014 17:36:41 Toralf F?rster wrote: >>> >>> On 09/16/2014 03:35 AM, Paritesh Boyeyoko wrote: >>> >>>> Hello -- >>>> 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? I >>>> >>>> >>>> Beside the general answer (probably "NO") - you mean something, which cannot be handled by a firewall ? >>>> >>> >>> >>> @Toralf Correct, this has nothing to do with firewalls. This is more about better utilisation of slow circuits/relays by deliberately choosing to push relatively lightweight traffic across them. IRC and XMPP do not need 10Mbit/s circuits, not even close. I'm not sure how Tor clients choose the relays they use to build a circuit, and I do realise that a) there are probably more slow relays than fast ones b) attempting to pre-build both a "fast circuit" and a "slow circuit" will reduce the number of candidates for each. I'm just looking for ways to drive more traffic across slow relays. :) >> >> >> >> Paritesh, >> >> >> I think it might help to make a distinction between latency (delay) and throughput (capacity), both of which are affected by router speed: >> >> >> IRC, XMMP and SSH need low latency circuits, which are mostly correlated with high bandwidth relays. >> >> >> Web Browsing (HTTP/S) and similar generally need both low-ish latency and high throughput, also correlated with high bandwidth relays. >> >> >> File Downloads (HTTP/S, BitTorrent) can cope with high latency as long as the throughput is high (and the reliability is sufficient, but that's another matter). >> >> >> But I can't actually see much need for high latency, low throughput relays - are there many protocols that would find that useful? (SMTP is the only one that comes to mind.) >> >> >> T > > > Hi Tim -- > > Very good points, and yes most likely the mail protocols would be candidates for "slow", high > latency circuits. > > However, there may be another class of relays that's overlooked - many VPS providers sell VPSes > with low data caps, even on fast connections (100Mbit/s). There are two ways to address this: > > a) traffic accounting: the relay hibernates until the next reset > b) throttling so that the data cap for the month isn't prematurely reached. > > I'd imagine that most relay operators with such VPS packages will choose to throttle and keep the > relay up and running continuously rather than having it hibernate (I know I've had to do this in the past). > The actual connection is fast enough to not suffer real latency issues, it's just the relay doing the throttling > - do you think throttling to 0.5Mbit/s or 1Mbit/s will create issues of high latency? > > I'm about to go and read the Conflux paper: > > "In this paper, we present Conflux, a dynamic traffic-splitting approach that assigns traffic to an overlay path > based on its measured latency. Because it enhances the load-balancing properties of the network, Conflux > considerably increases performance for clients using low-bandwidth bridges." > > This would obviously create better utilisation of circuits as a whole, so it may well make my idea totally redundant. :) > > Cheers, > > -- > Paritesh Boyeyoko Paritesh, For fast Tor relays with low data caps, the general advice is I've heard is two-fold: * enable AccountingMax, which will hibernate the router when the bandwidth is used up, and * disable directory caching to save (upload) bandwidth (AccountingMax does this automatically when it's configured) This means that the network has many fast routers each covering some of the day/week/month, rather than many slow routers for the entire month. (It also uses the entire bandwidth quota more efficiently - what if the calculated bandwidth limit is too low?) Tor seems to need more fast routers to reduce latency, because there is a long tail of slower routers which can provide significant capacity when needed. T

3 2

Torservers.net relays not updated yet?
by Nusenu 19 Sep '14

19 Sep '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi torservers, since you haven't updated most of your relays to address [1] released on 2014-07-28 yet, I was wondering if everything is ok? collective vacation? Since you are operating a significant chunk of the tor network's bw - timely patching is appreciated. The tor network is currently at 64% of the bandwidth being served by relays running a recommended version according to torstatus.blutmagie.de. I updated a previous metrics feature request so we might see nice graphs about patching progress in the future [2]. [1] https://lists.torproject.org/pipermail/tor-announce/2014-July/000094.html [2] https://trac.torproject.org/projects/tor/ticket/6856#comment:2 -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJT7+R/AAoJEDcK3SCCSvoeevcP/06Jg2ubrbbD+SKe32necCd2 OCp4auBI3M8LjxVwJMaMi1aBW81Y513shnghYvAVLRe8NCFuem0mnWfeZq6fjrqd kKvksRhCUo2ERK7covRaoVJ8Aqs37MDJh7B48v/FYcbQYbeRIw6+OUmysC6qMPvP gi+ReWFL77kW4hAK+05z6VeaBq6FfKA8L2FRF12ahtGokCO9BnPM1DijHnA4kLJG Fh2YxbWegd5wVna3PJrubjyJ5ANHM0L5pS0dPZZNobat7Sdrux7dhLo2VdHqZFT5 etykHjc18iJhm7z0r4qjYo58gEAx9CebTqdq2w22TBQFnXPaEt9oPktpdG1Q+Ba+ wPiOOBODyngqSUICD6LRGFq3L9Xa+1RrxORD+d+XmsrGhire+83BLkxDZ/JqUB0Z ZY4NEc13tTQqxPfqB6yQyU/XjTPl45zYWsaAxBjzX/AqoXgkwAQkBwdpFrUeu0O3 UiHe4DLhYtcoeOJjisqfl8t7xbyi5TduKfFH10Erglr3WX/OJ/Pau1N/tDtNqey8 GbrZSXVtv0ch7T31Cp6hYrZwxYnucUBcotcOX01+k158zpI5wv87WCwpc9ncDO3t Oj8ORAL/MbgtYh0JaE1wIP0zSuhhWY2Y+qzdXnTwoYMbfDNnLUjcgZzbZNOhEu+E Y3LfuCsT+DI5TpwIp6tK =FZKz -----END PGP SIGNATURE-----

3 9

RELAY_EARLY tor network update status (CVE-2014-5117)
by Nusenu 18 Sep '14

18 Sep '14

(if you are on the CC list of this email you are probably one of the tor relay operators running one of the 10 fastest vulnerable [CVE-2014-5117] relays on the tor network. Please upgrade your tor relay) > The tor network is currently at 64% of the bandwidth being served by > relays running a recommended version according to torstatus.blutmagie.de. > I updated a previous metrics feature request so we might see nice > graphs about patching progress in the future [2]. Since we are seeing active RELAY_EARLY attacks again (or new buggy tor implemantations) I was wondering what the current update stats look like. ~85%* of the tor network's bandwidth is provided by patched relays. (~66% 0.2.4.23, ~11% 0.2.5.6-alpha, ~7% 0.2.5.7-rc) *) according to data from torstatus.blutmagie.de 10 fastest relays still running a vulnerable version: https://atlas.torproject.org/#details/EC98311F9EC02BEAA183651CE8402249CD036… https://atlas.torproject.org/#details/D1271A1E15C568DA709D3A1E68188EEAE8DDB… https://atlas.torproject.org/#details/12AD30E5D25AA67F519780E2111E611A455FD… https://atlas.torproject.org/#details/1B9FACF25E17D26E307EA7CFA7D455B144B03… https://atlas.torproject.org/#details/2F57987F3942BA0BBD706D623F1FF86A89684… https://atlas.torproject.org/#details/379FB450010D17078B3766C2273303C358C3A… https://atlas.torproject.org/#details/935BABE2564F82016C19AEF63C0C40B5753BA… https://atlas.torproject.org/#details/B83DC1558F0D34353BB992EF93AFEAFDB226A… https://atlas.torproject.org/#details/104A9453FD93BDBEAE9E2024898266AD2051A… https://atlas.torproject.org/#details/C11650E31F83E149C855D574B3171CC9CF9BE…

3 2

Re: [tor-relays] BBC and UK Lottery blocking ip addresses running relay
by Dan Hanley 18 Sep '14

18 Sep '14

> > > I have just received a slightly more positive reply: "At present, our GeoIP data provider classes Tor nodes as proxies, regardless of whether or not they're an exit node. We understand that there is room for improvement in this model, since non-exit relays do not present traffic on behalf of other users. We have asked our provider to give us a way of differentiating Tor exit nodes from non-exit relays, to allow us to block exit nodes only." So perhaps they will make a change... certainly reporting the issue seems to raise its importance :-) atb Dan > 5. Re: BBC and UK Lottery blocking ip addresses running relay > nodes (Chris Whittleston) > ---------- Forwarded message ---------- > From: Chris Whittleston <csw34(a)cam.ac.uk> > To: tor-relays(a)lists.torproject.org > Cc: > Date: Thu, 18 Sep 2014 01:40:31 +0100 > Subject: Re: [tor-relays] BBC and UK Lottery blocking ip addresses running > relay nodes > Yeah ouch - maybe I just got someone a bit more helpful. I'm with Matt > though, it seems like they still don't get the difference between using Tor > as a client and running a relay, so this isn't the end of the road there. > You are going to have to rely on them wanting to actually think about it > though. > > If all else fails, you could always try to simply report the issue again > using the form I linked before, but this time just don't mention Tor at all > and see if you get a different customer service person... > > http://iplayerhelp.external.bbc.co.uk/tv/incorrect_location_may2014 > > I suspect you'll end up having to explain that you're running a relay in > the end anyway, but you never know. > > Chris > > On 17 September 2014 21:48, Matt Puckey <matt(a)puckey.org> wrote: > >> Stephen Mollett: >> > [...] >> > "Thank you for contacting the BBC iPlayer support team. >> > >> > "I understand you’re experiencing problems accessing BBC iPlayer as >> > you’re told that you are outside of the UK. >> > >> > "Please note that if you run TOR, then I’m afraid as per our development >> > team’s confirmation you’ll not be able to access BBC iPlayer. If you >> > continue to use TOR then your IP address may be blacklisted against UK >> > only services across bbc.co.uk." >> > >> > I made a point of stating explicitly in my original case filing that I >> > run a middle relay and that no traffic exits from my node to the BBC's >> > website or to anywhere else, along with a link to my node's stats on >> > blutmagie confirming the (non-)exit policy. >> > [...] >> >> Hi Stephen, >> >> I'm not sure whether I'm surprised at the BBC or not! >> >> It is a shame if they seem to be doing blanket blocking of Tor relay IP >> addresses. I suppose this >> ( >> https://blog.torproject.org/blog/call-arms-helping-internet-services-accept… >> ) >> has /some/ relevance. >> >> The problem is obviously convincing a organisation like the BBC to treat >> individual IP addresses different from other Tor relay IP addresses (and >> whether they should be doing that at all). Although it seems Chris >> Whittleston obviously managed it! Maybe you simply got 'the wrong person >> at the other end'. Personally, I would continue to pursue this with them! >> >> --Matt >> >> >> >> _______________________________________________ >> tor-relays mailing list >> tor-relays(a)lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> > > > > -- > *Dr Chris Whittleston 栗主* > Department of Chemistry > University of Cambridge > Lensfield Road, Cambridge, CB2 1EW > Email: csw34(a)cam.ac.uk > Tel: +44 (0)1223 336423 > > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > >

3 2

Where to report relay warnings
by Sebastian Urbach 18 Sep '14

18 Sep '14

Hi, I also found a lot of the mentioned log entries. The comment from Arma within the ticket is just right "Bonus points for using the name in the NSA document" Rofl :-) -- 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! -----------------------------------------

1 0

Where to report relay warnings
by Jens Müller 18 Sep '14

18 Sep '14

Hi there My relay logged the following warning this morning: Sep 18 04:52:58.387 [Warning] Received an inbound RELAY_EARLY cell on circuit 2147511747. Closing circuit. Please report this event, along with the following message. Sep 18 04:52:58.388 [Warning] upstream=85.159.214.57:9003 Now, I have checked the FAQs but didn't found any information where to report this, so I hope you can help me out. Thank you already and kind regards Jens

2 1