Hello all,
for somewhat over a year now I run a Tor relay on my router. The router in turn is running OpenWRT. It's this one:
https://globe.torproject.org/#/relay/A52C51551F3BD6A68E778720E02B53303F014EB... https://atlas.torproject.org/#details/A52C51551F3BD6A68E778720E02B53303F014E...
Not much, but let it be one of my small shares for improving humanity :-)
A few days ago I upgraded OpenWRT from 14.07 to 15.05, the latest release. Reinstalled the package 'tor', kept the old config file and the server started apparently smoothly. Previous Tor version was 0.2.4.22, now it's 0.2.5.12. I'm aware that these aren't exactly the latest, but that's what OpenWRT's package manager offers.
As you can see in the link above, the relay is no longer recognized as 'running'. They don't recognize the new Tor version, don't recognize the restart.
To what I know, /var/log/tor/notices.log looks fine, a few excerpts:
Jan 02 14:34:36.000 [notice] Tor 0.2.5.12 (git-99d0579ff5e0349f) opening new log file. [... clock synchrionisation works :-) ...] Jan 04 17:35:42.000 [warn] Your system clock just jumped 183652 seconds forward; assuming established circuits no longer work. [...] Jan 04 17:38:09.000 [notice] Now checking whether ORPort x.x.x.x:9001 is reachable... (this may take up to 20 minutes -- look for log messages indicating success) Jan 04 17:38:15.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. [...] Jan 06 11:35:42.000 [notice] Heartbeat: Tor's uptime is 1 day 18:00 hours, with 0 circuits open. I've sent 68.73 MB and received 85.15 MB. Jan 06 11:35:42.000 [notice] Average packaged cell fullness: 76.757% Jan 06 11:35:42.000 [notice] TLS write overhead: 9% Jan 06 11:35:42.000 [notice] Circuit handshake stats since last time: 9/9 TAP, 0/0 NTor.
How could I find out about what's going wrong?
Thanks, Markus
On 01/06/2016 06:11 AM, Markus Hitter wrote:
Not much, but let it be one of my small shares for improving humanity
You probably didn't save the keys in /var/lib/tor, so you set up a new relay and the old one isn't running. Here's your new relay: https://globe.torproject.org/#/relay/C1B80BA2D97C33851DE08FD061F531A12970598... It will be a few days before it sees more traffic, since it's a very new relay at this point.
With a speed like that, you might consider switching to an obfs4 bridge rather than a relay. You'll probably contribute more to the network that way.
Am 06.01.2016 um 20:22 schrieb Jesse V:
On 01/06/2016 06:11 AM, Markus Hitter wrote:
Not much, but let it be one of my small shares for improving humanity
You probably didn't save the keys in /var/lib/tor, so you set up a new relay and the old one isn't running.
Thanks, Jesse, looks like you're spot on. I've filed a bug report with the OpenWRT package:
https://dev.openwrt.org/ticket/21541 https://github.com/openwrt/packages/issues/2247
They might argue that an identity should go into /etc/, which is backed up by default, but let's see.
Markus
On 01/06/2016 11:02 AM, Markus Hitter wrote:
They might argue that an identity should go into /etc/, which is backed up by default, but let's see.
Your counter-argument is that /etc is for configuration files, not data files. /var/lib/tor is the correct place for keys per the Unix filesystem standards, near as I can tell. See https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
Is there really a reason to continue running this relay, even as a bridge? It has a consensus weight of 9. Before the upgrade and subsequent fingerprint reset, it was only at cw 16. The mean middle probability fraction was 0.000103%. The mean on the read/write was less than half a kilobyte per second. It's not really being used.
On 8 Jan 2016, at 16:26, Green Dream greendream848@gmail.com wrote:
Is there really a reason to continue running this relay, even as a bridge? It has a consensus weight of 9. Before the upgrade and subsequent fingerprint reset, it was only at cw 16. The mean middle probability fraction was 0.000103%. The mean on the read/write was less than half a kilobyte per second. It's not really being used.
A bridge exists to allow censored users access to the Tor network. So its consensus weight and use by the Tor network aren't really relevant.
What matters is the bandwidth it can contribute to censored users. The advertised bandwidth is 100KB/s, which is somewhat low for a bridge. As far as I recall, 250KB/s is considered a good minimum for a bridge.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
Am 08.01.2016 um 07:33 schrieb Tim Wilson-Brown - teor:
What matters is the bandwidth it can contribute to censored users. The advertised bandwidth is 100KB/s, which is somewhat low for a bridge. As far as I recall, 250KB/s is considered a good minimum for a bridge.
Yes, I'm aware of this "recommended minimum". But it's not me limiting bandwidth artifically, it's what the current hardware delivers. These 100 kB/s come for free, raising them would come with a price tag (xx Euros per month).
So the question is wether to take these 100 kB or wether to stop the relay entirely. I could well imagine such small contributions are more than nothing. I could also imagine to see thousands of such small relays, because they cost nothing and run barely noticeable to the non-Tor, everyday traffic. "Help freedom of speech at no cost" sounds really good, many others could chime in, if approached by some marketing. If there were thousands of them, their bandwidth would add up, right?
Another consideration is that it doesn't matter too much wether the bandwidth is actually used. I _could_ be used, raising the obfuscation the Tor network relies so heavily on.
What do you think?
Markus
On 8 Jan 2016, at 21:17, Markus Hitter mah@jump-ing.de wrote:
Am 08.01.2016 um 07:33 schrieb Tim Wilson-Brown - teor:
What matters is the bandwidth it can contribute to censored users. The advertised bandwidth is 100KB/s, which is somewhat low for a bridge. As far as I recall, 250KB/s is considered a good minimum for a bridge.
Yes, I'm aware of this "recommended minimum". But it's not me limiting bandwidth artifically, it's what the current hardware delivers. These 100 kB/s come for free, raising them would come with a price tag (xx Euros per month).
So the question is wether to take these 100 kB or wether to stop the relay entirely. I could well imagine such small contributions are more than nothing. I could also imagine to see thousands of such small relays, because they cost nothing and run barely noticeable to the non-Tor, everyday traffic. "Help freedom of speech at no cost" sounds really good, many others could chime in, if approached by some marketing. If there were thousands of them, their bandwidth would add up, right?
Another consideration is that it doesn't matter too much wether the bandwidth is actually used. I _could_ be used, raising the obfuscation the Tor network relies so heavily on.
What do you think?
There's a point at which distributing the information for a new relay (in consensus documents and microdescriptors) outweighs the bandwidth contributed by that relay.
I also wonder how much diversity Tor gains from small relays. I'm not sure how this works out, it may depend on your threat model. (Or the client's threat model.)
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@lists.torproject.org
-
Green Dream -
Jesse V -
Markus Hitter -
Tim Wilson-Brown - teor