> What can be known is *how* TOR is being used by setting up studies at exits
> and seeing what kind of services people are connecting to.
Please don't do that, or suggest doing that. Sniffing or inspecting exit
traffic may be illegal in some jurisdictions, and will result in the BadExit
It was two days ago. Today I can not reach it as well.
best regards
Dirk
On 01.05.2017 08:08, scar wrote:
> I was unable to reach the site, is it still in operation?
>
> _______
> tor-relays mailing list
> tor-relays@lists.torproj
for reducing the log footprint of a relay? Are
the OS defaults generally sufficient, or do operators need to take additional
steps to preserve user privacy?___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin
ontrol._______
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
going to help at all. Tor still isn't optimized for it.
If running on Linux or Unix there are a lot of optimizations to be done. For
Linux, I'd start here: https://www.torservers.net/wiki/setup/server and look at
the "High Bandwidth Tweaks" section._____
Nope that need not be it.
I had my bridge relay running for many moths with a few Mbps BW and it steadily
had the guard flag set.
When doing the latest TOR upgrade I upped the BW-limit 100% but since that tor
service restart it has now been running some 40 days without getting the guard
flag
On 16/02/2017 08:55, tor-ad...@torland.is wrote:
> Hi all,
>
> after 5 years of operation I will shutdown TorLand1
> (https://atlas.torproject.org/#details/E1E922A20AF608728824A620BADC6EFC8CB8C2B8)
>
> on February 17 2017.
Thank you for
an organization like torservers, nos onions, etc.
I hope others will step up and run high capacity exits. The Tor network needs
your help. I will continue to run a meek bridge.
Regards,
torland
___
tor-relays mailing list
tor-relays
It's a bridge.
Original Message
Subject: Re: [tor-relays] Normal to lose stable/guard flags on relay reboot?
Local Time: February 9, 2017 11:29 PM
UTC Time: February 9, 2017 11:29 PM
From: teor2...@gmail.com
To: tor-relays@lists.torproject.org
> On 10 Feb 2017, at 08
Mine is still missing the guard flag after 17 days since reboot.
Original Message
Subject: Re: [tor-relays] Normal to lose stable/guard flags on relay reboot?
Local Time: February 6, 2017 12:04 AM
UTC Time: February 6, 2017 12:04 AM
From: dl1...@gmx.de
To: tor-relays
On 8/02/2017 15:00, Andrew Deason wrote:
> I assume some people will say this isn't even worth the effort; it's not
> like it's hard to just ignore those reports. But it doesn't take much
> effort to just try to talk ot them, and it perhaps helps to give tor a
> reputation of
On 06.02.17 09:25, nusenu wrote:
The first release with the fix for [1] was in 0.3.0.3-alpha [2].
So if you run an IPv6 exit, upgrading to 0.3.0.3-alpha potentially
increases the tor network's IPv6 exit capacity.
teor and nickm plan a backport for tor 0.2.9.x
[1] https://trac.torproject.org
Hey all,
I was wondering what the minimum exit policy was (wrt port 80 and 443) for
a Tor exit relay. I
cant find any documentation about the minimum exit policy.
Is it possible to have an exit relay exit only to a /16 or a /8 on port 80
and 443?
I've tried having an exit policy that allows
Hi
When a tor admin updates a tor node, what is the reasoning for punishing the
status by removing flags like the guard flag?
The node may have been up for months on end without issues and goes down for a
few minutes during install and restart and comes up with a newer version, hence
Hi
I am a TOR bridge operator running a bridge with 8 Mbps advertised BW and
having obfs4 installed. Been up a year or so on this install.
I'll put a few misc thoughts out here, only been lurking on list earlier.
I have been thinking a little about how useful this system is (MY bridge
RelayBandwidthRate 400 KBytes
BandwidthRate 400 KBytes
there are running other services too.
Random Mirror / Tor Node Operator
Am 04.01.2017 um 21:18 schrieb ike:
I apreciate I'm not going to keep a relay running 24 hours on this server but
I'd like to know
there is no speed limit? I am the opinion that I have read something
about 250 kb / s!
Random Mirror / Tor Node Operator
Am 04.01.2017 um 20:55 schrieb Toralf Förster:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 01/04/2017 07:54 PM, ike wrote:
say less than
On Tue, Nov 15, 2016 at 12:41:09PM -0800, Arisbe wrote:
> One of my tor guard relays is a medium size VPS operating in the Czech
> Republic. It's been up and stable for several years. Several weeks ago I
> was notified that my VPS was a source of UDP DoS traffic. It was shut down.
>
anks!
[1] https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy
--
1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333
___________
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
This is the same tor box we had at the other place when we
had much much better bandwidth measurement on our relay - reported
bandwidth was a lot closer to what I had the limits set to in torrc.
Google fiber is in mid-deployment now in our neck of the woods but I
think we would probably have
ed bandwidth might
end up being used as your consensus weight.
The long-term fix for bandwidth measurement this is for the Tor network to
geographically distribute more bandwidth authorities, or use a distributed
bandwidth measurement system (this is an unsolved problem for untrusted
distributed
signature
_______
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On Friday 09 September 2016 20:22:47 Ralph Seichter wrote:
> # /etc/tor/torrc
> ORPort 443
> # Policies are kept in separate file for readability
> Include /etc/tor/policies
>
There is a ticket that handles this feature:
https://trac.torproject.org/projects/tor/ticke
> fixed, thanks.
https://gitweb.torproject.org/debian/tor.git/commit/?id=040fffc07b430d825e5acc88e6d2085a17b718fa
There is a little typo in the fix
tor@$name "
vs
tor@$name"
_______
tor-relays mailing list
tor-relays@lists.torproj
This is only relevant for debian users.
If you assume you can manage your instances with the usual systemctl commands
like
systemctl disable/enable tor@myinstance
beware that they have no effect.
Note: systemctl start/stop works as expected.
This is important to know especially if you have
https://gitweb.torproject.org/debian/tor.git/tree/debian/tor-instance-create#n89
is:
systemctl tor@$name start
should be:
systemctl start tor@$name mailto:tor@$name
https://gitweb.torproject.org/debian/tor.git/tree/debian/tor-instance-create.8.txt#n18
brdige -> bri
When upgrading the tor package on debian I get the following syslog messages:
systemd[1]: Failed to reset devices.list on /system.slice: Invalid argument
systemd[1]: Failed to reset devices.list on /system.slice/system-tor.slice:
Invalid argument
Should I be concerned
made a ticket:
https://trac.torproject.org/projects/tor/ticket/19847
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> So there is no way to disable the default instance using systemctl after all?
To answer my own question:
systemctl mask tor@default
disables the default instance for real.
..but I'm still curious why tor@default is a static unit (without [Install]
section)
https://bbs.archlinux.
> > > > Also: you can not start/stop/restart tor.service separately without
> > > > leaving all other tor instances untouched.
> > >
> > > tor.service is *not* the default service. tor.service is the collection
> > > of all service instan
> On August 5, 2016 at 1:24 PM Peter Palfrader <wea...@torproject.org> wrote:
>
>
> On Fri, 05 Aug 2016, tor relay wrote:
>
> > Also: you can not start/stop/restart tor.service separately without leaving
> > all other tor instances untouched.
>
> t
ice specific
ways like "if you want to disable it you have to move away its configuration
file).
Simply moving away its configuration file will cause unnecessary logs since
systemd will attempt to start tor.service every time:
Unable to open configuration file "/etc/tor/torrc".
>
> On August 4, 2016 at 10:23 AM Peter Palfrader <wea...@torproject.org>
> wrote:
>
> On Thu, 04 Aug 2016, tor relay wrote:
>
> > >
> > > > >
> > > On August 3, 2016 at 11
https://trac.torproject.org/projects/tor/ticket/19825___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
gt;
Since it is reproducible in my case as well I assume you do _not_ have the
following constellation:
tor.service is disabled and stopped (I don't use the default instance)
tor@1 mailto:tor@1 .service is enabled and running
tor@2.service mailto:tor@2.
> On August 3, 2016 at 11:04 PM Green Dream <greendream...@gmail.com> wrote:
>
>
> > When upgrading, all running tor instances are stopped (not restarted,
> as expected)
>
> > syslog shows:
>
> > Interrupt: we have stopped accepting ne
the upgrade. (I expected a simple restart
of all running tor instances)
I use debian's multi instance systemd service file.
When upgrading, all running tor instances are stopped (not restarted, as
expected)
syslog shows:
Interrupt: we have stopped accepting new connections, and will shut down in 30
as much as a
> > "thank you!" from anyone.
>
> Operating tor nodes is - like operating any
> invisible infrastructure - inherently thankless.
Absolutely. Most of the infrastructure we provide on that basis and it
is ok! The reason for running that exit node was that we bel
This makes no sense. It's good for the network if that
happens and allows diversity.
> Maybe a change in your strategy would make the life of your precious
> and fast relays a bit easier...
I have shut down our "precious and fast relays" recently as we
decided unanimously that th
Markus Koch <niftybu...@googlemail.com> wrote:
> exit allowed?
I can vouch for www.stayon.no
VPS with dedicated, unmetered 1 Gbps connection.
1 GB RAM / 1 CPU @ 2.6 GHz
Price: 149 NOK/month (~ 16 EUR / 17 USD).
Tor exit friendly. Their abuse departement will ask you to block
destin
> On July 28, 2016 at 2:48 PM Markus Koch <niftybu...@googlemail.com> wrote:
>
>
> exit allowed?
no, that is why I put "non-exit" in the subject of my email.
https://trac.torproject.org/projects/tor/wiki/doc/GoodBadISPs#Italy1
And yes, their support is poor, but
Hi!
I know the format for an obfs4 bridge is
obfs4 IP:port fingerprint cert=XX iat-mode=0
I know my IP, port and fingerprint, but where can I find the "cert"-value?
Kind regards
Tor-node.net
_______
tor-relays mailing list
tor-relays@lists.torp
Hi!
I run an obfs4 bridge.
1) Why is the advertised bandwidth 56.72 KB/s when the relay is on a
(shared) gigabit connection?
According to my experiments it should be several MB/s.
2) Where can I submit my bridges to help people in Iran, China etc, besides
the Tor BridgeDB?
Kind regards
Tor
Hi!
I have a VPS on a 6 TB (rx + tx) per month plan.
What is most useful for the Tor network:
a) Run it at full speed for about seven days per month (AccountingMax)
or
b) Throttle network speed by setting RelayBandwidthRate and always be
online?
Kind regards
Tor-node.net
<20MBit/s (per direction) weekly average
If anyone can recommend any other hosters, please come forward.
_______
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
ime.
Please quote support ID 13240401227566764688
signature.asc
Description: OpenPGP digital signature
___________
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
https://www.openssl.org/news/secadv/20160503.txt
In general I understand that padding oracle attacks are principally a
hazard for browser communications. Am assuming that updating OpenSSL
for this fix is not an urgent priority for a Tor Relay.
If anyone knows different please comment
On 25.04.2016 11:45, Petrusko wrote:
> 4. I'm confused, the "bridge" is acting like a relay ? (like a router on
> a network, 50% upload / 50% download...?). Or like a hidden door to
> contact the Tor network, and the client will only use relays after
> without the br
for the above recommendations found at
https://trac.torproject.org/projects/tor/ticket/18580#comment:11
https://unbound.net/pipermail/unbound-users/2016-April/004301.html
___
tor-relays mailing list
tor-relays@lists.torproject.org
https
wikisend.com/download/498630/ExoticVPS.ods
http://wikisend.com/download/894542/ExoticVPS.xlsx
http://wikisend.com/download/789008/ExoticVPS.txt
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
separated txt file)
Kind regards
tor-node.net
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
option, but that's now
obsolete.
See ticket 16543 and commit 2f8cf524b.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com
PGP 968F094B
teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
_______
tor-relays mailing list
tor-relays@list
FYI Tor-Relays
GoDaddy AS26496 is null-routing selected Tor Exits, presumably in
response to abuse originating from them. Know of two thus far
FE67A1BA4EF1D13A617AEFB416CB9E44331B223A 2016/01/26 ashtrayhat3
A0F06C2FADF88D3A39AA3072B406F09D7095AC9E 2016/03/16 Dhalgren
though probably more exist
Possibly this incident is the result of some malware attempting to use
some sort of domain "fast flux" or DGA algorithm. Seems improbable
anyone would be dumb enough to try to DDOS GoDaddy DNS using Tor.
_______
tor-relays mailing list
ost to this thread.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
was in the bogged-down state and was failing to
service Tor Browser requests. If developer is interested in taking a
look at this please contact me directly.
This issue is a PIA and if it continues I'll give up on 'unbound' and
follow the previous operator, switching to bind9 despite the lesser
performance
Nothing wrong with 'unbound'. Problem is bug in Tor daemon
interaction with 'unbound' that brings exit effectively offline when
GoDaddy blocks requests from it. This can happen to any fast exit
anytime. GoDaddy has been blocking high-volume DNS requesters since
2011, and recent activity by some
Hit a repeat of an earlier incident:
https://lists.torproject.org/pipermail/tor-relays/2016-January/008621.html
message from tor daemon is
Resolved [scrubbed] which was already resolved; ignoring
About 5400 of these messages over 37 hours, during which the relay
dropped down to 30% of usual
Gave up switched to 'named' and now it's working fine.
Entered BUG: https://trac.torproject.org/projects/tor/ticket/18580
Be advised, anyone running a fast exit with 'unbound' should switch to
using 'named'.
___
tor-relays mailing list
tor-relays
es,
then an upgrade happens. (as september last year)
Other factors probably also play a role. If anyone can contribute their
opinion based on their experience and the publicly available data,
feel free!
Cheers.
_______
tor-relays mailing list
tor-relays@lists.t
On 08.03.2016 19:30, Volker Mink wrote:
> You can take it down for some days without losing any flags or consensus
> weight.
> Had it with my exit i have at home.
> I had to reinstall it and i have the same stats as before.
The HSDir flag will be cleared after each restart of th
t 1
GB RAM.
signature.asc
Description: OpenPGP digital signature
_______
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On 26.02.2016 13:50, Roman Mamedov wrote:
> On Fri, 26 Feb 2016 12:27:07 +0100
> Random Tor Node Operator <t...@unterderbruecke.de> wrote:
>
>> So in terms of censorship resistance, bridges with occasionally changing
>> IP are better for the Tor network than those wit
On 26.02.2016 11:54, Tim Wilson-Brown - teor wrote:
>
>> On 26 Feb 2016, at 11:52, Random Tor Node Operator
>> <t...@unterderbruecke.de <mailto:t...@unterderbruecke.de>> wrote:
>>
>> On 26.02.2016 05:15, torser...@datakanja.de
>> <mailto:torse
On 26.02.2016 05:15, torser...@datakanja.de wrote:
> * Next, i noticed a frequent (daily) behavior of the Tor server
> dropping traffic to around zero. Inspecting this, let me to
> understand, my provider was disconnecting me and reassigning a new
> IP on a daily basis
WNFY4VrO9qf2Uoh8VtKbHsGOj+SLdG1nLnQOfELU
eaCkGMX0sBif5lhe/Tr+
=v/3o
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
. [101144347 similar message(s) suppressed in
> > last 21600 seconds]
>
> Are you using tor packages from
> https://deb.torproject.org/torproject.org/dists/ ?
I get packages via
deb https://deb.torproject.org/torproject.org precise main
But I use a custom startup script from torserver
On Sunday 21 February 2016 12:57:52 Julien ROBIN wrote:
> When I had 2 tor clients running (the second launched manually by a user
> named "tor2"), I modified the "limits.conf" file, adding those 2 lines at
> the end :
>
> #* softcore
On Sunday 21 February 2016 11:56:37 Jonas Bergler wrote:
> https://gitweb.torproject.org/tor.git/tree/doc/TUNING
Thanks Jonas for the link. file descriptors should be set to ulimit -n 65535 in
the tor startup script. I thought that would work. But checking
/proc/PID/limits I saw that f
://trac.torproject.org/projects/tor/ticket/16929
which does not help me. I don't find the mentioned branch bug16929 in git.
Can someone please advise what has to be done to avoid the warning, or point
me where I find can the file "doc/TUNING".
Thank
since not declaring $family could cause risk to Tor-Network: action
should take place if relayoperator is not responding config,
right?
Am Dienstag, 19. Januar 2016 20:28 schrieb nusenu
<nus...@openmailbox.org>:
just wondering whats the matter with these 66+ relays &qu
hi,
just wondering whats the matter with these 66+ relays "cloudvps" ...
guess they get vote, should we discard some iprages?
thanks
_______
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/li
Mathewson
<ni...@torproject.org>:
TL;DR: Stable non-exit relays can help tor clients use the Tor
network. Please opt-in!
We want to run a trial of fallback directory mirrors (fallbacks) in
Tor. Tor clients contact fallbacks to download the consensus during
initial bootstrap, before they c
Hi,
you didn't get the V2Dir flag with AccountingMax set on... I had to have
the same experience with that.
Random Tor Node Operator
hi
Am 13.12.2015 um 23:32 schrieb Lucas Werkmeister:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi all!
For some reason, my
follwing advice:
For each Tor process set in torrc:
BandwidthRate 1300 bytes
BandwidthBurst 13375000 bytes
So you end up with
Server1: 4x 1300 bytes = 4x13MB/s
Server2: 4x 1300 bytes = 4x13MB/s
(in each direction)
104+104=208 MB/s
You hopefully will end up with ~540TB per month.
(oh
hmm weight-drops again? i am loosing my whole traffic / consensus
weight... since 7 pm CET.
Random Tor Node Operator
Am 09.12.2015 um 01:27 schrieb Tim Wilson-Brown - teor:
On 9 Dec 2015, at 06:07, tor-server-crea...@use.startmail.com
<mailto:tor-server-c
Mozilla <3
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Hi!
> Hi All
> Is it possible to schedule the time when bandwith will looks as follow:
>
> 8:00 - 18:00 - Tor relay bandwith 250kb/s
>
> 18:00 - 8:00 - Tor relay bandwith 10 000kb/s
>
>
> How may I schedule this in tor relay ? Is it possible to limit traffic
>
Am Freitag, 4. Dezember 2015 08:57 schrieb Josef 'veloc1ty' Stautner
<he...@veloc1ty.de>:
Have you restarted
Tor after you made changes?
Yes. After ive done changes i always restart the Server hard. Tor is
Running As Daemon so hours after restart i just do a
, Dhalgren Tor <dhalgren@gmail.com> wrote:
>>. . .I have to understand how my ISP reacts to this kind of things.
>
>>For the moment I will keep a low profile and I will block the
>>mentioned IP range for a month.
>
> Webiron's system sends notifications to both th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
On 28.11.2015 17:43, David Schulz wrote:
> can i get problems as an german citizen with an non exit tor relay
> in germany with an italien ip? not realy or? i think of TMG § 8.
As a non-exit relay operator, you are most certainly not
whos then receiving home-addresses from longtime relay-owners earned
t-shirts?!
Am Dienstag, 17. November 2015 21:00 schrieb nusenu
<nus...@openmailbox.org>:
tor weather hasn't been working for me for a long time and AFAIK it
is
not main
n appears to ignore this
source and simply construct the abuse@ from the rDNS domain name.
_______
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
y honest people" with
"grow the network as large as possible, so we can be robust against
more subtle attackers".
___________
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
a
given circuit (no family set, non-exit + exit relays and more than
one
/16 network).
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
______
Is the end of the month. Maybe they ran out of bandwidth and will be
back 11/1. LeaseWeb over-limit rates are terrifying.
BTW the exit policy includes 443.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi
Link requested subdomains to the relay's fingerprint, and require all
change/update requests to be signed by the node's keys, and have some
validation that the node can be found on the network (and is an exit
node). This will ensure only Tor exit nodes can apply, and that nodes
can only change
Dear yl,
just a few words from the abuse helpdesk of a larger tor-exit-node...
TL;DR: we ignore those requests. they don't even reach a human.
While we do handle most genuine/honest/helpful and especially all
non-automated abuse reports very diligently. Pointless nagging
services like webiron
>snake oil service like webiron
A most excellent characterization!
As a sales maneuver WebIron has been grandstanding
for months saying that Tor operators are "unwilling
to cleanup" when they know full-well that tor operators
can not / should not filter traffic due to minor brute
Any exit operators with relays at LeaseWeb who are not enjoying the
new automated abuse-notice system requiring all complaints be acted
upon, send a message directly to the above address. Have a solution.
___
tor-relays mailing list
tor-relays
final post
https://lists.torproject.org/pipermail/tor-relays/2015-October/007901.html
initial post
https://lists.torproject.org/pipermail/tor-relays/2015-October/007863.html
_______
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torp
d' replies.
Statistics for the filter are viewed with the command
tc -s filter show dev eth0 root
With the initial settings the bandwidth filter discarded 0.25% of
incoming TCP packets--in line with what one sees in 'netstat -s'
statistics for a not-overloaded relay. However the 'tor' daemon went
str
for thread 0: requestlist max 112 avg 28.1553 exceeded 0 jostled 0
histogram of recursion processing times
[25%]=0.00737672 median[50%]=0.0492239 [75%]=0.144125
...
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin
ou're near saturation,
> assuming the traffic is not constant
Would make it worse, not better. A higher burst rate will
allow the measurement to increase; the average limit
must stay the same regardless. Best to set burst-max ==
average max. Tor relays allow some bursting regardless
of the Band
per-decile 126717
. . .horrible
On 10/1/15, Yawning Angel <yawn...@schwanenlied.me> wrote:
> On Thu, 1 Oct 2015 19:05:38 +
> Dhalgren Tor <dhalgren@gmail.com> wrote:
>> 3) observing that statistics show elevated cell-queuing delays when
>> the relay has been
vity and low latency of relay. Result is overloaded relay and
poor end-use latency.
> Is Tor using more bandwidth that the BandwidthRate?
No, but relay is loaded to flat-line maximum and clearly is attracting
too many circuits.
> If so, this is a bug, and should be reported on the Tor Tra
>Don't cap the speed if you have bandwidth limits. The better way to do it is
>using AccountingMax in torrc. Just let it run at its full speed less of the
>time and Tor will enter in hibernation once it has no bandwidth left.
Not possible. Will violate the FUP (fair use policy) on th
to extract proper rating from measurement system?
Tried setting TokenBucketRefillInterval to 10 milliseconds for more
exact control but this has not helped. Should an IPTABLES
packet-dropping limit be established? Can the rating system be fixed?
___
tor
On Thu, Oct 1, 2015 at 12:55 PM, Tim Wilson-Brown - teor
<teor2...@gmail.com> wrote:
>
> On 1 Oct 2015, at 14:48, Dhalgren Tor <dhalgren@gmail.com> wrote:
>
> A good number appears to be around 65000 to 7, but 98000 was just
> assigned.
>
>
> Since I
701 - 800 of 988 matches
Mail list logo
