- tor-relays - lists.torproject.org

Tor metrics regarding bridges running transports
by Jan Nielsen 07 Oct '14

07 Oct '14

Hi all. I was wondering if these metrics exist? I couldn't find anything on tor metrics. They list the amount of users using transports but there is no information regarding the number of bridges running particular pluggable transports.

2 1

My relay hibernated unexpectedly
by Derric Atzrott 07 Oct '14

07 Oct '14

Hello all, I recently set up the relay zelltor. I just got a notification that it went down about 10 hours ago. From what I can tell it looks like it decided to hibernate and that it will be hibernating for the rest of the month. I think I may have configured something wrong because this was rather unexpected. I want it to hibernate at a certain point, but I do not think its reached that threshold yet. Arm tells me: Accounting (hard) 15 MB / 250 GB 598 KB / 250 GB Time to reset: 31:02:20:23 I have the following configured in torrc: AccountingMax: 250 GB AccountingStart: month 3 15:00 Tor's log files: [notice] Configured hibernation. This interval began 2014-10-03 15:00:00; the scheduled wake-up time is 2014-10-03 15:00:00; we expect to exhaust our quota for this interval around 2014-11-03 15:00:00 (all times local) [notice] Commencing hibernation. We will wake up at 2014-10-03 15:00:00 local time. [notice] Heartbeat: Tor's uptime is 3 days 12:00 hours, with 0 circuits open. I've sent 6.08 GB and received 6.08 GB. We are currently hibernating. [notice] TLS write overhead: 6% [notice] Circuit handshake stats since last time: 2039/2039 TAP, 753/753 NTor. [warn] eventdns: Address mismatch on received DNS packet. Apparent source was 216.69.185.43:53 [notice] Heartbeat: Tor's uptime is 3 days 18:00 hours, with 0 circuits open. I've sent 6.08 GB and received 6.08 GB. We are currently hibernating. [notice] TLS write overhead: 6% [notice] New control connection opened. Note: I stripped the timestamps out because I am viewing these on a different computer and had to retype them. My ISP caps me at 500 GB up+down data per month, which is why I've capped it at 250 GB. I was planning to adjust that down a little bit as needed when my next month's bill came in and I got to see how much overhead Tor produces above the 500 GB cpa. Clearly I've come nowhere close to that though, so I don't think my node should be hibernating yet... Any ideas? Thank you, Derric Atzrott

4 4

Arch Linux packages?
by Eric Hocking 05 Oct '14

05 Oct '14

Hi all, I looked through the Arch Linux repository, and wasn’t able to find any packages for Tor or arm. Does anyone use archlinux that could create a package for Tor and arm?

3 2

French Flag
by Sebastian Urbach 02 Oct '14

02 Oct '14

Hi, I saw that a lot of services around tor are using a bright blue in the french flag. It should be a dark blue like the one used in the Dutch flag for example ... The following services are concerned: Atlas Globe Compass Oniontip (already fixed, thanks Donncha) If there are more services around that i don't know about then i would like to ask if someone could check them as well. It hurts a bit to see the Tricolore like that ... 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! -----------------------------------------

1 0

Re: [tor-relays] scramblesuit
by Jan Nielsen 02 Oct '14

02 Oct '14

