- 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