- tor-relays - lists.torproject.org

consensus-health
by Felix 03 Jan '17

03 Jan '17

https:// consensus-health.torproject.org/ (observed 2017-01-03 16:00:00 and 2017-01-03 17:00:00) shows * dannenberg: Missing entirely from consensus * faravahar: Missing Signature! Valid-after time of auth's displayed consensus: 2017-01-03 15:00:00 * moria1: Sees only 2620 relays running Is https:// lists.torproject.org/pipermail/tor-consensus-health/2017-January/date.html ok ? -- imho - like always

2 1

Re: [tor-relays] Speed up of reconnections after IP Address change
by balbea16 03 Jan '17

03 Jan '17

Hi ThereI've just written a simple bash script which verifies (in a while loop) every 2 minutes if the OR address has been changed by my ISP. If so, it stops and then restarts the Tor service again. Then it sleeps for 24 hours and starts the 2 minute loop again. Not very sophisticated, but it might work. Mike

2 1

how to generate relay keys manually (before actually running the relay)
by nusenu 03 Jan '17

03 Jan '17

>> Tipp: If you are planing to grow beyond your 31 relays I recommend >> you preemptively generate the keys for your upcoming relays so you >> don't have to touch all other relays everytime you add a single >> relay (to the MyFamily line). > How do you pregenerate keys? Id be interested as Im spinning up > quite a few soon create a folder per tor instance: mkdir future-relay1 future-relay2 ... then invoke tor manually (this will just generate keys and exit after that): tor --PublishServerDescriptor 0 --orport auto --list-fingerprint --datadirectory future-relay1 --Log "err stdout" tor --PublishServerDescriptor 0 --orport auto --list-fingerprint --datadirectory future-relay2 --Log "err stdout" ... In these folders you will then find the fingerprint that you can use in MyFamily, so you don't have to touch your existing relays anymore once you actually use these generated keys on new relays. Make sure you take care of filesystem permissions when using these keys on the actual relay.

2 1

Container tor relay
by Sec INT 03 Jan '17

03 Jan '17