When I restart tor with that option enabled I get: " 2014-10-02 00:52:38,199 [WARNING] Obfsproxy (version: 0.2.3) starting up. 2014-10-02 00:52:38,199 [INFO] Entering server managed-mode. 2014-10-02 00:52:38,200 [INFO] No transports launched. Nothing to do." I noticed it says version 0.2.3 starting up. $obfsproxy --version gives me O.2.12 Why is tor starting the old version? This must be the reason it is not working since scramblesuit was only rolled into obfsproxy in version 0.2.6 . How do I get $sudo service tor start To start obfsproxy v0.2.12? On Oct 1, 2014 5:43 PM, <tor-relays-request(a)lists.torproject.org> wrote: Send tor-relays mailing list submissions to tor-relays(a)lists.torproject.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays or, via email, send a message with subject or body 'help' to tor-relays-request(a)lists.torproject.org You can reach the person managing the list at tor-relays-owner(a)lists.torproject.org When replying, please edit your Subject line so it is more specific than "Re: Contents of tor-relays digest..." Today's Topics: 1. tor-relays (top mail) 2. tor-relays mailing list submissions (top mail) 3. Re: Bandwidth not being used by Tor on Gigabit dedicated server (Jon Daniels) 4. Re: Scramblesuit (isis) ---------- Forwarded message ---------- From: top mail <tpmail(a)safe-mail.net> To: tor-relays(a)lists.torproject.org Cc: Date: Wed, 1 Oct 2014 08:49:53 -0400 Subject: [tor-relays] tor-relays tor-relays ---------- Forwarded message ---------- From: top mail <tpmail(a)safe-mail.net> To: tor-relays(a)lists.torproject.org Cc: Date: Wed, 1 Oct 2014 08:50:49 -0400 Subject: [tor-relays] tor-relays mailing list submissions tor-relays mailing list submissions ---------- Forwarded message ---------- From: Jon Daniels <apexio(a)gmail.com> To: tor-relays(a)lists.torproject.org Cc: Date: Wed, 1 Oct 2014 07:30:37 -0700 Subject: Re: [tor-relays] Bandwidth not being used by Tor on Gigabit dedicated server Thank you for the reply. I have already (months ago) configured the max file limit to be 795552. Perhaps I'll try running more instances... On Tue, Sep 30, 2014 at 11:46 AM, Tom van der Woerdt <info(a)tvdw.eu> wrote: > I've often found my servers accidentally bottlenecked by the default open > file limit on some Linuxes. For example, on CentOS 6 this is 4096, which > for an exit node tends to mean ~50Mbit/s per process. > > A single process will not saturate 1Gbit/s. Judging by the hardware > (AES-NI support) you will need 3 or 4 instances running simultaneously to > max the link. > > Tom > > > > s7r schreef op 30/09/14 20:31: > > -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> It has nothing to do with the location (US). There are fewer US exit >> relays than other countries in Europe. >> >> Check the CPU usage too, usually CPU is the bottleneck on high port >> speed servers. Tor does not know yet how to do multithreading. >> >> Do you have AES-NI hardware acceleration at your CPU? This is very >> helpful too. >> >> Install htop (yum -y install htop) and it will tell you exactly how >> much each core is used. Let us know. I see that you confirm CPU load >> is not the fault, but probably you are checking it via a tool which is >> reporting the usage for ALL CPU (all cores) - try with htop and see if >> there is just one core @ 98% usage and others at less than 10%. >> >> If the CPU is not the bottleneck, there is something at your provider >> (probably throttling Tor traffic to balance the other non-tor users in >> the same datacenter). If you built the network infrastructure there >> and know for sure such thing is not implemented there, don't really >> know what to say. CPU / RAM and Network interface is all you can test >> to see if it is the bottleneck for Tor. If all these are off the list, >> there is something upstream you. >> >> I repeat, the location is not the fault here, and I encourage adding >> more exits in the US. >> >> On 9/30/2014 8:52 PM, Jon Daniels wrote: >> >>> Hi, >>> >>> My Tor node is not utilizing the bandwidth available to it. I have >>> tried setting RelayBandwidthRate to various values with no change >>> whatsoever in bandwidth usage. >>> >>> Running for 5 months with 99.77% uptime: >>> https://globe.torproject.org/#/relay/1F6598EA09A82E7A5D3131E71A97C8 >>> 06E6FDA4A1 >>> >>> My node has used a maximum of about 4MB/s or about 40Mbps. I've >>> been expecting it to use 10MB/sec to 30 MB/sec. It dropped from >>> 4MB/sec to around 1MB/sec now. >>> >>> OS: CentOS 6.x 64bit latest CPU: Xeon E3 1230 MB: Supermicro X9SCL >>> RAM: 8GB Network connection: 1000Mbps >>> >>> Bandwidth tests show the server can easily send or receive hundreds >>> of Mbps. I have tweaked server settings trying to get the speed up >>> to no avail. >>> >>> >>> Tor v0.2.4.24 (git-549ec02c188842f6) running on Linux with >>> Libevent 1.4.13-stable and OpenSSL 1.0.1e-fips. >>> >>> Relevant config: >>> >>> DirPort 9030 # what port to advertise for directory connections >>> >>> RelayBandwidthRate 30 MB # Throttle traffic to 100KB/s (800Kbps) >>> RelayBandwidthBurst 30 MB # But allow bursts up to 200KB/s >>> (1600Kbps) >>> >>> DisableDebuggerAttachment 0 >>> >>> ORPort 443 >>> >>> ExitPolicy accept *:20-23 # FTP, SSH, telnet ExitPolicy accept *:43 >>> # WHOIS ExitPolicy accept *:53 # DNS ExitPolicy accept *:79-81 # >>> finger, HTTP ExitPolicy accept *:88 # kerberos ExitPolicy accept >>> *:110 # POP3 ExitPolicy accept *:143 # IMAP ExitPolicy accept *:194 >>> # IRC ExitPolicy accept *:220 # IMAP3 ExitPolicy accept *:389 # >>> LDAP ExitPolicy accept *:443 # HTTPS ExitPolicy accept *:464 # >>> kpasswd ExitPolicy accept *:531 # IRC/AIM ExitPolicy accept >>> *:543-544 # Kerberos ExitPolicy accept *:554 # RTSP ExitPolicy >>> accept *:563 # NNTP over SSL ExitPolicy accept *:636 # LDAP over >>> SSL ExitPolicy accept *:706 # SILC ExitPolicy accept *:749 # >>> kerberos ExitPolicy accept *:873 # rsync ExitPolicy accept >>> *:902-904 # VMware ExitPolicy accept *:981 # Remote HTTPS >>> management for firewall ExitPolicy accept *:989-995 # FTP over SSL, >>> Netnews Administration System, telnets, IMAP over SSL, ircs, POP3 >>> over SSL ExitPolicy accept *:1194 # OpenVPN ExitPolicy accept >>> *:1220 # QT Server Admin ExitPolicy accept *:1293 # PKT-KRB-IPSec >>> ExitPolicy accept *:1500 # VLSI License Manager ExitPolicy accept >>> *:1533 # Sametime ExitPolicy accept *:1677 # GroupWise ExitPolicy >>> accept *:1723 # PPTP ExitPolicy accept *:1755 # RTSP ExitPolicy >>> accept *:1863 # MSNP ExitPolicy accept *:2082 # Infowave Mobility >>> Server ExitPolicy accept *:2083 # Secure Radius Service (radsec) >>> ExitPolicy accept *:2086-2087 # GNUnet, ELI ExitPolicy accept >>> *:2095-2096 # NBX ExitPolicy accept *:2102-2104 # Zephyr ExitPolicy >>> accept *:3128 # SQUID ExitPolicy accept *:3389 # MS WBT ExitPolicy >>> accept *:3690 # SVN ExitPolicy accept *:4321 # RWHOIS ExitPolicy >>> accept *:4643 # Virtuozzo ExitPolicy accept *:5050 # MMCC >>> ExitPolicy accept *:5190 # ICQ ExitPolicy accept *:5222-5223 # >>> XMPP, XMPP over SSL ExitPolicy accept *:5228 # Android Market >>> ExitPolicy accept *:5900 # VNC ExitPolicy accept *:6660-6669 # IRC >>> ExitPolicy accept *:6679 # IRC SSL ExitPolicy accept *:6697 # IRC >>> SSL ExitPolicy accept *:8000 # iRDMI ExitPolicy accept *:8008 # >>> HTTP alternate ExitPolicy accept *:8074 # Gadu-Gadu ExitPolicy >>> accept *:8080 # HTTP Proxies ExitPolicy accept *:8087-8088 # >>> Simplify Media SPP Protocol, Radan HTTP ExitPolicy accept >>> *:8332-8333 # BitCoin ExitPolicy accept *:8443 # PCsync HTTPS >>> ExitPolicy accept *:8888 # HTTP Proxies, NewsEDGE ExitPolicy accept >>> *:9418 # git ExitPolicy accept *:9999 # distinct ExitPolicy accept >>> *:10000 # Network Data Management Protocol ExitPolicy accept >>> *:11371 # OpenPGP hkp (http keyserver protocol) ExitPolicy accept >>> *:12350 # Skype ExitPolicy accept *:19294 # Google Voice TCP >>> ExitPolicy accept *:19638 # Ensim control panel ExitPolicy accept >>> *:23456 # Skype ExitPolicy accept *:33033 # Skype ExitPolicy accept >>> *:64738 # Mumble ExitPolicy reject *:* >>> >>> In addition, there's another Tor node running at the same ISP (but >>> by a different person), on completely different hardware and a >>> different router, that exhibits the same issue: >>> >>> https://globe.torproject.org/#/relay/50F37822AFA257B24B3343D9BBFB04 >>> 42E900FB4C >>> >>> For background, I built and manage the network both servers are >>> hosted on and have been doing so for 20 years. I also built both >>> servers. The network is at less than 15% capacity, 99% of the >>> time. >>> >>> CPU load is always at 0.00. Based in the USA, west coast. >>> >>> Ideas? Is there simply less demand for tor traffic in the US? >>> >>> Cheers, Jon >>> >>> >>> _______________________________________________ tor-relays mailing >>> list tor-relays(a)lists.torproject.org >>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >>> >>> >> - -- >> s7r >> PGP Fingerprint: 7C36 9232 5ABD FB0B 3021 03F1 837F A52C 8126 5B11 >> PGP Pubkey: http://www.sky-ip.org/s7r@sky-ip.org.asc >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v2.0.22 (MingW32) >> >> iQEcBAEBAgAGBQJUKvcYAAoJEIN/pSyBJlsRft0IANm500IF63yielvNcKqVdXQl >> j1fe532wa+/Ui3x3CCAj05lAEGFZlIhRZG70HQql+A5tTHFOUQbMhkJloXs5OOMC >> XGwMy8f26A6ZbHd4YAtg4p1c6d7YRfd3QJD1k8yERoEG1jEOjtJANCsCuXCult7u >> NyXL1t9UD12KMbTckIchBdqr5k2wA9e+RI8O60jSIq3h06kJ7yDA5yO6JNAvVRPE >> 2FMCxrJ5Bu9wWhp7F4YvogMHXTlcVbVNubOe/D5oBumz7KjsjUPbshaWz3kbXJUY >> 939O2dB5h3OrZkz9MqnlnpPkqcA4yTFZT8J3cXqtnOvKZx9SXhpj6WAXmua/Mo8= >> =IYwa >> -----END PGP SIGNATURE----- >> _______________________________________________ >> tor-relays mailing list >> tor-relays(a)lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> >> > ---------- Forwarded message ---------- From: isis <isis(a)torproject.org> To: tor-relays(a)lists.torproject.org Cc: Date: Wed, 1 Oct 2014 23:41:33 +0000 Subject: Re: [tor-relays] Scramblesuit Jan Nielsen transcribed 2.2K bytes: > Hi. > > I am trying to enable Scramblesuit for my bridge. I am wondering if there > is a method to verify that it is working, similar to how obfs3 shows > "registered server transport". There is not much out there about > scramblesuit but there is one mention that the log should show " registered > server transport scramble suit". > > Tor version is 0.2.5.8-rc > > Obfsproxy version 0.2.12 > > ExtORPort auto > > ServerTransportPlugin obfs3,scramblesuit exec /usr/bin/obfsproxy managed > > Oct 01 03:03:28.000 [notice] Registered server transport 'obfs3' at ' > 0.0.0.0:39491' > > Is there something wrong with my config? One way to figure out if scramblesuit is running would be to enable logging, like this: ServerTransportPlugin scramblesuit exec /usr/bin/obfsproxy --log-file /var/log/tor/scramblesuit.log --log-min-severity info managed -- ♥Ⓐ isis agora lovecruft _________________________________________________________ GPG: 4096R/A3ADB67A2CDB8B35 Current Keys: https://blog.patternsinthevoid.net/isis.txt _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

