January 2014 - tor-relays - lists.torproject.org

running Tor relay live with AddressSanitizer
by starlight.2013q4＠binnacle.cx 28 Jun '14

28 Jun '14

Has anyone tried running a live relay with an image built using GCC 4.8 and -fsanitize=address? AddressSanitizer documentation says it should be no worse than about x4 on CPU and typically about x2, so it looks reasonable to try. I'm seeing peak CPU of about 7-8% of a 2.2GHz AMD core. I'd probably create a static build, with 'libevent' and 'tor' compiled using -fsanitize=address -O1 -fno-omit-frame-pointer -g per the Google documentation and 'libz' compiled normally since 'zlib' is stable and mature. Any thoughts or experience? Thanks

3 6

Need help to get TorDNSEL compiled
by BlueStar88 26 Jun '14

26 Jun '14

Hi there, today I've read about the outage at "check.torproject.org". Since my torcheck-service "torcheck.xenobite.eu" needs the underlying TorDNSEL feature I'm trying to get this to work on my host. Like this I won't need to query the TorDNSEL-part of "check.torproject.org" anymore. I'm not into programming and do not know anything about haskell, c++ and such. So be patient with me on such matters. ;-) I've DL'ed the code from the internet website mirror [2]. I've prepp'ed all the dependencies using lucid binary packages: ghc6 6.12.1-12 libghc6-mtl-dev 1.1.0.2-10 libghc6-network-dev 2.2.1.7-1 libghc6-time-dev 1.1.2.4-2 libghc6-hunit-dev 1.2.2.1-2 libssl-dev 0.9.8k-7ubuntu8.15 libghc6-stm-prof 2.1.1.2-5 libghc6-binary-prof 0.5.0.2-1 First error I got on compile attempt was: src/TorDNSEL/Main.hs:81:21: parse error on input `#' That was quite easy thought: import GHC.Prim (Addr#) I deleted the '#' hopefully making it correct this way. Next error is some numbers too high for me now: src/TorDNSEL/DeepSeq.hs:20:7: Could not find module `Data.ByteString': It is a member of the hidden package `bytestring-0.9.1.5'. Perhaps you need to add `bytestring' to the build-depends in your .cabal file. Use -v to see a list of the files searched for. The libghc6-bytestring-dev-0.9.1.5-125af ist installed by it's main package ghc6 6.12.1-12. Any ideas? Or are there some binary packages for TorDNSEL around, to make this more easy for me? :-P Thanks, BlueStar88 [1] https://blog.torproject.org/blog/tor-check-outage-03-and-04-july-2013 [2] https://www.torproject.org/tordnsel/dist/tordnsel-0.0.6.tar.gz

3 7

Any Tor/Linux coaches in Sydney?
by I 14 May '14

14 May '14

5 6

Setting up AWS cloud-relay - don't reserve expensive storage!
by Nick Sheppard 31 Mar '14

31 Mar '14

Hi all, I set up an AWS EC2 cloud Tor relay a month ago and made an expensive mistake. Perhaps others may learn from my example! I followed the instructions on the tor-project website, and found that it actually is quite a simple process, as it says. I did notice that the AWS setup screens I was seeing were different from the screenshots on the website, but they were asking me similar questions so I just went with the defaults where the website said "No changes". I didn't look closely enough. Everything went to plan and I watched the relay work for a month. However, on the AWS EC2 Management console I neglected to click on "Services" then "Billing" to see how much they were charging me. At the end of the month I got a bill for 120 dollars. And Amazon were quite right - they were charging me for the 1024 GB of storage I had accidentally asked for by not changing the default when I set up the instance. The first 30 GB were free, the other 994 I was paying for. And I was only actually using 1.5 GB ... There doesn't seem to be any way of shrinking the storage of an existing instance (though it can be expanded, now, with EBS, Elastic Block Storage), so I had to terminate it (which deletes the storage) and create another instance with a more reasonable 10 GB (of which df tells me I'm now using 11%). So ... if you've recently set up an AWS EC2 cloud relay with the Tor AMI, check your storage, and your billing! I think the option to specify your storage amount (with its default of 1024 GB) may have been introduced when AWS introduce EBS instead of just instance-backed storage (which may have defaulted to the size of the AMI??). In any case, I think the tor-project website AWS screenshots urgently need to be changed to reflect the current setup procedure, with a warning not to accept the 1024 GB default and an explicit recommendation about the amount of storage to ask for (was my guess of 10 GB reasonable?). Oh well, I have gained 100 dollars worth of wisdom from the episode. My way of "Don't look too closely, and hope for the best at the end of the month" was *not* a good idea. Nick Sheppard

7 20

(untrusted) Raspberry Pi binary .deb packages for Tor 0.2.4.18-rc
by Gordon Morehouse 06 Mar '14

06 Mar '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I've built Tor 0.2.4.18-rc for the Raspberry Pi and released unofficial packages[1]. They are signed with my GPG key, but as always, if you don't trust binary packages from some dude on the internet, please see the instructions to compile them for yourself[1]. 1. https://github.com/gordon-morehouse/cipollini/tree/master/raspbian_packages… 2. https://www.torproject.org/docs/debian.html.en#source Best, - -Gordon M. -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJSj5ghAAoJED/jpRoe7/ujpugIAL8U1aGVZQ4FSqCgRac0g4oW pqEGYT/aHI7GYX1J0ruS5kSjB7VGBqqskvb3LmWkSjMbJwX7MqTLbfUBj/wX8db8 sHTH/cdFNin3qazjrMnS0fe6bJ/AlimPcQSQfeEPQ3w5Wqk2Lb/qxVEY0cGxwYDn p6P4KItegJkWcT7pKHCcIkLcjUHjalS4N9xUOg0oFh1cXzA4YRrMbrmHuNuNYtOG OV09+56jlOJm6ApsYHNiDO/3lYB8xPnaMs8EbOVWUjBsh0kraTusXvNs9IquZEXd Pk83VhavdsiAmksz5u6q7+gVIXsBkwxTBlpybj5aWNOwze2D4DNe/eBKVzLTu2w= =7g1s -----END PGP SIGNATURE-----

2 1

Problem encountered with Bandwith Authority algorithm (was : "bandwidth authority algorithm is cracked")
by julien.robin28＠free.fr 04 Mar '14

04 Mar '14

Hi everybody, 15 days, 16 hours and 15 minutes (without any restart) have passed since my 2 involved in this problem are restarted (started at the same time). And there is something very clear and interesting to see. They both have restarted from nearly zero (~100kB/s) in the first days, and a problem is still completly present on 1 of the 2 identity : -> The first one (the older one also) is stuck at less than 1MB/sec (5,510 in consensus weight) - ArachnideFR94 -> The second one is growing, growing and growing, now around 9MB/sec (and more than 75,000 in the consensus weight) - ArachnideFR94v2 It can be very clearly seen by observing graph on Tor Atlas. (But there is no more bandwith earthquake like I had on december.) On this machine, the first daemon is launched by /etc/init.d, while the second one is manually lauched via another non-admin user. No differences, same nice value, completely the same torrc file apart from nickname, DirPort, ORPort and MyFamily. Pretty large max bandwith for both of them : RelayBandwidthRate 25600 KB RelayBandwidthBurst 122070 KB ShutdownWaitLength 90 -- Into the log file : The only one difference was this (I just corrected it) - it was on the server that is working perfectly fine (ArachnideFR94v2) : Jan 30 06:07:03.000 [warn] Failing because we have 4063 connections already. Please raise your ulimit -n. [6978 similar message(s) suppressed in last 21600 seconds] Jan 30 12:07:17.000 [warn] Failing because we have 4063 connections already. Please raise your ulimit -n. [20004 similar message(s) suppressed in last 21600 seconds] -> Oops :s I know very well this problem and I just forgot to prevent it this time - Sorry for that - Corrected by editing /etc/security/limits.conf and adding some lines about the user used by my second tor daemon - I just restarted this one by SIGINT, wait and new launch (logged with a much better ulimit !) today at 12:35 UTC. Absolutely nothing else abnormal into the log of the 2 daemons. And the problem of ulimit was on the one that runs perfectly well! -- Any idea of why the first one is completely stuck at such a low value ? The next steps would be to set the 2 tor daemons on the /etc/init.d using the Multiple Tor Processes example at www.torservers.net on this machine, and to watch if ArachnideFR94v2 launched by /etc/init.d is still working as well as today. If no solution appears, may be trying to re-install the entire system, and watch what happens would be interesting. If still no solutions, it will be complicated to understand ! Best regards, and thank you in advance for your ideas Julien ROBIN

1 1

Checking a bridge
by Martin Kepplinger 08 Feb '14

08 Feb '14

When my bridge uses only the same few MBs each day, i guess it isn't used at all right? Is there a simple way to ensure it is in bridgeDB and functioning as it should? thanks, martin

8 8

Tails 0.22.1~rc1
by K. Besig 31 Jan '14

31 Jan '14

Is anyone having luck setting up a mid-relay within the latest Tails build? I'm finding no joy..

3 3

Re: [tor-relays] Considering setting up an exit, need advice
by Jesse Victors 31 Jan '14

31 Jan '14

> Have you set AccountingMax in your torrc, by chance? > > Also, you sure are restarting the relay a lot. You should learn how to > use 'service reload' rather than 'service restart'. :) No, I don't have AccountingMax enabled, which is one of the reasons why I was puzzled by the hibernation flag. Thanks for the tips on the service, I should have known better. I was restarting often because I was making adjustments to the DirPort and the hosted webpage (that .png thumbnail never loaded when it was offered locally, so I just linked to the hosted one on torproject.org) and it took a few tries before things were working right. Well, at least I won't be restarting Tor frequently going forward. Thanks. >> 3) There are mysterious warnings in the log: >> >> Jan 30 23:07:29.000 [warn] EXTEND cell received, but not via >> RELAY_EARLY. Dropping. [4 similar message(s) suppressed in last 3600 >> seconds] >> Jan 30 23:07:29.000 [warn] (We have dropped 95.24% of all EXTEND cells >> for this reason) > You don't happen to have set "ProtocolWarnings 1" in your torrc, have you? > >> I'm familiar with the meaning of the "EXTEND" cell, but I'm not sure >> what RELAY_EARLY is > See > https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/110-avoid-in… > as motivated by > http://freehaven.net/anonbib/#congestion-longpaths > > My guess is that these are unofficial Tor clients you're seeing, and > you're seeing them more because all official Tor clients are ignoring > your relay until it gets out of 'phase one' (from the blog post). Yes, I had ProtocolWarnings enabled, good eyes there. I had it on because I thought that it would help me see Tor-level security threats, but I think it's better with it off at least for now. Thanks for the help. Jesse

1 0

Re: [tor-relays] Considering setting up an exit, need advice
by Jesse Victors 31 Jan '14

31 Jan '14

Thanks again guys for the help. "usuexit" is now online, and should be functioning properly, but there seem to be a few mystifying issues: 1) TorStatus marks it as "hibernating" which it clearly isn't; it's online and accepting connections. I'm not sure what made TorStatus think it was offline. 2) For the first nine hours it has moved about 12 MB of data. I would think it would be more than that, especially for an exit. There's a blog post outlining the growth rate for guards, but how about for exits? 3) There are mysterious warnings in the log: Jan 30 21:57:36.000 [notice] Circuit handshake stats since last time: 0/0 TAP, 50/50 NTor. Jan 30 22:57:36.000 [notice] Circuit handshake stats since last time: 0/0 TAP, 31/31 NTor. Jan 30 23:07:29.000 [warn] EXTEND cell received, but not via RELAY_EARLY. Dropping. [4 similar message(s) suppressed in last 3600 seconds] Jan 30 23:07:29.000 [warn] (We have dropped 95.24% of all EXTEND cells for this reason) Jan 30 23:57:36.000 [notice] Circuit handshake stats since last time: 0/0 TAP, 39/39 NTor. Jan 31 00:01:41.000 [warn] Got headers "HEAD / HTTP/1.0\r\n\r\n" with unknown command. Closing. Jan 31 00:57:36.000 [notice] Circuit handshake stats since last time: 2/2 TAP, 41/41 NTor. Jan 31 01:04:46.000 [warn] EXTEND cell received, but not via RELAY_EARLY. Dropping. Jan 31 01:04:46.000 [warn] (We have dropped 95.45% of all EXTEND cells for this reason) I'm familiar with the meaning of the "EXTEND" cell, but I'm not sure what RELAY_EARLY is, nor do I know what this warning means. If the relay has an exit policy, why are circuits being extended beyond it? Hidden services, maybe? Basically the log has more warnings in it than it should (at least based on my experience with regular relays) and I'm not sure why. I tried restarting Tor, but the warnings still appeared. Any ideas on what I can do about them, if anything? Thanks, Jesse

2 1