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