1 1

Nokia n900 relay
by Franklin 02 Oct '14

02 Oct '14

Hi How to setup relay address on nokia n900?

2 1

Scramblesuit
by Jan Nielsen 02 Oct '14

02 Oct '14

Hi. I am trying to enable Scramblesuit for my bridge. I am wondering if there is a method to verify that it is working, similar to how obfs3 shows "registered server transport". There is not much out there about scramblesuit but there is one mention that the log should show " registered server transport scramble suit". Tor version is 0.2.5.8-rc Obfsproxy version 0.2.12 ExtORPort auto ServerTransportPlugin obfs3,scramblesuit exec /usr/bin/obfsproxy managed Oct 01 03:03:28.000 [notice] Registered server transport 'obfs3' at ' 0.0.0.0:39491' Is there something wrong with my config? Thank you.

3 4

Failed to load Scramblesuit
by Christian 01 Oct '14

01 Oct '14

Dear fellows, maybe you can help out. And maybe I missed some information on my Tor version. I run an obfuscated bridge (Tor 0.2.5.8-rc (git-eaa9ca1011e73a9d)) on Ubuntu 12.04 and wanted to enable the scramblesuit pluggable transport. When changing my line in torrc to ServerTransportPlugin obfs3,scramblesuit exec /usr/bin/obfsproxy managed I get the following warning in the logs: [warn] The communication stream of managed proxy '/usr/bin/obfsproxy' is 'closed'. Most probably the managed proxy stopped running. This might be a bug of the managed proxy, a bug of Tor, or a misconfiguration. Please enable logging on your managed proxy and check the logs for errors. [notice] Failed to terminate process with PID '18171' ('Success'). Obfs3-only works like a charm without complaints. (ServerTransportPlugin obfs3 exec /usr/bin/obfsproxy managed) I set my ExtORPort to "auto", pyptlib is installed, packages from obfsproxy and pyptlib are in the right locations and I use the shipped apparmor profile for Tor for Ubuntus. Even if I stop apparmor service, I don't get better results. I thought it was a permissions problem somehow as --log-min-severity=debug --log-file=/home/me/obfs.log won't even create the logfile so that obfsproxy fails from the very beginning. But, as I said, obfs3-only works without problems. Any ideas? Thank you in advance. Kind regards christian