Had a search but cant find much info on running tor relays in containers specifically by proxmox lxc containers - I have a free server atm but dont really want to spinup a load of vms when I could do containers instead - its a load test for me but would mean quite a few relays running with gbps network card (all their own ip's) Anyone tried this yet? Cheers Mark B Snaptor.co.uk (non commercial)

1 0

what to expect with baby exitnodes?
by stinkyonion＠sigaint.org 03 Jan '17

03 Jan '17

well the subject sums it up really I couldn't find a solid explanation. I believe it was ARMA that explained the life cycle of a relay, so I'm curious does this apply for exit nodes? thanks for the clarification

2 1

what to expect with baby exitnodes?
by stinkyonion＠sigaint.org 03 Jan '17

03 Jan '17

well the subject sums it up really I couldn't find a solid explanation. I believe it was ARMA that explained the life cycle of a relay, so I'm curious does this apply for exit nodes? thanks for the clarification

1 0

Speed up of reconnections after IP Address change
by balbea16 03 Jan '17

03 Jan '17

Hi There,I only have a dynamic IP address and my ISP changes it almost every time after 24 hours. It is somehow sad to see 1.400 connections drop to almost none. After the change it takes 20 minutes until my OR notices this (our IP Address has changed from ...). It than takes another hour until the connections start to actualy rebuild. This means it takes more than an hour (every per day) to reach the normal operating Mode. Is there any way to speed up this process? Could adjust the torrc script for instance? TNX Mike

4 3

Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP
by balbea16 03 Jan '17

03 Jan '17

Hi There I evaluated some relays with newly assigned (red) guard flags. All of them had already the stable flag assigned. And (so far I could see) all of them had (almost) static IP addresses. In my case, this may be the reason why I don't get a guard flag. My ISP changes it every 24 hours. However, I'd be fine with "just" operating a fast middle node. I will keep an eye on this. Mike

3 4

_AceLewis tor relays: please specify 'MyFamily' in your torrc
by nusenu 03 Jan '17

03 Jan '17

Hi Lewis, thanks for adding your 6 tor relays to the network! Please do not forget to set the MyFamily parameter in your torrc configuration to tell clients your relays belong to a single operator. If you need help with the MyFamily option let us know. thanks, nusenu +------------+-----------+-----------------+----------------+ | first_seen | nickname | IP | eMyFamilyCount | +------------+-----------+-----------------+----------------+ | 2016-12-27 | acelewis4 | 138.197.131.213 | NULL | | 2016-12-27 | acelewis | 188.226.129.48 | NULL | | 2016-12-27 | acelewis3 | 207.154.205.226 | NULL | | 2016-12-27 | acelewis5 | 139.59.160.33 | NULL | | 2016-12-27 | acelewis6 | 139.59.42.48 | NULL | | 2016-12-27 | acelewis2 | 139.59.252.170 | NULL | +------------+-----------+-----------------+----------------+

1 0

Re: [tor-relays] Grizzly Steppe
by rush23＠gmx.net 02 Jan '17

02 Jan '17

By the way Jerry Gamblin checked the list against the tor exit nodes and found 191 that have been used in this hacking... There you can find his thread with the whole listing.. https://twitter.com/JGamblin/status/814627227656683521 Regards 0x23 Am 2. Januar 2017 09:39:50 MEZ schrieb tor-relays-request(a)lists.torproject.org: >Send tor-relays mailing list submissions to > tor-relays(a)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(a)lists.torproject.org > >You can reach the person managing the list at > tor-relays-owner(a)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: Grizzly Steppe (Rana) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Mon, 2 Jan 2017 10:39:40 +0200 >From: "Rana" <ranaventures(a)gmail.com> >To: <tor-relays(a)lists.torproject.org> >Subject: Re: [tor-relays] Grizzly Steppe >Message-ID: <03ed01d264d3$c4700b40$4d5021c0$(a)gmail.com> >Content-Type: text/plain; charset="utf-8" > >My bet is that the recorded IP address dates back to the days when your >node >was an exit. Naturally the Russian hackers have used Tor, probably in >tandem >with a VPN - it would have been stupid of them not to, and stupid they >are >not. > >And you are right - now the US government will blame Tor exit operators >for >the sheer stupidity of email operators in political shops such as DNC >that >do not force their users to encrypt email end to end. PGP is too much >trouble for them. > >If I am right there is nothing you can do now, you have already closed >the >exit. If they pressure you, migrate your relay to another IP. > >Rana > >From: tor-relays [mailto:tor-relays-bounces@lists.torproject.org] On >Behalf >Of Dr Gerard Bulger >Sent: Monday, January 02, 2017 10:15 AM >To: tor-relays(a)lists.torproject.org >Subject: [tor-relays] Grizzly Steppe > >I ran an exit node, but gave up after too many abuse reports that >annoyed my >ISP. So I turned al exit ports off, and reports stopped as a rely. >After >months and many terabytes of data I get an abuse complaint that my tor >IP >has been used for espionage. > >"NCSC have been made aware of a report and associated malicious >indicators >released by the United States Government relating to malicious cyber >activity. A copy if the report and indicators can be found at the >following >link:- >https://www.us-cert.gov/security-publications/GRIZZLY-STEPPE-Russian-Malicio >us-Cyber-Activity >Details within this report indicate network assets which may have been >compromised or associated with malicious activity. We have identified >the >following IP address from this report as x.x.x.x As a minimum, it is >recommended that you check systems and any available logs concerned >with the >above addresses for indications of malicious activity" > >There are no other details as to HOW my tor relay is being used. The >espionage seems to relay on the stupidity of recipients on receiving >emails >asking for passwords. I am not sure HOW ISP or relay service can stop >that. >Or is it that my relay was being used to transfer the data? > >I assume my IP was found by way of a DNS leak which I need to look >into. >There is nothing else I can do as a relay to stop this or is there? > >Gerry > > > >

1 0

Grizzly Steppe
by Dr Gerard Bulger 02 Jan '17

02 Jan '17

I ran an exit node, but gave up after too many abuse reports that annoyed my ISP. So I turned al exit ports off, and reports stopped as a rely. After months and many terabytes of data I get an abuse complaint that my tor IP has been used for espionage. "NCSC have been made aware of a report and associated malicious indicators released by the United States Government relating to malicious cyber activity. A copy if the report and indicators can be found at the following link:- https://www.us-cert.gov/security-publications/GRIZZLY-STEPPE-Russian-Malicio us-Cyber-Activity Details within this report indicate network assets which may have been compromised or associated with malicious activity. We have identified the following IP address from this report as x.x.x.x As a minimum, it is recommended that you check systems and any available logs concerned with the above addresses for indications of malicious activity" There are no other details as to HOW my tor relay is being used. The espionage seems to relay on the stupidity of recipients on receiving emails asking for passwords. I am not sure HOW ISP or relay service can stop that. Or is it that my relay was being used to transfer the data? I assume my IP was found by way of a DNS leak which I need to look into. There is nothing else I can do as a relay to stop this or is there? Gerry

3 2

How can we trust the guards?
by Rana 01 Jan '17

01 Jan '17

Sorry for the naïve question, but we have a total of about 7000 relays, many of them residential and thus practically unused or very lightly used. So the actual number of relays that carry most of the traffic is rather small, and many of them are middle relays, leaving an even smaller number of guard relays. This means that an adversary with a rather modest budget can easily take over half the guards. Whats the trust mechanism (if any) to ensure that the majority of guards are not hijacked by adversaries?

2 1

Re: [tor-relays] [Crypto-practicum] Open-source cooperative security using low-cost HSMs?
by grarpamp 31 Dec '16

31 Dec '16

On Fri, Dec 30, 2016 at 10:36 PM, Bill Cox <waywardgeek(a)gmail.com> wrote: > One problem is shills. IIUC, TOR has a problem where an attacker can create > a ton of nodes that collude. > TOR could be > 50% shills and we would not know. Is this something that could > be implemented effectively with the dreaded web of trust? Yes. It has been repeatedly brought up among tor that relay operators, being globally spread and relatively physically mobile for the purpose of keysigning, can cross sign their node keys with gpg keys, have their gpg keys signed in person under proof of relay ownership as usual, dump the fingerprints into the consensus and sks, then build relay selection algorithms that download and verify the wot into user run tools that then build their circuits in the controller. Users can elect to use variant levels of trust present in the wot, anon / nym / context signing, ID signing, photo signing, multisig assertions, etc. Beyond just the wot, all sorts of other external metrics, even subscriptions to third party metrics services, could be applied to such a relay selection process. 7000 relays, even at low 10% shill and 1:1 would require 700 unique persons of the adversary that pass the smell test of other operators and principals, that has real costs. Or your allies just supply the number of validated nodes needed to prevent network saturation and users simply decline to route anything but CNN and gerbil pr0n through the 700 unvalidated nodes. Pretty simple really, needs nothing more than one structured comment field in the consensus and some external tools, but nobody has rolled it out or even developed concept further yet.

1 0

"Graceful" Restart of Tor-Relay ?
by mistral.relay＠posteo.net 30 Dec '16

30 Dec '16

Hello all, a newbie question: assuming that I want to shut down and restart a running tor-relay (for whatever reason; e.g. a linux reboot is required) - is it fine to just shut down the relay or is there a nicer, more tor-user friendly way so circuits don't drop for them unexpectedly? I was thinking about a command to tell tor to complete whatever is ongoing, but to not accept any new circuits or other requests and then stop working. Would setting the BandwidthBurst to 0 followed by a tor-reload do this over some time (checking with e.g. arm what is still ongoing)? Many thanks!

5 4

I am in with 4 exits
by niftybunny 30 Dec '16

30 Dec '16

https://twitter.com/JGamblin/status/814627227656683521 <https://twitter.com/JGamblin/status/814627227656683521> anyone can beat this? Markus

1 0

TransPort: Convert iptables to pf
by diffusae 28 Dec '16

28 Dec '16

Hello! Does anybody know how to convert this to pf rules in FreeBSD: iptables -t nat -A OUTPUT -p tcp -d 10.192.0.0/10 -j REDIRECT --to-ports 9040 I' running a Tor client in a jail on a different IP and want to route only the .onion traffic through. The DNS stuff is working fine, but I can't find a solution for the above iptables rule, which is working. I like transparently do DNS and Routing for .onion traffic on the network. I looked into the wiki and also find some pf rules, which are routing all the traffic though Tor, but this only works locally. The machine is on FreeBSD 11.0-STABLE. Tor is running in a jail with cloned loopback interface (lo1) and has also a private IP address on the main NIC. Maybe you have some hints. Thanks a lot Regards,

5 11

Relay is missing Running flag in the consensus
by Dmitrii Tcvetkov 28 Dec '16

28 Dec '16

Hello, I have a problem with one[1] of my exit relays: about a week ago this relay lost its Running flag, but it was running all the time. I upgraded Tor on this relay to 0.2.9.7-rc from "tor-devel" FreeBSD port and restarted it. Relay was and still is accessible from outside via ports 80 and 443. FreeBSD version is 11.0-RELEASE-p2. After about 24 hours running on new version I decided to check votes from bwauth on detailed page here[2]. Back then the relay had votes for Running flag from maatuuska, dizum and dannenberg. I've checked the relay's ability to open connections to bwauths and it couldn't connect to longclaw - connection timed out, all other bwauths are reachable from the relay. Test was performed by command "openssl s_client -connect <bwauth ip>:443". Ipfw and pf are disabled on the server, there are only tor, ssh and local_unbound running, unbound uses my recursive DNS resolver on another server. DNS queries are resolved fine. Then I saved /var/db/tor directory and started Tor with fresh identity[3], but in about 6 hours it showed similiar symptoms: only maatuska, dizum and dannenberg were voting for it, so I switched back to old identity[1] since. In December 23th I decided to downgrade Tor version back to 0.2.8 from FreeBSD port "tor" and I enabled info level logging. The relay was running since with version 0.2.8.11, at the moment still only 3 bwauth are voting "Running" flag for it: maatuska, dizum and dannenberg. All bwauths except longclaw are accessible from the server. All bwauths are accessible from my neighbour relays in the same datacenter[4][5]. Log info.log has size of 200 megabytes at the moment, first concerning message is: Dec 23 11:54:23.000 [warn] Cannot make an outgoing connection without a DirPort. messages during relay startup, but they disappear eventually: # grep -c 'outgoing connection without a DirPort' info.log 19 They don't look like a reason for the problem. Another anomaly is huge amount of messages like Dec 23 11:54:24.000 [info] router_pick_published_address: Success: chose address '85.143.213.44'. ... Dec 26 13:58:31.000 [info] router_pick_published_address: Success: chose address '85.143.213.44'. # grep -c router_pick_published_address info.log 1653449 I upgraded Tor to version 0.2.9.8 from FreeBSD port "tor". The flood of router_pick_published_address doesn't reproduce with new version. I can compress the log file to 2 mb file with xz -9 and publish it, though I don't want to do it right away because of the warning: Dec 23 11:54:20.000 [warn] Your log may contain sensitive information - you're logging more than "notice". Don't l og unless it serves an important reason. Overwrite the log afterwards. as I don't really know what exact info I should scrub from it. Currently relay is running with identity[1] and version 0.2.9.8 with info logging. Traceroute to longclaw: 17:05:15-root@bsd1 ~ # traceroute 199.254.238.53 traceroute to 199.254.238.53 (199.254.238.53), 64 hops max, 40 byte packets 1 192.168.240.102 (192.168.240.102) 0.084 ms 0.088 ms 0.059 ms 2 192.168.240.5 (192.168.240.5) 0.664 ms 0.180 ms 0.105 ms 3 85.143.208.1 (85.143.208.1) 1.035 ms 1.437 ms 3.960 ms 4 185-47-53-25.customer.comfortel.pro (185.47.53.25) 0.759 ms 0.615 ms 0.645 ms 5 81-27-254-184.rascom.as20764.net (81.27.254.184) 1.507 ms 1.213 ms 1.300 ms 6 80-64-96-225.rascom.as20764.net (80.64.96.225) 12.082 ms 11.974 ms 11.867 ms 7 xe-9-2-0.bar1.Stockholm1.Level3.net (213.242.110.113) 11.781 ms 11.575 ms lag-127-401.ear1.Stockholm2.Level3.net (213.242.110.41) 12.083 ms 8 * * * 9 63-235-41-149.dia.static.qwest.net (63.235.41.149) 112.242 ms 115.032 ms 117.349 ms 10 * * * 11 65.116.154.6 (65.116.154.6) 182.361 ms 182.780 ms 185.128 ms 12 208.99.210.41 (208.99.210.41) 181.991 ms 182.831 ms 182.524 ms 13 208.99.192.65 (208.99.192.65) 181.698 ms 182.007 ms 182.437 ms 14 204.8.32.86 (204.8.32.86) 185.968 ms 185.809 ms 185.945 ms 15 wren.riseup.net (198.252.153.1) 181.940 ms 181.907 ms 181.890 ms 16 * * * 17 * * * Please tell what I can do to understand a reason of the problem. P.S. During compress attempt of the log memory of the server was exhausted: xz and tor processes were killed. So log is containing information since Dec 23 11:54:20 UTC till Dec 26 13:58:39 UTC. I'll compress logs on another machine. [1] 1836695E7DFE2F80B13A9884431759B5DD19F1DA [2] https://consensus-health.torproject.org/ [3] 9E2833F5F95421B52A5336F66B063E471725F011 [4] 2C2CD992B785F09752278260DCD8D6D6242BB87A [5] 7F350D9EAD6C74730FB13862308BE60FA9B19678

2 1

Re: [tor-relays] [tor-talk] 33c3 and tor?
by Nicolas Braud-Santoni 28 Dec '16

28 Dec '16

On Mon, Dec 26, 2016 at 08:56:04AM -0500, Roger Dingledine wrote: > On Tue, Dec 20, 2016 at 02:37:19PM +0100, fatal wrote: > > And will there be a tor relay operators meetup? > > [...] > I think there is no separate relay operators meeting, so relay > operators are welcome in this workshop space too. I was made to spontaneously organise one (after I asked a certain Moritz if there would be one) on day 3 (Thursday), 10pm : https://events.ccc.de/congress/2016/wiki/Session:Tor_Relays_Operators_Meetup We currently have hall C.2, which can host ~50 people, but I will try to organise a larger venue based on the success of tomorrow's meetup. Best, and hoping to see you there, nicoo

1 0

TransPort: Convert iptables to pf _ nat
by Felix 27 Dec '16

27 Dec '16

>>> scrub in all >>> nat pass on $ext_if from $NET_JAIL to any -> $IP_PUB >>> rdr pass on $ext_if proto tcp from any to $IP_PUB port $PORT_TOR_JAIL -> >>> $IP_JAIL_TOR port $PORT_TOR_JAIL >> >> That looks good. >> >> There is no "pass out quick" or "pass out on" statement? > > Sure, there is. > pass out on $ext_if proto { tcp udp icmp } all modulate state Remove 'pass' form 'nat pass' if the packet shall flow through the 'pass out' rule after 'nat'. Otherwise it will pass out without respect to any rule. [] https:// www.freebsd.org/cgi/man.cgi?query=pf.conf&sektion=5#end -- imho, looking forward to 33C3 :)

1 0

George Shuklin relays: please specify MyFamily in torrc
by nusenu 26 Dec '16

26 Dec '16

Hi George Shuklin, thanks for running tor relays. Please do not forget to set the MyFamily parameter in your torrc configuration to tell clients your relays belong to a single operator. If you need help with the MyFamily option let us know. thanks, nusenu https://github.com/nusenu/ansible-relayor https://raw.githubusercontent.com/ornetstats/stats/master/o/potentially_dan…

1 0

neelc.org relays: MyFamily update required
by nusenu 26 Dec '16

26 Dec '16

Hi Neel, one of your relays got a new key, please do not forget to update your MyFamily setting. thank you, nusenu https://atlas.torproject.org/#search/69.126.169.33 https://raw.githubusercontent.com/ornetstats/stats/master/o/potentially_dan… +---------------------+----------------+---------------+ | first_seen | IP | MyFamilyCount | +---------------------+----------------+---------------+ | 2016-08-10 01:00:00 | 89.187.144.122 | 4.0000 | | 2015-04-15 18:00:00 | 107.181.174.84 | 4.0000 | | 2016-09-05 22:00:00 | 108.29.79.159 | 4.0000 | | 2016-12-17 17:00:00 | 69.126.169.33 | 2.0000 | +---------------------+----------------+---------------+

2 2

Re: [tor-relays] 2bithacker.net relays: MyFamily fixed.
by nusenu 25 Dec '16

25 Dec '16

Chip Marshall: > Should be all fixed up now, thanks for the headsup. yes it is fixed now, thanks! +-------------+----------------+ | nickname | eMyFamilyCount | +-------------+----------------+ | 2bitsgsin01 | 12.0000 | | 2bitusnyc02 | 12.0000 | | 2bitusnyc01 | 12.0000 | | 2bitdefra01 | 12.0000 | | 2bitgblon01 | 12.0000 | | 2bitinblr01 | 12.0000 | | 2bitcator01 | 12.0000 | | 2bitusnyc03 | 12.0000 | | 2bitussfo01 | 12.0000 | | 2bitnlams02 | 12.0000 | | 2bitussfo02 | 12.0000 | | 2bitnlams03 | 12.0000 | +-------------+----------------+

1 0

Minimum requirements for becoming a guard
by Rana 25 Dec '16

25 Dec '16

What are the absolute minimum requirements for becoming a guard? [I am not asking about being trustworthy which I am obviously not, only about bandwidth etc. :)]

