Digital ocean does not currently charge for going over your data limit.
Send tor-relays mailing list submissions to
    tor-relays@xxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxx
You can reach the person managing the list at
    tor-relays-owner@xxxxxxxxxxxxxxxxxxxx
When replying, please edit your Subject line so it is more specific
than "Re: Contents of tor-relays digest..."
Today's Topics:
 Â1. Re: entry guard interference? (starlight.2015q1@xxxxxxxxxxx)
 Â2. Re: entry guard interference? (starlight.2015q1@xxxxxxxxxxx)
 Â3. Re: Digital Ocean: Moving to better Plan (Abhiram Chintangal)
 Â4. Re: Consensus weight dropped (Bram de Boer)
 Â5. Re: Consensus weight dropped (starlight.2015q1@xxxxxxxxxxx)
 Â6. Re: Consensus weight dropped (starlight.2015q1@xxxxxxxxxxx)
 Â7. Re: Consensus weight dropped (Network Operations Center)
---------- Forwarded message ----------
From:Âstarlight.2015q1@xxxxxxxxxxx
To:Âtor-relays@xxxxxxxxxxxxxxxxxxxx
Cc:Â
Date:ÂSat, 31 Jan 2015 09:26:24 -0500
Subject:ÂRe: [tor-relays] entry guard interference?
At 06:20 1/31/2015 -0500, grarpamp wrote:
>Yet during the time of an outage, you might try
>to leave the old tor running and. . .
I see the idea here but it's a lot
of fiddling and preparation. If it
continues to happen and I suspect
a bug, I'll upgrade the relay
version and run 'tcpdump' with
a ring-buffer capture that holds
the last two or three hours of
traffic. Then I just have to
stop the 'tcpdump' and review what
happened. Look for ICMP "not
reachable," injected RST's etc.
If my "just because your paranoid
doesn't mean they're not out to
get you" theory is correct, it
may never happen again. Certainly
the spooks of the world all read
the Tor mailing lists.
---------- Forwarded message ----------
From:Âstarlight.2015q1@xxxxxxxxxxx
To:Âtor-relays@xxxxxxxxxxxxxxxxxxxx
Cc:Â
Date:ÂSat, 31 Jan 2015 10:04:14 -0500
Subject:ÂRe: [tor-relays] entry guard interference?
At 06:20 1/31/2015 -0500, grarpamp wrote:
>Yet during the time of an outage, you might try
>to leave the old tor running and. . .
Also I see I should make a copy of the
cached-* files and the state file in
case some anomaly is present the Tor
routing data.
I did look at Vidalia'a network map
at the time of the incident and the
list of relays on the left side looked
ok. On the right side something like
 Â<path>
 Â<path>
 Âetc