2 1

Bandwidth not being used by Tor on Gigabit dedicated server
by Jon Daniels 01 Oct '14

01 Oct '14

Hi, My Tor node is not utilizing the bandwidth available to it. I have tried setting RelayBandwidthRate to various values with no change whatsoever in bandwidth usage. Running for 5 months with 99.77% uptime: https://globe.torproject.org/#/relay/1F6598EA09A82E7A5D3131E71A97C806E6FDA4… My node has used a maximum of about 4MB/s or about 40Mbps. I've been expecting it to use 10MB/sec to 30 MB/sec. It dropped from 4MB/sec to around 1MB/sec now. OS: CentOS 6.x 64bit latest CPU: Xeon E3 1230 MB: Supermicro X9SCL RAM: 8GB Network connection: 1000Mbps Bandwidth tests show the server can easily send or receive hundreds of Mbps. I have tweaked server settings trying to get the speed up to no avail. Tor v0.2.4.24 (git-549ec02c188842f6) running on Linux with Libevent 1.4.13-stable and OpenSSL 1.0.1e-fips. Relevant config: DirPort 9030 # what port to advertise for directory connections RelayBandwidthRate 30 MB # Throttle traffic to 100KB/s (800Kbps) RelayBandwidthBurst 30 MB # But allow bursts up to 200KB/s (1600Kbps) DisableDebuggerAttachment 0 ORPort 443 ExitPolicy accept *:20-23 # FTP, SSH, telnet ExitPolicy accept *:43 # WHOIS ExitPolicy accept *:53 # DNS ExitPolicy accept *:79-81 # finger, HTTP ExitPolicy accept *:88 # kerberos ExitPolicy accept *:110 # POP3 ExitPolicy accept *:143 # IMAP ExitPolicy accept *:194 # IRC ExitPolicy accept *:220 # IMAP3 ExitPolicy accept *:389 # LDAP ExitPolicy accept *:443 # HTTPS ExitPolicy accept *:464 # kpasswd ExitPolicy accept *:531 # IRC/AIM ExitPolicy accept *:543-544 # Kerberos ExitPolicy accept *:554 # RTSP ExitPolicy accept *:563 # NNTP over SSL ExitPolicy accept *:636 # LDAP over SSL ExitPolicy accept *:706 # SILC ExitPolicy accept *:749 # kerberos ExitPolicy accept *:873 # rsync ExitPolicy accept *:902-904 # VMware ExitPolicy accept *:981 # Remote HTTPS management for firewall ExitPolicy accept *:989-995 # FTP over SSL, Netnews Administration System, telnets, IMAP over SSL, ircs, POP3 over SSL ExitPolicy accept *:1194 # OpenVPN ExitPolicy accept *:1220 # QT Server Admin ExitPolicy accept *:1293 # PKT-KRB-IPSec ExitPolicy accept *:1500 # VLSI License Manager ExitPolicy accept *:1533 # Sametime ExitPolicy accept *:1677 # GroupWise ExitPolicy accept *:1723 # PPTP ExitPolicy accept *:1755 # RTSP ExitPolicy accept *:1863 # MSNP ExitPolicy accept *:2082 # Infowave Mobility Server ExitPolicy accept *:2083 # Secure Radius Service (radsec) ExitPolicy accept *:2086-2087 # GNUnet, ELI ExitPolicy accept *:2095-2096 # NBX ExitPolicy accept *:2102-2104 # Zephyr ExitPolicy accept *:3128 # SQUID ExitPolicy accept *:3389 # MS WBT ExitPolicy accept *:3690 # SVN ExitPolicy accept *:4321 # RWHOIS ExitPolicy accept *:4643 # Virtuozzo ExitPolicy accept *:5050 # MMCC ExitPolicy accept *:5190 # ICQ ExitPolicy accept *:5222-5223 # XMPP, XMPP over SSL ExitPolicy accept *:5228 # Android Market ExitPolicy accept *:5900 # VNC ExitPolicy accept *:6660-6669 # IRC ExitPolicy accept *:6679 # IRC SSL ExitPolicy accept *:6697 # IRC SSL ExitPolicy accept *:8000 # iRDMI ExitPolicy accept *:8008 # HTTP alternate ExitPolicy accept *:8074 # Gadu-Gadu ExitPolicy accept *:8080 # HTTP Proxies ExitPolicy accept *:8087-8088 # Simplify Media SPP Protocol, Radan HTTP ExitPolicy accept *:8332-8333 # BitCoin ExitPolicy accept *:8443 # PCsync HTTPS ExitPolicy accept *:8888 # HTTP Proxies, NewsEDGE ExitPolicy accept *:9418 # git ExitPolicy accept *:9999 # distinct ExitPolicy accept *:10000 # Network Data Management Protocol ExitPolicy accept *:11371 # OpenPGP hkp (http keyserver protocol) ExitPolicy accept *:12350 # Skype ExitPolicy accept *:19294 # Google Voice TCP ExitPolicy accept *:19638 # Ensim control panel ExitPolicy accept *:23456 # Skype ExitPolicy accept *:33033 # Skype ExitPolicy accept *:64738 # Mumble ExitPolicy reject *:* In addition, there's another Tor node running at the same ISP (but by a different person), on completely different hardware and a different router, that exhibits the same issue: https://globe.torproject.org/#/relay/50F37822AFA257B24B3343D9BBFB0442E900FB… For background, I built and manage the network both servers are hosted on and have been doing so for 20 years. I also built both servers. The network is at less than 15% capacity, 99% of the time. CPU load is always at 0.00. Based in the USA, west coast. Ideas? Is there simply less demand for tor traffic in the US? Cheers, Jon