2 1

FW: Merry Christmas from President Obama and the First Lady
by I 25 Dec '16

25 Dec '16

1 0

Multiple Tor Instances
by Dakota Hourie 24 Dec '16

24 Dec '16

Hi Everyone, Would anyone be able to point me in the right direction to be able to run multiple instances of tor for a multi core cpu. Tor version is 2.9.8 on Ubuntu 16.04. Thanks -- Dakota Hourie --

5 7

iptables stats
by Monkey Pet 24 Dec '16

24 Dec '16

This machine is dedicated as a tor-relay. Is it normal that the INPUT bytes count is much greater than the OUTPUT bytes or did I configure the iptables wrong? iptables -L -v Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 6 328 ACCEPT all -- lo any anywhere anywhere 38 2557 ACCEPT icmp -- any any anywhere anywhere 1135 68123 ACCEPT tcp -- any any anywhere anywhere tcp dpt:http 27432 6416K ACCEPT tcp -- any any anywhere anywhere tcp dpt:https 6274 479K ACCEPT tcp -- any any anywhere anywhere tcp dpt:ssh 93821 129M ACCEPT all -- any any anywhere anywhere ctstate RELATED,ESTABLISHED 1050 54292 DROP all -- any any anywhere anywhere Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 70579 packets, 36M bytes) pkts bytes target prot opt in out source destination

