[tor-relays] scramblesuit

Thu Oct 2 03:18:13 UTC 2014

Ok, I got scramblesuit working. Had to change various permissions and copy
over the new obfsproxy Dir from /usr/local/bin to /usr/bin/.

The log file helped; thank you! And just to confirm, I did receive a "
server transport registered scramblesuit" entry in my log.
On Oct 1, 2014 7:00 PM, <tor-relays-request at lists.torproject.org> wrote:

> 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 at lists.torproject.org> wrote:
>
> Send tor-relays mailing list submissions to
>         tor-relays at 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 at lists.torproject.org
>
> You can reach the person managing the list at
>         tor-relays-owner at 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 at safe-mail.net>
> To: tor-relays at 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 at safe-mail.net>
> To: tor-relays at 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 at gmail.com>
> To: tor-relays at 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 at 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 at 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 at lists.torproject.org
>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>>
>>>
>>
>
>
> ---------- Forwarded message ----------
> From: isis <isis at torproject.org>
> To: tor-relays at 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 at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20141001/247a6568/attachment-0001.html>