4 4

tor-relays mailing list submissions
by top mail 01 Oct '14

01 Oct '14

tor-relays mailing list submissions

1 0

tor-relays
by top mail 01 Oct '14

01 Oct '14

tor-relays

1 0

Loki1 and Loki2 closed
by jason＠icetor.is 30 Sep '14

30 Sep '14

Hey fellow ops, Just an FYI today that Icetor lost two of it's fastest two exits that were hosted with Greenqloud here in Iceland, obviously would not recommend them as an ISP in the future regarding exit hosting. About two weeks ago we got notification that abuse notices were breaking their EULA and would be the reason for the termination. Today they shut down the nodes about 5 hours earlier than indicated, no ability to do data migration or save keys. Needless to say I'm not very happy with the entire situation and how it was handled. We'll soldier on with our remaining two exits and ifanyone is thinking of spinning up an exit in the future Icetor is still able to handle abuse contact for the relay. -Jason

1 0

Oniontip
by justaguy 30 Sep '14

30 Sep '14

So, https://oniontip.com is a great help for tor-relay runners We do need more donations imho Whoever made it, thank you - Justaguy

10 15

[warn] No unused circIDs found on channel without wide circID support
by tor-admin 29 Sep '14

29 Sep '14

Hi, since upgrading torland to 0.2.5.8-rc I see the below warnings. Is this something to worry about? Regards, torland -------------------------------------------------------------------------- Sep 28 16:07:24.000 [warn] No unused circIDs found on channel without wide circID support, with 0 inbound and 4 outbound circuits. Found 0 circuit IDs in use by circuits, and 64 with pending destroy cells. (0 of those were marked bogusly.) The ones with pending destroy cells have been marked unusable for an average of 7594 seconds and a maximum of 16137 seconds. This channel is 18469 seconds old. Failing a circuit. Sep 28 16:07:24.000 [warn] Circuitmux on this channel has 4 circuits, of which 4 are active. It says it has 29535 destroy cells queued. Sep 28 16:07:24.000 [warn] Channel 93320 (at 0x7fbff4579d90) with transport TLS channel (connection 3245390) is in state open (2) Sep 28 16:07:24.000 [warn] * Channel 93320 was created at 1411894775 (18469 seconds ago) and last active at 1411913240 (4 seconds ago) Sep 28 16:07:24.000 [warn] * Channel 93320 says it is connected to an OR with digest 4C733BAC82CC609ACC58AD95BFBFF04D5D06188C and no known nickname Sep 28 16:07:24.000 [warn] * Channel 93320 says its remote address is [scrubbed], and gives a canonical description of "[scrubbed]" and an actual description of "[scrubbed]" Sep 28 16:07:24.000 [warn] * Channel 93320 has these marks: !bad_for_new_circs canonical is_canonical_is_reliable !client !local outgoing Sep 28 16:07:24.000 [warn] * Channel 93320 has 0 queued incoming cells and 0 queued outgoing cells Sep 28 16:07:24.000 [warn] * Channel 93320 has 4 active circuits out of 4 in total Sep 28 16:07:24.000 [warn] * Channel 93320 was last used by a client at 0 (1411913244 seconds ago) Sep 28 16:07:24.000 [warn] * Channel 93320 was last drained at 1411913141 (103 seconds ago) Sep 28 16:07:24.000 [warn] * Channel 93320 last received a cell at 1411913240 (4 seconds ago) Sep 28 16:07:24.000 [warn] * Channel 93320 last transmitted a cell at 1411913141 (103 seconds ago) Sep 28 16:07:24.000 [warn] * Channel 93320 has received 234 cells and transmitted 2497 Sep 28 16:07:24.000 [warn] * Channel 93320 has averaged 78.927350 seconds between received cells Sep 28 16:07:24.000 [warn] * Channel 93320 has averaged 7.396476 seconds between transmitted cells Sep 28 16:07:24.000 [warn] failed to get unique circID

