Send tor-relays mailing list submissions to
        tor-relays@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@lists.torproject.org

You can reach the person managing the list at
        tor-relays-owner@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@safe-mail.net>
To: tor-relays@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@safe-mail.net>
To: tor-relays@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@gmail.com>
To: tor-relays@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@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/1F6598EA09A82E7A5D3131E71A97C806E6FDA4A1

  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/50F37822AFA257B24B3343D9BBFB0442E900FB4C

  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@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@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

---------- Forwarded message ----------
From: isis <isis@torproject.org>
To: tor-relays@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@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays