I've been running an exit node for a number of years without incident, so I tend not to look at its state very much. I'm also not very technically knowledgeable about Tor.
However, I notice from Atlas that from January 1st, the exit probability of my server dropped dramatically and has stayed that way together with the observed bandwidth being always a small fraction of the speed I advertise:
https://atlas.torproject.org/#details/3612C429C29F698DEAB5072C75E2D700893D0C...
So I'm curious as to whether there's anything I can do to bring my consensus weight up, apart from just ensuring continuous uptime. That's not often under my control though, since reboots for kernel updates etc. come quite regularly.
Apologies if this a common question, but some initial searches on the subject turned up rather too much information for me to understand!
Jonathan
Hi Jonathan,
It is a relatively common question, I ask it all the time.
There are a few things you can try to do. Read all 4 before you make a decision.
1) Try turning your exit relay into a guard relay (ExitPolicy reject *:*). If no change after a week or so, it won't change. 2) Try resetting your onion keys by deleting everything in /var/lib/tor/keys 2.1) WARNING: Your relay is not new, looks almost 4 years old. When/if you reset your onion keys, you will get a brand new fingerprint, and you will appear as a brand new relay on the network, and have to go through all the stages again. That could be upsetting due to your longstanding participation, so be warned. Alternatively, save your onion keys somewhere safe, and create fresh onion keys to see if it works. If it doesn't work, put back your old keys. 3) Turn off your relay for at least a week. Let the network churn for a bit without you. It may help. 4) Do nothing. Ignore the previous 3 suggestions, and wait for more bwauths to be setup, which I've been repeatedly told are in the works and coming, and periodically remind people the problem still exists.
If you can, I would choose #4. If you are impatient like me, and also not horrendously fixated on your atlas stats, try any or all of the first 3.
Matt Speak Freely
On 07/17/2015 05:53 PM, Speak Freely wrote:
Hi Jonathan,
It is a relatively common question, I ask it all the time.
There are a few things you can try to do. Read all 4 before you make a decision.
- Try turning your exit relay into a guard relay (ExitPolicy reject
*:*). If no change after a week or so, it won't change. 2) Try resetting your onion keys by deleting everything in /var/lib/tor/keys 2.1) WARNING: Your relay is not new, looks almost 4 years old. When/if you reset your onion keys, you will get a brand new fingerprint, and you will appear as a brand new relay on the network, and have to go through all the stages again. That could be upsetting due to your longstanding participation, so be warned. Alternatively, save your onion keys somewhere safe, and create fresh onion keys to see if it works. If it doesn't work, put back your old keys. 3) Turn off your relay for at least a week. Let the network churn for a bit without you. It may help. 4) Do nothing. Ignore the previous 3 suggestions, and wait for more bwauths to be setup, which I've been repeatedly told are in the works and coming, and periodically remind people the problem still exists.
If you can, I would choose #4. If you are impatient like me, and also not horrendously fixated on your atlas stats, try any or all of the first 3.
Puh - a new fresh relay would be handled differently than an old relays which was rebooted ??
That would mean IMO that the bwauth algorithm has to be fixed or ?
On Fri, 17 Jul 2015 14:52:42 +0100 Jonathan Baker-Bates jonathan@bakerbates.com wrote:
So I'm curious as to whether there's anything I can do to bring my consensus weight up, apart from just ensuring continuous uptime. That's not often under my control though, since reboots for kernel updates etc. come quite regularly.
You could set up a 2nd instance of Tor on the same machine and IP address (of course using a different set of ports). This would help you to try the suggested "start afresh" experiment without losing your currently running relay.
Thanks all for the advice - I'll have a think about the options. Am inclined just to leave it as is for now, but tempted by the 2nd instance idea too.
Jonathan
On 17 July 2015 at 17:21, Roman Mamedov rm@romanrm.net wrote:
On Fri, 17 Jul 2015 14:52:42 +0100 Jonathan Baker-Bates jonathan@bakerbates.com wrote:
So I'm curious as to whether there's anything I can do to bring my consensus weight up, apart from just ensuring continuous uptime. That's
not
often under my control though, since reboots for kernel updates etc. come quite regularly.
You could set up a 2nd instance of Tor on the same machine and IP address (of course using a different set of ports). This would help you to try the suggested "start afresh" experiment without losing your currently running relay.
-- With respect, Roman
tor-relays@lists.torproject.org
-
Jonathan Baker-Bates -
Roman Mamedov -
Speak Freely -
Toralf Förster