2 1

Oniontip
by Sebastian Urbach 28 Sep '14

28 Sep '14

Hi, Mike, your questions are all valid. Remember where this project is coming from. Donncha put this together at the Dublin Bitcoin Hackathon and it was designed to give back a little bit to the Relay Operators. I never expected anything in return for my relays but im glad that onintip exists and the approach seems to be to give everybody a little bit back based on the consensus. Exit operators can get a lot of legal trouble and i acknowledge that but without Middle Relays, Guards, Bridges etc. TOR would not be possible. It seems to be always about the Exit's. There are different organizations for Exit's and now they should be preferred on oniontip.com ? It is hard not to feel like a second class Relay operator when you don't run an Exit. Im happy that there is a possibility like oniontip and btw. there is nothing similar on the torproject website. You can donate to the torproject via bitcoin but there is no way to choose who should receive this donation like you can do on oniontip.com Im not sure if it is necessary for oniontip to provide the best possible distribution of the donations from the projects point of view (diversity etc.) It seems to be a different approach just to give back to everybody and it has a certain amount of charme. It is easy to use and it seems to be working and becoming more and more popular. I like it. -- 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! -----------------------------------------

3 2

(no subject)
by I 27 Sep '14

27 Sep '14

Hej, Reportedly Pirate Bay runs virtual machines in someone else's clouds dodging revealing their IPs because traffic is handled by a load balancer. Why couldn't Tor be run in China, for example, using that method as there are cloud companies there? Robert