1 0

atx.name relays: MyFamily update required
by nusenu 24 Dec '16

24 Dec '16

Hi Josef, thanks for adding your 3 relays to the tor network! Please do not forget to set the MyFamily parameter in your torrc files so tor clients are not using your non-exit and exit relays at the same time in a single circuit. If you need help with configuring MyFamily, let us know. Since you are running tor 0.2.5.12 you might also want to consider updating to the recently released version 0.2.9.8. happy relaying, nusenu https://github.com/nusenu/ansible-relayor https://github.com/ornetstats/stats https://raw.githubusercontent.com/ornetstats/stats/master/o/potentially_dan…

1 1

"[warn] Cannot make an outgoing connection without a DirPort" under BSD
by pa011 24 Dec '16

24 Dec '16

I am running (FreeBSD 11.0-RELEASE-p2) Tor 0.2.8.11 getting following warnings while Self-testing indicates that DirPort is reachable from the outside? Can these warnings be ignored, while Tor is running properly afterwards ? Merry Christmas! Paul Dec 24 13:20:57.000 [notice] Bootstrapped 80%: Connecting to the Tor network Dec 24 13:20:57.000 [warn] Cannot make an outgoing connection without a DirPort. Dec 24 13:20:58.000 [notice] Bootstrapped 85%: Finishing handshake with first hop Dec 24 13:20:58.000 [notice] Bootstrapped 90%: Establishing a Tor circuit Dec 24 13:20:58.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working. Dec 24 13:20:58.000 [notice] Bootstrapped 100%: Done Dec 24 13:20:58.000 [notice] Now checking whether ORPort x.x.x.x:9001 and DirPort x.x.x.x:9030 are reachable... (this may take up to 20 minutes -$ Dec 24 13:20:59.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Dec 24 13:20:59.000 [notice] Self-testing indicates your DirPort is reachable from the outside. Excellent. Publishing server descriptor. Dec 24 13:21:00.000 [notice] Performing bandwidth self-test...done. Dec 24 13:21:57.000 [warn] Cannot make an outgoing connection without a DirPort. Dec 24 13:21:57.000 [warn] Cannot make an outgoing connection without a DirPort. Dec 24 13:21:57.000 [warn] Cannot make an outgoing connection without a DirPort. Dec 24 13:21:57.000 [warn] Cannot make an outgoing connection without a DirPort. Dec 24 13:21:57.000 [warn] Cannot make an outgoing connection without a DirPort. Dec 24 13:21:57.000 [warn] Cannot make an outgoing connection without a DirPort.

3 2

Reset torrc file
by Sec INT 24 Dec '16

24 Dec '16

Hi I upgraded all relays and exits to 0.2.9.8 but the torrc file was then renamed on all of them when the daemon restarted automatically - this meant the torrc file was then recreated as defaut losing all my settings and all relays exits were not working - this hasnt happened in all other upgrades to new versions but was pretty inconvenient when having to go back and replace all torrc files - is this normal? Cheers Mark B Snaptor.co.uk (non commercial)

3 3

Re: [tor-relays] What's a "useful" relay?
by balbea16 24 Dec '16

24 Dec '16

Hi There I am actually a little bit confused now. I am one of (as Rana knows) those Pi 3 based OR operators with daily changing IP address. My consensus weight is about 5,000, with a max. of 1,400 connections. I would like to recomment, that the TOR org should publish minimum requirements to run a relay. And, if my kind of relays would bring disadvantage to the network, I would shut it off. So far, I think, that small and large relays in combination are good for anonymity. Mike

3 3

2bithacker.net relays: please specify MyFamily in torrc
by nusenu 24 Dec '16

24 Dec '16

Hi Chip Marshall, thanks for adding so many new FreeBSD relays! Please do not forget to set the MyFamily parameter in your torrc configuration to tell clients your relays belong to a single operator. Since you know ansible already you might also use it to do that automatically. If you need help with the MyFamily option let us know. thanks, nusenu https://github.com/nusenu/ansible-relayor ornetradar(a)riseup.net: > 2016-12-23 > ----------------------------------------------------------------------------------------------------------------------- > Up|Ext|JoinTime| IP | AS | CC | ORp | Dirp | OS | Version | Nickname | eFamlen > ----------------------------------------------------------------------------------------------------------------------- > 1 | 0 | 02:32:38 | 82.196.8.232 | None | nl | 9090 | 9030 | FreeBSD | 0.2.8.11 | 2bitnlams02 | 1 > 1 | 0 | 02:32:32 | 46.101.21.201 | Digital Ocean, | gb | 9090 | 9030 | FreeBSD | 0.2.8.11 | 2bitgblon01 | 1 > 1 | 0 | 02:32:38 | 139.59.0.37 | Digital Ocean, | in | 9090 | 9030 | FreeBSD | 0.2.8.11 | 2bitinblr01 | 1 > 1 | 0 | 02:32:35 | 162.243.115.59 | Digital Ocean, | us | 9090 | 9030 | FreeBSD | 0.2.8.11 | 2bitusnyc02 | 1 > 1 | 0 | 02:32:35 | 45.55.50.151 | Digital Ocean, | us | 9090 | 9030 | FreeBSD | 0.2.8.11 | 2bitusnyc03 | 1 > 1 | 0 | 02:32:35 | 107.170.205.8 | Digital Ocean, | us | 9090 | 9030 | FreeBSD | 0.2.8.11 | 2bitussfo01 | 1 > 1 | 0 | 02:32:34 | 159.203.33.54 | Digital Ocean, | ca | 9090 | 9030 | FreeBSD | 0.2.8.11 | 2bitcator01 | 1 > 1 | 0 | 02:32:37 | 138.68.0.4 | Digital Ocean, | us | 9090 | 9030 | FreeBSD | 0.2.8.11 | 2bitussfo02 | 1 > 1 | 0 | 02:32:34 | 188.166.241.75 | Digital Ocean, | sg | 9090 | 9030 | FreeBSD | 0.2.8.11 | 2bitsgsin01 | 1 > 1 | 0 | 02:32:33 | 46.101.166.19 | Digital Ocean, | de | 9090 | 9030 | FreeBSD | 0.2.8.11 | 2bitdefra01 | 1 > 1 | 0 | 02:32:33 | 188.166.41.46 | Digital Ocean, | nl | 9090 | 9030 | FreeBSD | 0.2.8.11 | 2bitnlams03 | 1 > 1 | 0 | 02:32:32 | 198.199.72.150 | ServerStack, In | us | 9090 | 9030 | FreeBSD | 0.2.8.11 | 2bitusnyc01 | 1 > Fingerprints: > C3F631DE3EC41854168600AE1AE5728A2EA55CBC,0386ADA6F685FABB04E529C5ED49C3DCFB92A73B,2685BFE15151FEB867E1CD27DCACFB8DA39002E5,D93DDF11BD3F58403A2A94EA62C7FA3D415E9FDF,A144C89AEAD0F9CD38A90A1F2FDF9B21592E6799,F45A1231CD1EC9096FD65142E50B940B3E2B384B,71A61E23D16187ACED135530B606FE052CFF763C,6CF9DFBA9B9304706781F10EB4787DB1BFBFF048,E3BC5F5196C140903D3D46029C2340C79C9BF17C,E7EEA1B771C1DF30684DC200338EA7F6EBAF3858,04FBD9ADF8947F925C4C5D3A57A9B0215251EE7A,E4AE28405E6D1D14E0681491A27FFDDC06643B77 >

1 0

Re: [tor-relays] [tor-r@elays] What's a "useful" relay?
by Rana 24 Dec '16

24 Dec '16

@Ivan >If you think that your relay is underrated or has poor performance try to adjust your hardware/settings. Anyway almost every relay operator has this kind of "operator anxiety". Don't worry. ;) It is not about anxiety. The last thing that would cause anxiety for me is the possibility to find another cool project for my Pi :) >If there were only blazing fast relays it would decrease anonymity because these relays would be placed in some datacenters and operated by small amount of people (entities). >Tor network needs all kinds of relays to be strong. Diversity is about platform, location, connectivity, etc, etc. While I hold the same opinion as you (intuitively) I am interested not in intuition but in in a sober technical analysis, and not in words of encouragement, or in the customary "thank you thank you thank you for running a relay" I hear opinions here that small relays are not really useful, and about small bridges I heard here that they are actually causing DAMAGE. Those opinions were backed by technical arguments, here are a few: - the numerous small relays that change their IP addresses burden the network unnecessarily with frequent re-publishing of their descriptors - small relays that carry a small number of circuits actually DESTROY anonymity since the small number of circuits going through them makes it easier to de-anonymize traffic; - anonymity is much better served by a few large relays since they carry a lot of circuits simultaneously, and for this reason DirAuths try to saturate them before they direct traffic to small relays - the connections through small relays are quickly saturated, making using the internet a horribly slow and unpleasant experience - Isis, the bridge db and bridge authority operator, has asked Tor people who make decisions NOT to recommend that people run bridges on their small residential connections, because the need to re-distribute information about changed IP addresses is a major hurdle towards bridge adoption Or as one DirAuth operator summarized it: "On balance, the very small relays do not contribute enough resources compared to the associated costs to be worthwhile." All of which is exactly the opposite of what you are saying and what was also my intuitive opinion. So I am interested to know if there are solid, TECHNICALLY SOUND opinions in favor of use of small relays. If running a small relay is just for feeling good and displaying political support for privacy rights, then I am outta here. I feel good already and I have other means of expressing my political support. Rana

2 1

Tor Relay on ARM server Marvell Armada 370/XP
by Fabio Pietrosanti (naif) - lists 23 Dec '16

23 Dec '16

Hello, i'm experimenting Tor setup on very cheap servers from scaleaway.com that run a quad-core ARM Marvell Armada 370/XP servers but have unlimited bandwidth. Those are Soc platform: http://natisbad.org/NAS2/refs/Marvell_ARMADA_370_SoC.pdf I saw no information on torproject mailing list about those SOC. I'm trying to push the limits and i saw that those have a crypto acceleration support: https://www.kernel.org/doc/Documentation/devicetree/bindings/crypto/marvell… However with kernel 4.5.7 it does not really work and loading of marvel-cesa gives out error: [6.841862] marvell-cesa: probe of d0090000.crypto failed with error -22 :( I've only built latest Tor 0.2.9 with -O9 -mcpu=marvell-pj4 -mtune=xscale and the Tor Relay is at https://atlas.torproject.org/#details/82C63C5D61D17557B7C5D0E7FDC545A2B6B6B… . Does someone have experienced optimizing and tuning Tor specifically on ARM processors to understand how far those could be optimized? -naif

5 7

What's a "useful" relay?
by Rana 23 Dec '16

23 Dec '16

So - what's the metric for calling a middle relay "useful"? Is it the total number of bytes that it relays daily? https://atlas.torproject.org/#details/707A9A3358E0D8653089AF32A097570A96400C C6 is sending about 0.85 GB every 24 hours. Is it a "useful" relay?

2 1

Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP
by Rana 23 Dec '16

23 Dec '16

@Patrice: Yes both relays started with brand new identities and the one that is now clinically dead (nickname ZG0) has been wiped out and restarted with a new fingerprint AND a new IP address as I have a dynamic one and I rebooted my router to get a new one). Did not help, so obviously this has everything to do with the network and how dirauths/bwauths test the connection and vote, and absolutely nothing to do with the identity of the relay See my previous messages to confirm that this has absolutely nothing to do with the capabilities of the Pi, which are a gross overkill for the use of (nickname) GG2 that the dirauths and bwauths allow. -----Original Message----- From: tor-relays [mailto:tor-relays-bounces@lists.torproject.org] On Behalf Of Patrice Sent: Thursday, December 22, 2016 2:57 AM To: tor-relays(a)lists.torproject.org Subject: [tor-relays] @Rana - with reference to: Unwarranted discrimination of relays with dynamic Hi, I`ve read your post and questions, also about your 2 Raspberry PIs with the same setting but different locations. I thought about it and my question is: Did these to PIs got a new fresh identity on day zero? If not, it`s worth a try, probably. Kill the old identities and let them by. My fundamental idea is (and that`s why I am writing this): Does my behaviour with the relay (restarting, upgrading, not be onlinening) effect the measurement and therefore the throughput of my relay? Cheers, Patrice _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

7 15

Re: [tor-relays] Is AES-NI enabled in tor?
by Patrice 23 Dec '16

23 Dec '16

> Please don't mix multiple questions into one thread. Sorry, my bad. > Tor does not implement crypto itself (mostly) and relies on a > cryptolibrary (which is OpenSSL/LibreSSL/etc) instead. Thus you should > check if AES-NI is enabled in your cryptolibrary. > > An excerpt from StackOverflow answer [1] about it: > > $ openssl speed -elapsed -evp aes-128-cbc > > $ OPENSSL_ia32cap="~0x200000200000000" openssl speed -elapsed -evp > aes-128-cbc > > "Output of the first line should be significantly faster than the > second." If there is no AES-NI enabled in "OpenSSL" these two should > give similar results. I couldn't do that test. OpenSSL was not installed. After I installed it I could perform that test and it was positive. Here is the output: $ openssl speed -elapsed -evp aes-128-cbc You have chosen to measure elapsed time instead of user CPU time. Doing aes-128-cbc for 3s on 16 size blocks: 33370007 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 64 size blocks: 13118341 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 3915543 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size blocks: 1029134 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 8192 size blocks: 130438 aes-128-cbc's in 3.00s OpenSSL 1.0.1t 3 May 2016 built on: Fri Sep 23 17:53:23 2016 options:bn(64,64) rc4(16x,int) des(idx,cisc,16,int) aes(partial) blowfish(idx) compiler: gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wa,--noexecstack -Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 177973.37k 279857.94k 334126.34k 351277.74k 356182.70k $ OPENSSL_ia32cap="~0x200000200000000" openssl speed -elapsed -evp aes-128-cbc You have chosen to measure elapsed time instead of user CPU time. Doing aes-128-cbc for 3s on 16 size blocks: 6232419 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 64 size blocks: 1776077 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 454887 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size blocks: 114409 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 8192 size blocks: 14327 aes-128-cbc's in 3.00s OpenSSL 1.0.1t 3 May 2016 built on: Fri Sep 23 17:53:23 2016 options:bn(64,64) rc4(16x,int) des(idx,cisc,16,int) aes(partial) blowfish(idx) compiler: gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wa,--noexecstack -Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 33239.57k 37889.64k 38817.02k 39051.61k 39122.26k But it is a little confusing for me because there is this line in the logs: Tor 0.2.9.8 (git-a0df013ea241b026) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1t and Zlib 1.2.8. From that I thought Tor used already OpenSSL but it wasn't installed. :S I bought this board with this CPU (incl. AES-NI support) because I thought it would give a benefit. > N.B. AES-NI is not a feature of*motherboard* - it's CPU instructions > (NI stands for "New Instructions"). I simply forgot that. ;) Cheers, Patrice

2 1

Re: [tor-relays] tor-relays Digest, Vol 71, Issue 93
by Patrice 22 Dec '16

22 Dec '16

Thank you! That was already the answer. :) > You will not see anything in logs until this value isn't good and was > adjusted by tor. For details, see compute_real_max_mem_in_queues() > function in /src/or/config.c. Cheers, Patrice

1 0

A Question about aes-ni and the use of RAM.
by Patrice 22 Dec '16

22 Dec '16

Hi, does anyone know if the aes-ni support of the motherboard is used by default? (I saw nothing in the logs.) At the beginning I thought so but than I stumbled upon this option: > HardwareAccel 1 After I edited my torrc, this line showed up in my logs: Dec 21 17:34:41.000 [notice] Default OpenSSL engine for RSA is RSAX engine support [rsax] ------------------------------- And my other question is, does tor recognize this option? > MaxMemInQueues 7000 MByte Because I see nothing in the logs. I am not 100% sure but I think tor gave a feedback when I used this option in the earlier versions. Cheers, Patrice

2 2

@Rana - with reference to: Unwarranted discrimination of relays with dynamic
by Patrice 22 Dec '16

22 Dec '16

Hi, I`ve read your post and questions, also about your 2 Raspberry PIs with the same setting but different locations. I thought about it and my question is: Did these to PIs got a new fresh identity on day zero? If not, it`s worth a try, probably. Kill the old identities and let them by. My fundamental idea is (and that`s why I am writing this): Does my behaviour with the relay (restarting, upgrading, not be onlinening) effect the measurement and therefore the throughput of my relay? Cheers, Patrice

1 0

confusing error from "tor --verify-config"
by Patrice 21 Dec '16

21 Dec '16

Hi folks, my relay is running fine [zeiberschnitzel] and it got no errors. I can`t see anything in the logs either. But when I do the command #tor --verify-config I got these outputs: Dec 20 18:20:27.946 [notice] Tor v0.2.8.11 (git-9fc59eddc17a726a) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1t and Zlib 1.2.8. Dec 20 18:20:27.947 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning Dec 20 18:20:27.947 [notice] Read configuration file "/etc/tor/torrc". Dec 20 18:20:27.956 [warn] /var/lib/tor is not owned by this user (root, 0) but by debian-tor (105). Perhaps you are running Tor as the wrong user? Dec 20 18:20:27.957 [warn] Failed to parse/validate config: Couldn't access/create private data directory "/var/lib/tor" Dec 20 18:20:27.957 [err] Reading config failed--see warnings above. I would say it`s nothing tragical but I am curios about it. Thanks and Cheers

4 3

Re: [tor-relays] confusing error from "tor --verify-config"
by Patrice 21 Dec '16

21 Dec '16

Hi, > My bad, shell for debian-tor is set to /bin/false and so it prevents any > command from running. Setting shell should "fix" this: > > su debian-tor -s /bin/sh -c "tor --verify-config" > > -- > Ivan Markin thank you for your hint, that solved it. :-) Now I`ve got this beautiful non error output: # su debian-tor -s /bin/sh -c "tor --verify-config" Dec 21 14:10:43.078 [notice] Tor 0.2.9.8 (git-a0df013ea241b026) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1t and Zlib 1.2.8. Dec 21 14:10:43.078 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning Dec 21 14:10:43.078 [notice] Read configuration file "/etc/tor/torrc". Configuration was valid Cheers, Patrice

1 0

Re: [tor-relays] confusing error from "tor --verify-config"
by Patrice 21 Dec '16

21 Dec '16

Hi, > I would suggest running tor --verify-config as debian-tor user instead of > root After I run the following command I`ve got no output. Is this correct then? I expected a few lines somehow. su -c "/etc/init.d/tor --verify-config" debian-tor > I would suggest not running tor as root .:) > As root you can do: > su debian-tor "tor --verify-config" > I am not running tor as root. Tor runs as "debian-tor". I installed it from the repositories and changed nothing in the permissions. Cheers, Patrice

3 2

Updating our IP Address
by diffusae 20 Dec '16

20 Dec '16

Hi! Yesterday I encountered a strange IP address update via DynDNS: Dec 19 23:00:32.000 [notice] Your IP address seems to have changed to 176.10.104.240 (METHOD=RESOLVED HOSTNAME=my.dyndns.cc). Updating. Dec 19 23:00:32.000 [notice] Our IP Address has changed from xx.xx.xx.xx to 176.10.104.240; rebuilding descriptor (source: METHOD=RESOLVED HOSTNAME=my.dyndns.cc). Dec 19 23:00:36.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Dec 19 23:04:32.000 [notice] Your IP address seems to have changed to xx.xx.xx.xx (METHOD=RESOLVED HOSTNAME=my.dyndns.cc). Updating. Dec 19 23:04:32.000 [notice] Our IP Address has changed from 176.10.104.240 to xx.xx.xx.xx ; rebuilding descriptor (source: METHOD=RESOLVED HOSTNAME=my.dyndns.cc). Dec 19 23:04:34.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Dec 19 23:08:32.000 [notice] Your IP address seems to have changed to 176.10.104.240 (METHOD=RESOLVED HOSTNAME=my.dyndns.cc). Updating. Dec 19 23:08:32.000 [notice] Our IP Address has changed from xx.xx.xx.xx to 176.10.104.240; rebuilding descriptor (source: METHOD=RESOLVED HOSTNAME=my.dyndns.cc). Dec 19 23:08:34.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Dec 19 23:13:32.000 [notice] Your IP address seems to have changed to xx.xx.xx.xx (METHOD=RESOLVED HOSTNAME=my.dyndns.cc). Updating. Dec 19 23:13:32.000 [notice] Our IP Address has changed from 176.10.104.240 to xx.xx.xx.xx; rebuilding descriptor (source: METHOD=RESOLVED HOSTNAME=my.dyndns.cc). Dec 19 23:13:36.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Dec 19 23:22:38.000 [notice] Self-testing indicates your DirPort is reachable from the outside. Excellent. Publishing server descriptor The DynDNS client updates the IP every five minutes. It looks like somebody has tried to changed / update the IP manually or via spoofed update (DNS) entry. I also recognized the change at the WebGUI of the DynDNS Provider. The changed IP address is an exit node (0111BA9B604669E636FFD5B503F382A4B7AD6E80) in Switzerland. I don't think, that this is a bug in Tor 0.2.9.7-rc. Are there any possible attacks to Tor relays, if they are using a faked IP address? Normally this shouldn't work. Even if the traffic is redirected to an exit node, but I am not sure. Well, it should be safer to use autodetection of the IP though Tor. Regards,

3 4

Report of home relay experience (cont'd)
by Rana 20 Dec '16

20 Dec '16

Of the two relays that I run from two different residential premises for some time now, the first, nicknamed ZG0 (has absolutely stable dynamic IP and Stable flag for many days now) is clinically dead despite the measured BW of 100 kbytes/sec. The second, nicknamed GG2 (static IP, Stable, Fast, HSdir) is not dead but is relaying only about 0.5 gbytes per day. That's an average rate of just 4% of its never-changing measured BW of 153 Kbytes/sec (which is equal to 100% of its bandwidth limit in torrc). It currently has 900 connections and made over 16,000 circuit handshakes in the last 6 hours, all of them successful. The two relays run on identical Pies with the same configuration except the bandwidth limit (which is higher on ZG0 than on GG2) and negligible CPU and memory utilization. Comments? Rana

3 3

confusing error from "tor --verify-config"
by Patrice 20 Dec '16

20 Dec '16

Hi folks, my relay is running fine [zeiberschnitzel] and it got no errors. I can`t see anything in the logs either. But when I do the command #tor --verify-config I got these outputs: Dec 20 18:20:27.946 [notice] Tor v0.2.8.11 (git-9fc59eddc17a726a) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1t and Zlib 1.2.8. Dec 20 18:20:27.947 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning Dec 20 18:20:27.947 [notice] Read configuration file "/etc/tor/torrc". Dec 20 18:20:27.956 [warn] /var/lib/tor is not owned by this user (root, 0) but by debian-tor (105). Perhaps you are running Tor as the wrong user? Dec 20 18:20:27.957 [warn] Failed to parse/validate config: Couldn't access/create private data directory "/var/lib/tor" Dec 20 18:20:27.957 [err] Reading config failed--see warnings above. I would say it`s nothing tragical but I am curios about it. Thanks and Cheers

1 0

Re: [tor-relays] zencurity.dk relays: MyFamily update required
by nusenu 20 Dec '16

20 Dec '16

Henrik Lund Kramshøj: > So sorry, I have updated config with family thanks for fixing it.

1 0

Tor blocked in Turkey as government cracks down on VPN use (Turkey Blocks 2016-12-18)
by Ralph Seichter 19 Dec '16

19 Dec '16

https://turkeyblocks.org/2016/12/18/tor-blocked-in-turkey-vpn-ban/

1 0

Flags?
by balbea16 19 Dec '16

19 Dec '16

Hi There, I assume, that this has been discussed here already pretty often. However, it seems to be, that the "stable flag" is only assigned to relays with a static, or at least long lasting, IP address. It also seems to be, that the stable flag is mandatory to get the guard flag. If so, that would mean: Dynamic address = no chance to obtain the guard flag. Is that the truth? Tnx Mike

4 3

asymmetry in connections
by Rana 19 Dec '16

19 Dec '16

On one of my relays I have 389 inbound, 38 outbound connections and 15 circuits What's the connection between these 3 numbers and why such asymmetry in inbound and outbound?

3 4

Cloning a relay - duplicate fingerprint
by Patrick DERWAEL 19 Dec '16

19 Dec '16

Hi list, I'm running a relay on a CentOS VM As I have lots of resources available, I wanted to duplicate that VM to bring more bandwidth to the Tor network --> cloned VM, changed IP and mac adresses, OS hostname, Tor nickname and restarted the Tor service Surprise: the fingerprint of the clone is identical to the one of the source VM I have stopped my clone to avoid any issue, but I guess I must have missed something... Any clue would be highly appreciated !!

5 6