appeared where client connections
normally are listed.
---------- Forwarded message ----------
From:ÂAbhiram Chintangal <abhiram.chintangal@xxxxxxxxx>
To:Âtor-relays@xxxxxxxxxxxxxxxxxxxx
Cc:Â
Date:ÂSat, 31 Jan 2015 12:22:42 -0500
Subject:ÂRe: [tor-relays] Digital Ocean: Moving to better PlanHello Sebastian,Thanks for responding.On Fri, Jan 30, 2015 at 10:15 PM, Sebastian Urbach <sebastian@xxxxxxxxxx> wrote:On January 31, 2015 2:09:14 AM Abhiram Chintangal <abhiram.chintangal@xxxxxxxxx> wrote:
Hi Abhiram,
I have been running a tor middle relay[1] for the past few months.
Thank you very much !
Â
One thing that I noticed in the last two months is that my relay is eating
up the 1tb bandwidth in the first three weeks. So I am thinking of moving
to a better plan or tweaking the current config to serve the bandwidth so
that the relay is up for the entire month.
I assume that you want a recommendation. A better plan probably means spending more money. Would be better for the network. If you can spare the money, go for it.
If you dont want to spend more money than it would be a good idea to lower the Rate value until you end up within your traffic limit for the month. The benefit would be a permanent available relay.ÂHmm, I think I will try changing the rate and see what happens. Last year, I used a daily limit instead of monthly one. It drastically reduced the relays reported bandwidth ( 1Mbps to 60 kbps ).ÂThanks!--
Sincerely yours / SincÃres salutations / M.f.G.
Sebastian Urbach
-----------------------------------------
Religion is fundamentally opposed to
everything I hold in veneration - courage,
clear thinking, honesty, fairness, and,
above all, love of the truth.
-----------------------------------------
Henry Louis Mencken (1880 - 1956),
American journalist, essayist, magazine
editor, satirist and critic.
_______________________________________________
tor-relays mailing list
tor-relays@xxxxxxxxxxxxxxxxxorg
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
--Abhiram Chintangal
---------- Forwarded message ----------
From:ÂBram de Boer <list-tor-relays@xxxxxxxxx>
To:Âtor-relays@xxxxxxxxxxxxxxxxxxxx
Cc:Â
Date:ÂSat, 31 Jan 2015 20:54:42 +0100
Subject:ÂRe: [tor-relays] Consensus weight dropped
All,
Consensus weight of my relays and those of others is still near zero, and
not improving. For a network that attempts to break censorship, it is
peculiar that this is getting so little attention.
Apparently a few malfunctioning bwauth systems is enough to censor
specific Tor relays. Endless research and development effort is put in
tweaking and optimizing the relay-to-relay communication, but having only
a few systems in the world that determine the consensus weight of the
entire network does not seem to trouble anyone. Wierd.
I hope the bwauth operators can find a way to correct the problem. I am
feeling silly spending good money on a high-end server with unmetered
bandwidth that has now been relaying a whopping 300 Kb/s on average during
the last five weeks.
Thanks,
Bram
> Thank you all for looking into this.
>
> Karsten wrote:
>> You could start a second relay on the same physical machine on a
>> different port and see whether the bandwidth scanners pick that up.
>> Give it a day or two, and see if only tor26 and moria1 measure it.
>
> In fact, both the 7C3AE76BB9E9E6E4F2AE9270FD824DF54A944127 and
> E6D740ABFFAAAD8052EDF95B2C8DC4059763F365 relays operate on the same IP
> address. Both dropped to 0.000000%.
>
> However, other nodes in the same AS16265 are doing fine (e.g.
> B144DC5C08AF1FB3ABD729AFC2CF938CF63F78AC). This seems to suggest that the
> route between the bwauths and the relay is irrelevant and connectivity is
> not an issue.
>
> I can imagine that an overloaded bwauth occasionally skips a few relays.
> But wouldn't that be corrected automatically during the measurement the
> next day? Given that the relays are missing votes consistently during many
> consecutive days, some other mechanism must be causing this.
>
> Would a quick-fix be to randomize the order in which relays are measured?
> That way, if a bwauth has trouble processing the entire list in 24h, every
> day other relays are given a chance?
>
> Thanks,
> Bram
>
> _______________________________________________
> tor-relays mailing list
> tor-relays@xxxxxxxxxxxxxxxxxxxx
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
---------- Forwarded message ----------
From:Âstarlight.2015q1@xxxxxxxxxxx
To:Âtor-relays@xxxxxxxxxxxxxxxxxxxx
Cc:Â
Date:ÂSat, 31 Jan 2015 15:23:08 -0500
Subject:ÂRe: [tor-relays] Consensus weight dropped
At 20:54 1/31/2015 +0100, you wrote:
>Consensus weight of my relays and those of others
>is still near zero, and not improving. . .
I read the earlier discussion around this
issue with interest. Have no specific
ideas about resolving the problem, but
I can recommend pulling the raw text
data files for the authority votes,
grep'ping your nodes, and looking at
the specific BWauth votes over time.
The data is found here
https://collector.torproject.org/archive/relay-descriptors/votes/
and while the files are a bit huge,
are easy to whack at with *nix
command line tools such as
egrep/awk/sed/perl etc. In a
pinch one might apply Excel to the
problem, but first trim the data
set down to size with a grep or your
desktop and Excel will choke and
die.
I did this at the point where the
bandwidth for election to guard
status was increased greatly and
my node was shipped off to middle-
relay mediocrity. Could see
clearly how it all transpired, but
of course I could do nothing about
it short of spending more $$ on
bandwidth.
With the raw data in hand, it will
be easier to campaign the operators
of the troublesome BWauths to correct
the problem.
---------- Forwarded message ----------
From:Âstarlight.2015q1@xxxxxxxxxxx
To:Âtor-relays@xxxxxxxxxxxxxxxxxxxx
Cc:Â
Date:ÂSat, 31 Jan 2015 15:32:23 -0500
Subject:ÂRe: [tor-relays] Consensus weight dropped
also, for recent data. . .
https://collector.torproject.org/recent/
---------- Forwarded message ----------
From:ÂNetwork Operations Center <noc@xxxxxxxxxxxx>
To:Âtor-relays@xxxxxxxxxxxxxxxxxxxx
Cc:Â
Date:ÂSat, 31 Jan 2015 21:51:12 +0100
Subject:ÂRe: [tor-relays] Consensus weight dropped
This has already been done. And I was under the impression that things would be changing soon. I still find it weird that the network is ignoring several nodes.
On 31.01.2015 09:23 PM, starlight.2015q1@xxxxxxxxxxx wrote:
At 20:54 1/31/2015 +0100, you wrote:
Consensus weight of my relays and those of others
is still near zero, and not improving. . .
I read the earlier discussion around this
issue with interest. Have no specific
ideas about resolving the problem, but
I can recommend pulling the raw text
data files for the authority votes,
grep'ping your nodes, and looking at
the specific BWauth votes over time.
The data is found here
https://collector.torproject.org/archive/relay-descriptors/votes/
and while the files are a bit huge,
are easy to whack at with *nix
command line tools such as
egrep/awk/sed/perl etc. In a
pinch one might apply Excel to the
problem, but first trim the data
set down to size with a grep or your
desktop and Excel will choke and
die.
I did this at the point where the
bandwidth for election to guard
status was increased greatly and
my node was shipped off to middle-
relay mediocrity. Could see
clearly how it all transpired, but
of course I could do nothing about
it short of spending more $$ on
bandwidth.
With the raw data in hand, it will
be easier to campaign the operators
of the troublesome BWauths to correct
the problem.
_______________________________________________
tor-relays mailing list
tor-relays@xxxxxxxxxxxxxxxxxorg
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
_______________________________________________
tor-relays mailing list
tor-relays@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
_______________________________________________ tor-relays mailing list tor-relays@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays