[tor-relays] moving digital ocean

Jan Nielsen jan.nielsen135 at gmail.com
Sat Jan 31 23:11:09 UTC 2015


Digital ocean does not currently charge for going over your data limit.
On Jan 31, 2015 1:51 PM, <tor-relays-request at lists.torproject.org> wrote:

> Send tor-relays mailing list submissions to
>         tor-relays at 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 at lists.torproject.org
>
> You can reach the person managing the list at
>         tor-relays-owner at 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. Re: entry guard interference? (starlight.2015q1 at binnacle.cx)
>    2. Re: entry guard interference? (starlight.2015q1 at binnacle.cx)
>    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 at binnacle.cx)
>    6. Re: Consensus weight dropped (starlight.2015q1 at binnacle.cx)
>    7. Re: Consensus weight dropped (Network Operations Center)
>
>
> ---------- Forwarded message ----------
> From: starlight.2015q1 at binnacle.cx
> To: tor-relays at lists.torproject.org
> 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 at binnacle.cx
> To: tor-relays at lists.torproject.org
> 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 at gmail.com>
> To: tor-relays at lists.torproject.org
> Cc:
> Date: Sat, 31 Jan 2015 12:22:42 -0500
> Subject: Re: [tor-relays] Digital Ocean: Moving to better Plan
> Hello Sebastian,
>
> Thanks for responding.
>
> On Fri, Jan 30, 2015 at 10:15 PM, Sebastian Urbach <sebastian at urbach.org>
> wrote:
>
>> On January 31, 2015 2:09:14 AM Abhiram Chintangal <
>> abhiram.chintangal at gmail.com> 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 at lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>
>
>
>
> --
> Abhiram Chintangal
>
>
>
>
> ---------- Forwarded message ----------
> From: Bram de Boer <list-tor-relays at nosur.com>
> To: tor-relays at lists.torproject.org
> 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 at lists.torproject.org
> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> >
>
>
>
>
>
> ---------- Forwarded message ----------
> From: starlight.2015q1 at binnacle.cx
> To: tor-relays at lists.torproject.org
> 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 at binnacle.cx
> To: tor-relays at lists.torproject.org
> 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 at schokomil.ch>
> To: tor-relays at lists.torproject.org
> 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 at binnacle.cx 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 at lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>
>
>
> _______________________________________________
> tor-relays mailing list
> tor-relays at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20150131/021be0cb/attachment-0001.html>


More information about the tor-relays mailing list