1 0

HAProxy + tor
by list-tor-relays＠nosur.com 26 Sep '14

26 Sep '14

Hello, My tor exit has been building up reputation for months but still fails to saturate a 100 Mbps line while barely using any CPU. Therefore, I recently decided to start a second tor process on the same server which is now slowly building up reputation. I gave the second process a different ORport in order not to affect the first process. Should that not be enough to saturate the line, I might even have to add a third process at yet other ports. I wondered whether the following is also possible: 1. Run tor process #1 on ORPort 8000, but advertise port 443 2. Run tor process #2 on ORPort 8001, but advertise port 443 3. Run tor process #3 on ORPort 8002, but advertise port 443 3. Run HAProxy on port 443; load-balancing between the three tor processes Obviously, this would require HAProxy to always route a circuit to the same tor process, since that tor process keeps track of the state of that specific circuit. Source IP stickiness ("balance source; hash-type consistent") would do that. Would such a setup work? Thanks, Bram

2 1

VPS in China
by I 26 Sep '14

26 Sep '14

Hej, Does anyone have an idea what might be done with a VPS in China? Robert

3 3

Estimating the value and cost of the Tor network
by Mike Perry 25 Sep '14

25 Sep '14

Hello everyone, I would like to put together some estimates on bounds of the current value and cost of the capacity of the Tor network as it is, and use that to generate some rough guestimates on what it would cost to grow it (assuming we solved all the complicated problems with respect to maintaining diversity and operator incentives). In order to make these estimates, I need some people to tell me: 1. Your node identity fingerprints. 2. How these fingerprints map to hardware, CPU cores, and uplink. 3. How much you are paying for this uplink per month. If you are paying less than market rate because of a friendly ISP, ideally you would also tell me what the standard market rate is at that ISP. If you have multiple nodes at multiple datacenters, please break these costs and fingerprints out individually rather than telling me aggregate information. I'd most like to hear from people who are doing the recommended best-practice of running one Tor process instance per CPU core, are paying for dedicated uplink at around 100Mbit/sec or higher at a datacenter, and who are not CPU bound on any of their Tor processes. If this does not apply to you, I'd still like to hear from you, but please tell me these details of your setup. Exit node data is most useful, but I am happy to hear about non-exits too. I suspect they may be much cheaper on average, and getting some data on this is also important. Unfortunately, bridges are not that useful at this time. You do not need to send this information publicly to the list. I am happy to receive it privately via GPG. My GPG key id is 0x29846B3C683686CC, and that key signs all of my mail to all torproject lists. You can get it here: https://pgp.mit.edu/pks/lookup?op=get&search=0x29846B3C683686CC -- Mike Perry

8 10

Bandwidth and weight fractions
by jchase 25 Sep '14

25 Sep '14

Dear Digest, If I take a look at my relay at atlas.torproject.org with the OR address of 83.163.171.103:9001 then I see on a 3 month graph that both my advertised bandwidth fraction and my consensus weight fraction are slowly declining. Concerning bandwidth fraction I assume this is a good thing, because if my bandwidth is stable then total bandwidth is going up (and my fraction is going down). Is the same true of my consensus weight fraction? If I'm going down, the total is going up? Thanks, JChase

1 0

Good hosting location for exit relay
by DerTor Steher 25 Sep '14

25 Sep '14

Hey, for a few days now I'm looking for an appropriate ISP for my new exit relay. There are a few problem I am facing now: 1.) Since I'm living in germany it isn't the very best to host an exit relay in germany, so I need to know which country is (law related) the best country I could host my VPS. 2.) The choice of a hoster. It's not easy to find a good and reliable and (if possible) cheap hoster which allows tor exit relays so I need to crawl to whole Good/Bad ISPs list for such providers. If I had the cash I would rent a server at Cyberbunker but it's to expensive to only run a relay there. I would appreciate if you could help me or at least give me some tips with finding the best country and provider. Thanks. :)

7 8

Re: [tor-relays] Call for a big fast bridge (to be the meek backend)
by David Fifield 25 Sep '14

25 Sep '14

On Mon, Sep 15, 2014 at 07:12:23PM -0700, David Fifield wrote: > The meek pluggable transport is currently running on the bridge I run, > which also happens to be the backend bridge for flash proxy. I'd like to > move it to a fast relay run by an experienced operator. I want to do > this both to diffuse trust, so that I don't run all the infrastructure, > and because my bridge is not especially fast and I'm not especially > adept at performance tuning. > > All you will need to do is run the meek-server program, add some lines > to your torrc, and update the software when I ask you to. The more CPU, > memory, and bandwidth you have, the better, though at this point usage > is low enough that you won't even notice it if you are already running a > fast relay. I think it will help if your bridge is located in the U.S., > because that reduces latency from Google App Engine. > > The meek-server plugin is basically just a little web server: > https://gitweb.torproject.org/pluggable-transports/meek.git/tree/HEAD:/meek… A couple of other requirements have shown themselves in helping set up a meek-server relay. The first is that it has to be a 0.2.5.x version of tor. This is so that the ExtORPort option will be supported. The ExtORPort option is needed in order to collect statistics on pluggable transports (see #4773). One of the lines you will have to add to torrc is: ExtORPort auto If your tor does not support the option, you will see in the log: [warn] Failed to parse/validate config: Unknown option 'ExtORPort'. Failing. The second requirement is that the relay needs to have either BridgeRelay or DirPort set. If neither of these options is set, the relay will not be a directory cache, and clients will not be able to bootstrap past "20%: Asking for networkstatus consensus." As I understand it, #12538 will make it so that every relay is a directory cache, but it is not committed yet. I'll check back privately with the people who offered to run a relay and check if setting these options is okay. David Fifield

1 0

Help collect hidden service usage stats?
by Roger Dingledine 24 Sep '14

24 Sep '14

Hi folks, If you are comfortable compiling Tor from git, and you want to help investigate what fraction of Tor network load comes from hidden service use, I have a shiny new git branch called hs-stats that will collect per-thirty-minute statistics about number of circuits and number of cells your relay sees that have to do with exiting, with hidden services, with circuits where you're not the final hop, and a fourth none-of-the-above category. https://trac.torproject.org/projects/tor/ticket/13192 It skips all circuits and cells that come from non-relays, which should help make sure the stats aren't useful for hurting anonymity. It doesn't automatically send the output anywhere -- it just writes it to its notice-level log for now. So you'll need to either send me the log lines, or add them to the trac ticket like I did here: https://trac.torproject.org/projects/tor/ticket/13192#comment:2 Preliminary results are that load from hidden services is actually a tiny fraction of overall load. A bonus use from these statistics would be to learn what fraction of load comes from exit connections vs middle connections, for relays with various consensus flags. And of course, it's possible there are bugs in how I'm doing the counting. I'll keep investigating to make sure I'm doing it right. Thanks! --Roger

1 0

How about a TWN entry about hosting locations?
by Jens Kubieziel 24 Sep '14

24 Sep '14

Hi, it seems quite much work for a person to collect information about hosting locations. So what do you think about putting a section into next TWN which links to a wiki page where everyone can share information about costs in different regions? -- Jens Kubieziel http://www.kubieziel.de Es genügt nicht, keine Gedanken zu haben. Man muß auch unfähig sein, sie auszudrücken. Karl Kraus

3 3

Alternative Nobel Prize
by Sebastian Urbach 24 Sep '14

24 Sep '14

Hi, The german magazine "der Spiegel" reports that Edward Snowden will receive the Alternative Nobel Prize. Congratulations Edward ! -- 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! -----------------------------------------

2 1