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, <[email protected]> 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, <[email protected]> wrote: > > Send tor-relays mailing list submissions to > [email protected] > > 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 > [email protected] > > You can reach the person managing the list at > [email protected] > > 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 <[email protected]> > To: [email protected] > Cc: > Date: Wed, 1 Oct 2014 08:49:53 -0400 > Subject: [tor-relays] tor-relays > tor-relays > > > > ---------- Forwarded message ---------- > From: top mail <[email protected]> > To: [email protected] > 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 <[email protected]> > To: [email protected] > 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 <[email protected]> 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 [email protected] >>>> 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/[email protected] >>> -----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 >>> [email protected] >>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >>> >>> >> > > > ---------- Forwarded message ---------- > From: isis <[email protected]> > To: [email protected] > 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 > [email protected] > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > >
_______________________________________________ tor-relays mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
