[tor-commits] r26528: {website} +6 FAQ entries (website/trunk/docs/en)
Matt Pagan
matt at pagan.io
Fri Jan 10 07:10:50 UTC 2014
Author: mttp
Date: 2014-01-10 07:10:49 +0000 (Fri, 10 Jan 2014)
New Revision: 26528
Modified:
website/trunk/docs/en/faq.wml
Log:
+6 FAQ entries
Modified: website/trunk/docs/en/faq.wml
===================================================================
--- website/trunk/docs/en/faq.wml 2014-01-09 03:13:38 UTC (rev 26527)
+++ website/trunk/docs/en/faq.wml 2014-01-10 07:10:49 UTC (rev 26528)
@@ -132,12 +132,22 @@
</a></li>
<li><a href="#WhyIsntMyRelayBeingUsedMore">Why isn't my relay being
used more?</a></li>
+ <li><a href="#IDontHaveAStaticIP">I don't have a static IP.</a></li>
+ <li><a href="#ModemKeepsCrashing">My cable/dsl modem keeps crashing.
+ What's going on?</a></li>
+ <li><a href="#PortscannedMore">Why do I get portscanned more often
+ when I run a Tor relay?</a></li>
+ <li><a href="#MoreThanOneCPU">I have more than one CPU. Does this
+ help?</a></li>
<li><a href="#HighCapacityConnection">How can I get Tor to fully
make use of my high capacity connection?</a></li>
<li><a href="#RelayFlexible">How stable does my relay need to
be?</a></li>
- <li><a href="#ExitPolicies">I'd run a relay, but I don't want to
-deal
+ <li><a href="#BandwidthShaping">What bandwidth shaping options are
+ available to Tor relays?</a></li>
+ <li><a href="#LimitTotalBandwidth">How can I limit the total amount
+ of bandwidth used by my Tor relay?</a></li>
+ <li><a href="#ExitPolicies">I'd run a relay, but I don't want to deal
with abuse issues.</a></li>
<li><a href="#RelayOrBridge">Should I be a normal relay or bridge
relay?</a></li>
@@ -1526,8 +1536,8 @@
</p>
<p>
-For other configuration options you can use, look at the <a href="<page
-docs/tor-manual>">Tor manual page</a>. Look at <a
+For other configuration options you can use, see the <a href="<page
+docs/tor-manual>">Tor manual page</a>. Have a look at <a
href="https://gitweb.torproject.org/tor.git/blob/HEAD:/src/config/torrc.sample.in">
the sample torrc file</a> for hints on common configurations. Remember, all
lines beginning with # in torrc are treated as comments and have no effect
@@ -2031,6 +2041,82 @@
<hr>
+ <a id="IDontHaveAStaticIP"></a>
+ <h3><a class="anchor" href="#IDontHaveAStaticIP">I don't have a static
+ IP.</a></h3>
+
+ <p>
+ Tor can handle relays with dynamic IP addresses just fine. Just leave
+ the "Address" line in your torrc blank, and Tor will guess.
+ </p>
+
+ <hr>
+
+ <a id="ModemKeepsCrashing"></a>
+ <h3><a class="anchor" href="#ModemKeepsCrashing">My cable/DSL modem
+ keeps crashing. What's going on?</h3></a>
+
+ <p>
+ Tor relays hold many connections open at once. This is more intensive
+ use than your cable modem (or other home router) would ever get normally.
+ So if there are any bugs or instabilities, they might show up now.
+ </p>
+ <p>
+ If your router keeps crashing, you've got two options. First, you should
+ try to upgrade its firmware. If you need tips on how to do this, ask
+ Google or your cable/router provider, or try the Tor IRC channel.
+ </p>
+
+ <p>
+ Usually the firmware upgrade will fix it. If it doesn't, you will
+ probably want to get a new (better) router.
+ </p>
+
+ <hr>
+
+ <a id="PortscannedMore"></a>
+ <h3><a class="anchor" href="#PortscannedMore">Why do I get portscanned
+ more often when I run a Tor relay?</a></h3>
+
+ <p>
+ If you allow exit connections, some services that people connect to
+ from your relay will connect back to collect more information about you.
+ For example, some IRC servers connect back to your identd port to record
+ which user made the connection. (This doesn't really work for them,
+ because Tor doesn't know this information, but they try anyway.) Also,
+ users exiting from you might attract the attention of other users on the
+ IRC server, website, etc. who want to know more about the host they're
+ relaying through.
+ </p>
+ <p>
+ Another reason is that groups who scan for open proxies on the Internet
+ have learned that sometimes Tor relays expose their socks port to the
+ world. We recommend that you bind your socksport to local networks only.
+ </p>
+ <p>
+ In any case, you need to keep up to date with your security. See this <a
+ href="https://trac.torproject.org/projects/tor/wiki/doc/OperationalSecurity">article
+ on operational security for Tor relays</a> for more suggestions.
+ </p>
+
+ <hr>
+
+ <a id="MoreThanOneCPU"></a>
+ <h3><a class="anchor" href="#MoreThanOneCPU">I have more than one CPU.
+ Does this help?</a></h3>
+
+ <p>
+ Yes. You can set your NumCpus config option in torrc to the number of
+ CPUs you have, and Tor will spawn this many cpuworkers to deal with
+ public key operations in parallel.
+ </p>
+
+ <p>
+ This option has no effect for clients.
+ </p>
+
+ <hr>
+
<a id="HighCapacityConnection"></a>
<h3><a class="anchor" href="#HighCapacityConnection">How can I get Tor to fully
make use of my high capacity connection?</a></h3>
@@ -2093,7 +2179,115 @@
</ul>
<hr>
+
+ <a id="BandwidthShaping"></a>
+ <h3><a class="anchor" href="#BandwidthShaping">What bandwidth shaping
+ options are available to Tor relays?</a></h3>
+ <p>
+ There are two options you can add to your torrc file:
+ </p>
+ <ul>
+ <li>
+ BandwidthRate is the maximum long-term bandwidth allowed (bytes per
+ second). For example, you might want to choose "BandwidthRate 2 MB"
+ for 2 megabytes per second (a fast connection), or "BandwidthRate 50
+ KB" for 50 kilobytes per second (a medium-speed cable connection).
+ The minimum BandwidthRate is 20 kilobytes per second.
+ </li>
+ <li>
+ BandwidthBurst is a pool of bytes used to fulfill requests during
+ short periods of traffic above BandwidthRate but still keeps the
+ average over a long period to BandwidthRate. A low Rate but a high
+ Burst enforces a long-term average while still allowing more traffic
+ during peak times if the average hasn't been reached lately. For example,
+ if you choose "BandwidthBurst 50 KB" and also use that for your
+ BandwidthRate, then you will never use more than 50 kilobytes per second;
+ but if you choose a higher BandwidthBurst (like 1 MB), it will allow
+ more bytes through until the pool is empty.
+ </li>
+ </ul>
+ <p>
+ If you have an asymmetric connection (upload less than download) such
+ as a cable modem, you should set BandwidthRate to less than your smaller
+ bandwidth (Usually that's the upload bandwidth). (Otherwise, you could
+ drop many packets during periods of maximum bandwidth usage -- you may
+ need to experiment with which values make your connection comfortable.)
+ Then set BandwidthBurst to the same as BandwidthRate.
+ </p>
+ <p>
+ Linux-based Tor nodes have another option at their disposal: they can
+ prioritize Tor traffic below other traffic on their machine, so that
+ their own personal traffic is not impacted by Tor load. A <a
+ href="https://gitweb.torproject.org/tor.git/blob/HEAD:/contrib/linux-tor-prio.sh">script
+ to do this</a> can be found in the Tor source distribution's contrib
+ directory.
+ </p>
+ <p>
+ Additionally, there are hibernation options where you can tell Tor to
+ only serve a certain amount of bandwidth per time period (such as 100
+ GB per month). These are covered in the <a
+ href="#LimitTotalBandwidth">hibernation entry</a> below.
+ </p>
+ <p>
+ Note that BandwidthRate and BandwidthBurst are in <b>Bytes,</b>not Bits.
+ </p>
+
+ <hr>
+
+ <a id="LimitTotalBandwidth"></a>
+ <h3><a class="anchor" href="#LimitTotalBandwidth">How can I limit the
+ total amount of bandwidth used by my Tor relay?</a></h3>
+ <p>
+ The accounting options in the torrc file allow you to specify the maximum
+ amount of bytes your relay uses for a time period.
+ </p>
+ <pre>
+ AccountingStart day week month [day] HH:MM
+ </pre>
+ <p>
+ This specifies when the accounting should reset. For instance, to setup
+ a total amount of bytes served for a week (that resets every Wednesday
+ at 10:00am), you would use:
+ </p>
+ <pre>
+ AccountingStart week 3 10:00
+ AccountingMax N bytes KB MB GB TB
+ </pre>
+ <p>
+ This specifies the maximum amount of data your relay will send during an
+ accounting period, and the maximum amount of data your relay will receive
+ during an account period. When the accounting period resets (from
+ AccountingStart), then the counters for AccountingMax are reset to 0.
+ </p>
+ <p>
+ Example. Let's say you want to allow 1 GB of traffic every day in each
+ direction and the accounting should reset at noon each day:
+ </p>
+ <pre>
+ AccountingStart day 12:00
+ AccountingMax 1 GB
+ </pre>
+ <p>
+ Note that your relay won't wake up exactly at the beginning of each
+ accounting period. It will keep track of how quickly it used its
+ quota in the last period, and choose a random point in the new interval
+ to wake up. This way we avoid having hundreds of relays working at the
+ beginning of each month but none still up by the end.
+ </p>
+ <p>
+ If you have only a small amount of bandwidth to donate compared to your
+ connection speed, we recommend you use daily accounting, so you don't
+ end up using your entire monthly quota in the first day. Just divide
+ your monthly amount by 30. You might also consider rate limiting to
+ spread your usefulness over more of the day: if you want to offer X GB
+ in each direction, you could set your BandwidthRate to 20*X. For example,
+ if you have 10 GB to offer each way, you might set your BandwidthRate to
+ 200 KB: this way your relay will always be useful for at least half of
+ each day.
+ </p>
+ <hr>
+
<a id="ExitPolicies"></a>
<h3><a class="anchor" href="#ExitPolicies">I'd run a relay, but I
don't want to deal with abuse issues.</a></h3>
More information about the tor-commits
mailing list