- tor-relays - lists.torproject.org

Relay Node not acquiring Guard Flag.
by Sebastian Urbach 24 Feb '15

24 Feb '15

Hi, On 02/23/2015 06:44 PM, Sebastian Urbach wrote: > Because the criterias changed a while ago, only the fastest 25% of the > Relays are Guards anymore. >BTW, what's about minimum uptime ? Details for all the flags can be found here: https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt -- 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.

2 1

Relay Node not acquiring Guard Flag.
by Beagle Bone 23 Feb '15

23 Feb '15

Hey folks. 3xBT here, admin of the node of the same name. I was wondering why my node has yet to pick up the Guard flag: Fingerprint: D937161730610A5D66BDED6CF4D5C9692566D9FE Feb 23 06:25:05.000 [notice] Tor 0.2.4.24 (git-e3c61213fb2dc49a) opening new log file. Feb 23 06:25:05.000 [notice] Configured to measure directory request statistics, but no GeoIP database found. Please specify a GeoIP database using the GeoIPFile option. Feb 23 06:27:22.000 [notice] Your DNS provider gave an answer for "lya67fieutqf6", which is not supposed to exist. Apparently they are hijacking DNS failures. Trying to correct for this. We've noticed 1 possibly bad addre$ Feb 23 09:57:31.000 [notice] Heartbeat: Tor's uptime is 59 days 6:02 hours, with 153 circuits open. I've sent 414.64 GB and received 394.25 GB. Feb 23 09:57:31.000 [notice] Average packaged cell fullness: 97.080% Feb 23 09:57:31.000 [notice] TLS write overhead: 3% Feb 23 09:57:31.000 [notice] Circuit handshake stats since last time: 4059/4059 TAP, 3977/3977 NTor. Feb 23 15:02:49.000 [notice] New control connection opened. Feb 23 15:57:31.000 [notice] Heartbeat: Tor's uptime is 59 days 12:02 hours, with 158 circuits open. I've sent 416.55 GB and received 396.07 GB. Feb 23 15:57:31.000 [notice] Average packaged cell fullness: 97.087% Feb 23 15:57:31.000 [notice] TLS write overhead: 3% Feb 23 15:57:31.000 [notice] Circuit handshake stats since last time: 6032/6033 TAP, 4055/4055 NTor. Feb 23 17:23:54.000 [notice] New control connection opened. Additional info: When traffic is 4Mbit/sec, CPU and memory load is at ~50%. I'm also wondering why the log is only being written when I'm looking at it, and if there was anything I could do to increase usage of allotted bandwidth. -3xBT

3 2

drop in bandwith - because of fail2ban rule?
by tor＠viisauksena.de 23 Feb '15

23 Feb '15

hi i am wondering , because i constantly becoming less and less traffic / or given Bandwidth for a Tor exit relay with a bunch of flags .. the exit is on a debian, vserver with quit a lot of machine power behind, has it own IPv4 and there is also enough bandwidth (i checked this regulary with speedtests or fake downloads of whatever distros) https://atlas.torproject.org/#details/2AC2306BD625A9DD75532886842C268C3CDBB… i didnt change anything in configuration, beside one small thing after getting dozens of apache errorcode 504 port 80 and 443 to the Tor-IPv4.. and so i startet to make a fail2ban rule, because this doesnt make sense, also this comes often from a variety aof IPv4 en block from russia, china, korea (mostly) - so i optet for fail2ban more than ignoring these errors. This is the only thing i could imagine which connects to the network drop (ok some internet police whitehat watchers argue there is bad traffic here and than .. but this is "normal" i guessed for tor-exit) So i turned my rule of some 2-3 days, to see if this makes the drop in bandwidth - no effect. So i restartet back the fail2ban rule. So my question - tor hides in port 80 / 443 traffic - is this what i mistakingly block / or interfere .. or how this drop from near 14 Mb to 1,9 Mb is explainable? (while normal traffic on server goes well) thx, viisauksena (for completeness example of logoutput and fail2ban-regex ) # basicly i want to stop these lines # default-178_254_XXXXXX:443 104.245.96.249 - - [10/Feb/2015:16:52:07 +0100] "GET /" 400 549 "-" "-" [Definition] failregex = [^ ]+ <HOST>.*"GET /" 400 5[0-9][0-9]

1 0

Strong bumps in traffic with 0.2.6.3
by Christian Sturm 22 Feb '15

22 Feb '15

Hello, I noticed on my Tor relay that deploying 0.2.6.3 resulted in the bandwidth going up an down a lot which can be seen here: https://globe.torproject.org/#/relay/CE75BF0972ADD52AF8807602374E495C815DB3… It looks like I am not the only one. This CCC hosted relay (different OS, provider, etc.) appears to have the same thing happening: https://globe.torproject.org/#/relay/9BDF3EEA1D33AA58A2EEA9E6CA58FB8A667288… It is hard to filter relays per version right now (maybe something onionoo could support?). Are others experiencing the same problems?

3 3

Running obfs4proxy on Debian Stable
by isis 22 Feb '15

22 Feb '15

Hello, I requested that the obfs4proxy package in Debian jessie be ported to wheezy-backports, [0] however, it seems this is extremely unlikely to happen because it would mean backporting pretty much every Golang package in existence. I would be super stoked if we could make it as easy and seamless as possible for the Bridge operators who are still running obfs2 (!!) to move to supporting better, newer Pluggable Transports. Currently recommended PTs to run are: obfs3, obfs4, scramblesuit, and fteproxy. When Tor Browser 4.5 becomes stable (probably in mid-April 2015), we'll want lots more obfs4 Bridges! For the super adventurous sysadmins who'd like to try Yawning's experimental new post-quantum PT, Basket [1] is one of the newest PTs. We should probably come up with some easy instructions for operators of Tor Bridge relays who are running Debian stable, such as adding an Apt pin to pull in only the obfs4proxy package and its dependencies from Debian jessie and keep everything else pinned to stable. If someone has done this, or has another simple solution, would you mind writing up some short how-to on the steps you took, please? [0]: http://lists.alioth.debian.org/pipermail/pkg-anonymity-tools/Week-of-Mon-20… [1]: https://github.com/yawning/basket -- ♥Ⓐ isis agora lovecruft _________________________________________________________ OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 Current Keys: https://blog.patternsinthevoid.net/isis.txt

5 10

Tor relay only IPV6
by cmar433＠yandex.com 21 Feb '15

21 Feb '15

Hello, i try to run tor as relay .. but i have not any ipv4 adress.. is there any posibilities run tor as realy only for ipv6 adress ? for me seems is not functioning. (Debian wheezy) port 9001 is open but "conection refused" if i try IPV6 portscan I try open 22 only for test trough IPV6 portscan .. ist OK . port opened Any IDEA ? Thanks

4 4

load balance across multiple WAN?
by Rupert Roe 21 Feb '15

21 Feb '15

Hi, I currently run this middle node from a residental VDSL connection: https://atlas.torproject.org/#details/D0D6992508E64E28A77373B82798AB196BFA5… I am currently limited by the upload speed of my connection (~20MBit), I was wondering if I had another VDSL connection installed would I be able to load balance the upload of the relay across the two connections? Or would this mess up the routing for my relay? I.e. traffic comes in to the single published relay IP (which is OK as it's ~80MBit download). Then the relay can push ~40MBit upload load balanced across two 20MBit connections. Would it be problematic because the traffic would come from two different IPs, one of which does not match the published IP for the relay? I hope that question makes sense?? Thanks -- +447867537146 skype: rupertroe1 --

3 3

eventdns: Address mismatch on received DNS packet.
by Jeremy Olexa 20 Feb '15

20 Feb '15

Hi List, I'm seeing these messages in one of my relays. Pretty often, too. eventdns: Address mismatch on received DNS packet. Apparent source was <IP>:<port> I've searched this and found references[1] to a faulty resolver of some type and torservers.net ignores the message[2]. I use my ISPs resolvers which are physically close to the server. In an attempt to fix this, I've added a caching local resolver to my server and configured resolv.conf properly (problem persists). Then I switched to Google DNS with caching in front (problem persists). Can anyone clarify what the problem may be? Or is it no problem at all? [1]: https://lists.torproject.org/pipermail/tor-relays/2013-July/002209.html [2]: https://lists.torproject.org/pipermail/tor-relays/2011-December/001034.html Thanks! -Jeremy

6 5

(no subject)
by Volker Mink 20 Feb '15

20 Feb '15

3 2

Again Hibernations vs. limits, for the extreme case
by Filippo Valsorda 18 Feb '15

18 Feb '15

I run a relay with decently high bandwidth, but limited monthly transit (3TB out). https://globe.torproject.org/#/relay/2EC042F4274CC8A54381C78E8D1BF322FA26A0… I gathered from previous discussions that a fast node that goes into hibernation is more beneficial to the network than an artificially throttled node. So I set a hibernation limit and no speed limit. However, it looks like my node is fast enough to burn all the transit in a couple of days when it has consensus, and (1 month - 2 days) is enough time to get forgotten. So I'm probably stuck in a cycle of month 1. slowly ramp up speed and consensus; go into hibernation for a few days; lose the Guard flag (-> get more traffic); month 2. burn all the transit in 2 days go into hibernation for >25 days GOTO month 1 Is it still the case that I shouldn't put throttling in, even if this means that each other month I'll run at really low speed to ramp up consensus? Or should I combine the Hibernate setting with a reasonable limit of maybe 1 MB/s? Or maybe use daily limits in this case? (Please CC me, I might not read in-list-only replies) Thanks, Filippo

2 1

Re: [tor-relays] "Very Safe" Exit Policy
by Raynardine 18 Feb '15

18 Feb '15

On 02/18/2015 09:01 AM, Chris Patti wrote: > Bleah. > > Pesky humans:) Yes, it's always the problem of fitting imperfect components into a perfect system that ruins everyone's day. :P

1 0

"Very Safe" Exit Policy
by Stephen R Guglielmo 18 Feb '15

18 Feb '15

Hi list, I was looking for suggestions/discussion on very conservative policies for an exit relay. I run a relay now that is "reject *:*" and I wanted to open up a few exit ports. I don't want to open up major ports due to potential abuse issues. My server host states that, although they do allow Tor, there is a chance of the relay being terminated at their will [1]. I was considering using a whitelist exit policy and opening up only the following ports to be "safe": 43 - WHOIS protocol 53 - DNS 389 - LDAP 464,543,544,749 - Kerberos 531 - AOL IM 636 - LDAP over SSL 706 - SLIC 873 - rsync 5190 - ICQ and AOL Instant Messenger 5222,5223,5269,5280,5281,5298 - XMPP 5353 - Multicast DNS 5999 - CVSup 8332,8333 - Bitcoin 9091 -Transmission (BitTorrent client) Web Interface 11371 - OpenPGP key server 64738 - Mumble/Murmur I constructed the list based on a quick skimming of the WP ports list [2]. I suspect allowing IRC would eventually be grounds for my host to terminate my relay. This would be my first time running an exit relay and I'd be happy to hear advice and suggestions! Thanks, Steve [1] https://trac.torproject.org/projects/tor/wiki/doc/ISPCorrespondence#OVH [2] https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers

9 11

new ansible-tor features: automatic instance configuration + automatic MyFamily generation (PATCH)
by Nusenu 18 Feb '15

18 Feb '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi David, thanks for creating ansible-tor. I added two features that are crucial to me and maybe useful for others as well. If you like it, feel free to merge - this is my first ansible experience and it is lightly tested. Example: lets say you have added a new server to your inventory. The server has 3 public IP addresses (1.1.1.1, 2.2.2.2, 3.3.3.3). After running ansible-tor with the new changes you will have the following 6 tor instances/ORPorts running (without manually specifying IP addresses first): 1.1.1.1:80 1.1.1.1:443 2.2.2.2:80 2.2.2.2:443 3.3.3.3:80 3.3.3.3:443 including MyFamily configuration across all servers/instances. regards, Nusenu changes ======= - - auto instance deployment without manual IP/ORPort configuration (new) starts 2 tor instances per available IP address by default makes manually specifying IP addresses and ORPorts via proc_instances obsolete ORPorts default to 80 and 443 (DirPort not added yet) replace "single.yml" + "instances.yml" -> instance.yml only (handles both cases dynamically) - - MyFamily autogeneration (new) Keeping all relay fingerprints in sync is probably one of the most annoying tasks for a relay operator managing multiple relays, now ansible takes care of this (all relays need to be in the 'relays' group) - - directory structure (changed) defaults: configs -> /etc/tor/<ip>_<orport>.torrc log dir -> /var/log/tor/<ip>_<orport>.log datadir -> /var/lib/tor/<ip>_<orport>/ pid dir -> /var/run/tor/<ip>_<orport>.pid (previously everything was located in /etc) - - added torrc sanity check (tor --verify-config ) (new) - - torrc files are owned by root (previously owned by $tor_user) - - the pid file check has been removed since the file is not required to exist (it will be created when tor starts) open - ----- - - it does not take care of instance removals yet (in case IPs are no longer available or amount of ORPorts have been reduced) - - allow opt-out -> only 1 tor instance per host (even if there are more IPs available) - - DirPort support - - detect RFC1918 IPs (opt-in) -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJU4i+CAAoJEFv7XvVCELh0y+kP/i4Mn/XClgXYloGdgWU9UPR+ Y8yZv97FvJOMPI40tccPKcNPcLQFRvGFYkR96sAOGoMfbJT/tQeH2dOxwAEF31mv afFkLsVPAOpNzlyO2qP1mkLtB/aYXtZ6jb2+JtpAhVBLKOVFBN2nNRiwdgFYZFGy f0ZIp7xyR9XcAhXo4nc0hlETREAnbMOgFGM6vqqIpJfimF3liE6va5HNw2CD+7Zd MmeIOuVNvQh09SiYf48AJpBeBRoybOvmFIPphtXEYlC/y6cd/IyUIYdOBuaLa5td vQnrQOC7TUgp74uarl0yaatOYOEagl0lrNeN6+Vgy5e0e12TgVccWW5ZosM1PBXG VH2FTfjHXUO+VN0p4xn6AS0dhWTRKb7isj3jpznTMsiq0AcvXM6DZjkzkcCPChVz jptdUbNvgpdP7j5X11iZniGpxVe7aFo2wCzgZORY1xMysiigJsL4M/nonr4YO4G9 w7kyNcco9gStklJSvOJXbfX4HrOCuWdq8hp4xubyON+5jpEUgMmG1o/v5NJANV4C CLzlz4kf9l9o351Z7DJQzilxzDEwe6oZwSWnsq+yB65Mgj5sUJnchi40iPLOHSUr DaVSSUxoZ8VVNYqqvGYb2fysYa7DsCgofsF/eXP4QyJp1WFNwc0ft6qIhyAGIDwx RfwQHrA+Lg95mdXDyr0B =QHkD -----END PGP SIGNATURE-----

4 15

Re: [tor-relays] new ansible-tor features: automatic instance configuration + automatic MyFamily generation (PATCH)
by Raynardine 17 Feb '15

17 Feb '15

On 02/17/2015 04:01 PM, Moritz Bartl wrote: > My algorithm. Hm. This all sucks because Tor still doesn't scale across > multiple cores. There should be more affordable dedicated host service providers that provide professionally overclocked servers. Liquid nitrogen isn't that expensive to generate, if you use solar power to make the electricity required more affordable. It seems dedicated servers are becoming less and less common as virtual private servers attract cheap customers. For things like Tor that are dumb and can only bind to a single core, overclocking and overvolting that one core professionally could be a practical business venture. Unfortunately, due to the nature of mixnets like Tor, unless a large number of equivalent service providers do it, the benefit provided is minimal at best. The Tor relay pool is strongest when the hosting providers are as diverse as possible. If 51% of Tor relays are hosted by the same company and in the same country, Tor may as well not exist.

1 0

Re: [tor-relays] Mozilla-Middles losing guard
by Raynardine 17 Feb '15

17 Feb '15

On 02/17/2015 02:59 PM, lpwzi9i84(a)use.startmail.com wrote: > ...but what we want are nonmalicious guards, right? If you want non-malicious guards, you may consider manually configuring bridge relays. Manually verifying and authenticating the identity of bridge relay operators is probably the only sure way to get non-malicious guard relays.

1 0

Re: [tor-relays] Mozilla-Middles losing guard
by lpwzi9i84＠use.startmail.com 17 Feb '15

17 Feb '15

at this very moment all of them got the flag, right. But theyre loosing it at seemingly random order. I kept an eye on Atlas for some time, at 18:00 (UTC+1) Mozilla13 was at 1.51 MB/s without Guardflag. On Tue, February 17, 2015 19:50, Nusenu <nusenu(a)openmailbox.org> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > >> i am wondering about losing of guard state of the Mozilla Middle >> Relays. > what makes you think they [1] lost guard flag? > > [1] https://atlas.torproject.org/#search/mozilla > https://consensus-health.torproject.org/consensus-health.html > > -----BEGIN PGP SIGNATURE----- > > iQIcBAEBCgAGBQJU442PAAoJEFv7XvVCELh0FbUP/27q3GoeFaqEEjRrd88w3S5C > PGhX0yPe/0zZzTCWwBR8GR44qm6XyO6rQloGVFJAbcUfPjZEvYSED3CVDfgiuoIb > t9mg4nH5W6ZMMGQJhT+wmKZTFOIK68nZpfmtlsrAfstbQ4NMj4QHOb1mDos+XnE5 > DPYvjmfiarVbghM5KsB6w8s26bqT/By5coxEdGOlHLv5E8iqUpCUYWP45FAcY7uE > MGp7smOheykVF7MsNHG8uhWaEp63jSKS0hgqAXYQJfyAheo5y+zuoA6rL+7J7CqK > 9VRRg33qmCnuT4uRrk51Ggdbl9yS2qtJEnPVzxGJc8433wKHut6PlNz0SnusLuDN > Hal0ndXp0ZjQrAysBvMGJ7pcR/7+pw3kmLSyXfszMZVh4gkkWjDXdfQa3kTORdJ2 > XrIs/E+IqhwEGt1Sj+CcQBLiVJ0Wp3HMFl94rVH0qB2UhracoJ+tCfEvmKW8fZWf > lKpAZYGUgROgI1NHyyaFnhxvCPxma/bLjqjShaDJNR5Dak8DFHqzHnP78Y4w9hZm > 5Kk54Tg+jqjWapnwHQwgIj+mk8KiacqMirjHm5gBGRa34E8TZmoyZgINE+yRH4cj > ogvopd2DJerDwOaYb66ed1r1gsg78eDfBPE27kwAzfsY3ur/G6JDCTv3vSsyoO5r > XABeYlaQuf760OikXwXV > =aJUd > -----END PGP SIGNATURE----- > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

4 5

Mozilla-Middles losing guard
by lpwzi9i84＠use.startmail.com 17 Feb '15

17 Feb '15

Hi, i am wondering about losing of guard state of the Mozilla Middle Relays. Is it cause of 1 physical machine handles 6 IP's, 2 Relays each? Maybe the total bandwidth should shared by 4 IP's, 2 Relays each to increase the chance to keep a bandwidth throughput beyond 2 MB/s. Guardstate will be rejected by falling below 2MB/s, right? Just wondering if the Mozilla setup could be more smoothed... cheers (this emailadress will expire automatically after 2 weeks)

2 1

Tor weather - signature not found
by mattia 16 Feb '15

16 Feb '15

Hi all, I have recently converted a bridge to a relay. Its fingerprint is 0D14A4498E7D1854696CC07548653EA4CD3CB2DA. I wanted to subscribe to Tor Weather but when I try I get the "We could not locate a Tor node with that fingerprint." error. Searching the web I found it was a common error years ago, but shouldn't be now. Any ideas about it? Thanks!

5 6

tor weather not sending emails?
by Nusenu 16 Feb '15

16 Feb '15

Hi, I subscribed to tor weather to get notifications in case something is wrong with a relay. Although the relay had several downtimes (>1 day), I never got an email. (I subscribed to with the minimal setting 1 hour) Did anyone get emails from tor weather in the past 2-3 weeks during downtimes? thanks!

5 8

Value of an unused bridge?
by Elliott Jin 14 Feb '15

14 Feb '15

Hi all, I've had an EC2 bridge <https://globe.torproject.org/#/bridge/FD0814BDD15B2E591B04868B988D87FC6D331…> up for 2 weeks, and it seems to have gotten no usage. I'm considering converting it into a middle relay instead, but before I do so, I'm just wondering: - Is there value in having a marginal unused bridge "in reserve"? - Is this value greater than that of an active middle relay? Thanks! -Elliott -- Anonymous Feedback <http://www.admonymous.com/eyjin>

4 4

Thoughts on new relay
by Niklas Femerstrand 10 Feb '15

10 Feb '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Moin, Our relay is online as of Jan 23 and recently I've been thinking about pivoting it into a bridge instead. The relay lives in Cambodia and may naturally be a bit off from the rest of the network (latency). Consensus weight is steadily increasing despite various initial downtime incidents, which you can see in Atlas graphs. (We've had some network upgrades and during a separate event even had a monkey yanking the eth from the nic.) Currently we advertise 435.66 KB/s and with our current ~9d 10h uptime we have downloaded 3.6 GB resp uploaded 3.7 GB. Theoretically our tubes fit 10 Mbps download and 30 Mbps upload. The question is whether the relay is worth keeping with its current setup or if we can contribute more by re-configuring into a bridge. Unfortunately it is very risky for us to allow exit traffic, but we <3 any cipher packet. Please advice! https://atlas.torproject.org/#details/94F806110B23E727AE8BAD74DD95B0EE0B7A8… Regards, King Kong -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJU2gGzAAoJEHxAR3sGx+rLTzEP/05TJK3vzfPe3kUjUfg0G/wm vlc1vZLshAvK/pE1mf2DqDSgnuxR+QHHJI8htJOaU5VJVMlnEy4nsF0uE76It1EW OLUo7+LU452Sx7XjyVYMKOu6OJ9kD1Cg6OkNT2HEIOR+57x7vNJTYr7oF0uNu6dt UzVFJKkM3Y1ca4GsMS2M/oXFw2jGrrvmx4DLHu2OSDwNumy3ndOETnZscVfErAMK A/K4JI0Ws6pInBRciEHdak9ZBkR/f9jYGPbUXOSwnJN6XIsawijTIbrRLfYiUcro 0wj6mZYqXgKRDOvP57UNkf5UaolADQb6ssiLkhhAGu+DHnTt5V8g2vkqtY3wU02N 823X7o3oNZYq5yZFTbexH8Al+ys9KvKlu5q0YRYvbBwvI/yGHyr/gEI7ufV+9tZ6 z9Mo2hCBsaM0vrikBzejhjSw5qc4HcwMKErlC3cHQHIbszryu1O0WY1G22pwYgss mAGDr6OcdeIdMyNcJlpyH8+jToRSJrkAwDSPdQz+IVMq785x0GnOo2uV2/7NTr2J +LVUjSjAenRhPX+TrAFFujNYXZf5uD/EUfsGyUyCdBhJ5PWsLjYQ/EYD6PToDX8P BdocR3XfxZS7nD5PYRDfyWNeckCL6VPrnZrgMGIYBEXAn7jhX608vzmZV7IU7mzv 3NrnDWpllK4M42hT7fXs =hV51 -----END PGP SIGNATURE-----

3 3

Is Bridges supposed to get a gurard flag?.
by Sasikantha babu 10 Feb '15

10 Feb '15

Hello All, I've been running a non-exit relay at home and a bridge on amazon cloud since dec-2014. And today I had noticed on atlas my bridge has got a guard flag and from the logs in the last 18 hours it had sent 4.73 GB and received 4.89 GB (finally I'm happy to see bandwidth being used on bridge). I've the following questions 1. Is a bridge supposed to get a guard flag ?. 2. Is there a difference between a guard flag of a relay and a guard flag of a bridge?. Thanks

2 1

question and concering about probability of exitnode
by tor＠viisauksena.de 10 Feb '15

10 Feb '15

hi, just want to note, i am proud to have an german exit node with 11Mbs .. but also concerned about this raising exit node probability, actually it reads for me like 1 of 400 tor-users is going through this exit (by recalculating a exit probability of 0.25 %) - this concerns me because it should not be so easy (running just some days on a vserver) and i don't know how high this will raise ? i mean, its easy for me to guess a nsa/gchq/bnd bad-ass-club can get some hundred vservers running, and get tor exclusively exits .. and guard (which was much more easy, i lost it because i quickly run out of maximum limit for a month, so i cut it, but the 1 day downtime lost me the guard flag) just my opinion .. and if you can show me some more information over the numbers of exits and guards and so on, i would be happy, cant believe there are so less many exit nodes out there ... thx, Jens

2 2

Minimizing service interruption when reloading torrc?
by Elliott Jin 09 Feb '15

09 Feb '15

Hi all, I'd like to reload torrc; I think I can do this by either restarting tor or by sending a SIGHUP to the tor process, but I'm not sure how much of a service interruption each of these approaches will cause. What's the best way to reload torrc (i.e. how can I do this in a way that minimizes the service interruption)? Thanks! -Elliott -- Anonymous Feedback <http://www.admonymous.com/eyjin>

3 3

Relay operators: help improve this hardening document?
by Nick Mathewson 07 Feb '15

07 Feb '15

Hi, all! There's a project going on to try to add instructions for hardening a Tor relay for security: https://trac.torproject.org/projects/tor/ticket/13703 The idea is that Tor could ship with some basic recommendations, and links to places to find more advice? Recently, "mmcc" has uploaded a new draft. Do we think this is better than nothing and worth shipping with Tor, or does it need big changes? If possible, please write comments on the trac ticket above: it will help keep all the discussion in one place. best wishes, -- Nick

7 6

Changes in network traffic pattern
by Hu Man 06 Feb '15

06 Feb '15

Hi All I have been running a tor relay for about a year and according to my munin graph It normally receives, on average, just under 2,000 incoming tcp connections on port 443 every 5 minutes. In the last few days that figure has increased to about 10,000 and spiked to about 19,000 incoming requests every 5 minutes. First thought was DDOS but traffic is not high enough to cause any problems. I did some digging and in a 5 minute period received the following requests to the port tor is listening on (number of requests and source ip address) 2722 SRC=107.167.22.79 1355 SRC=107.167.22.90 1334 SRC=104.37.244.131 1237 SRC=213.251.185.14 604 SRC=188.247.130.32 13 DST=178.200.216.58 7 SRC=92.63.110.232 6 SRC=5.196.8.208 6 SRC=200.76.82.231 6 DST=93.158.248.243 This is only the top 10 source ip addresses. I had a look and none of the top few seem to be tor relays. Just wondering if others are seeing a large number of requests from the above ip addresses or if it's just me. If it is just me then I can easily just block these ip addresses.

3 2

Avoiding using my own Exit
by Chris Tilt 06 Feb '15

06 Feb '15

Hello, When running a relay that is configured as an Exit, do you run the risk of your own TOR browsing sessions (initiated from the same private network) using the relay and effectively short-circuiting the location randomization? Note that I don't have a relay up yet, so my question may be lacking clarity. Cheers, Chris

2 1

TOR: Inbound, Outbound, Exit connections
by Ralph Bolliger 05 Feb '15

05 Feb '15

*Good evening ladies and gentleman* I'm running a TOR Exit for a few days now ( https://globe.torproject.org/#/relay/06BA80D9E1143CFAD835442142A3FA5A1E4FD9…) I'm also using TOR ARM in order to monitor TOR's performance, log messages and connections. When I have a look at the connections page on TOR ARM I read about «Inbound», «Outbound» or «Exit» connections. I searched the web already. But I wasn't able to find a site that explains in simple words what's the difference between «Inbound», «Outbound» or «Exit» connections. Is there anybody who is able to tell me what «Inbound», «Outbound» or «Exit» connections are? Greetings from Switzerland Information Architect

2 1

Making your relay submit hidden service statistics
by George Kadianakis 04 Feb '15

04 Feb '15

Hello people, some days ago we sent a mail [1] asking for feedback on our patch that collects hidden service statistics from Tor relays. Specifically, we are trying to answer the questions: "Approximately how many hidden services are there?" and "Approximately how much traffic of the Tor network is going to hidden services?". For more information see my previous email and the relevant proposals. Our code [2] got merged in upstream Tor some days ago and now we are looking for more volunteers to enable it on their relays. We will collect these statistics during the next [days] weeks, and in a month we plan to publish a short report with our findings. To help us you will need to use the very latest version of Tor and also slightly edit your torrc. Here are some instructions for Debian/Ubuntu [3]: ----- Let's start by slightly editing your regular Tor torrc to enable hidden service statistics. Please append the folowing to your regular torrc (not including quotes): """ HiddenServiceStatistics 1 """ Now, we need to install a bleeding edge version of Tor that can do hidden service statistics. You can either use the git master [3], or use Tor's APT repositories. The following instructions help you with the latter approach. Please start by following "Option two" of https://www.torproject.org/docs/debian so that you add the proper APT repositories and install tor and the deb.torproject.org-keyring package. Next, add the following line to your sources.lst: deb http://deb.torproject.org/torproject.org tor-nightly-master-wheezy main (you might need to replace 'wheezy' with your distribution, like you did in the previous step) Now, do # apt-get update # apt-get install tor which should upgrade your Tor to the latest nightly version., Your system Tor should now be up-to-date and able to collect hidden service statistics! Just start Tor as you normally do, using the torrc we modified above. For example you could simply do: # tor -f torrc but feel free to use your init script if you prefer that. Now just leave your relay do its thing, and keep an eye to this mailing list around mid-January 2015 for the results of our research. --- FWIW, if you are not using Debian, you can use the master branch of the official git repository: https://git.torproject.org/tor.git You will also need to edit your torrc in the same manner as the Debian instructions. Feel free to reply with any questions you have! Thanks! George Kadianakis Karsten Loesing Aaron Johnson David Goulet [1]: https://lists.torproject.org/pipermail/tor-dev/2014-December/007968.html [2]: https://trac.torproject.org/projects/tor/ticket/13192 [3]: for example see http://tor.stackexchange.com/questions/75/how-can-i-install-tor-from-the-so…

1 1

Long running relay keeping low bandwidth utilization
by mail＠dotjhw.pw 03 Feb '15

03 Feb '15

Dear list, I am wondering, wether it is still within what is considered a normal lifecycle, if the relay I am running is utilizing significantly less than the available bandwidth? Some background info: I set the relay up a few months ago and experienced higher utilization after a few days. around the end of 2014, I experienced hardware failure with the relay's machine and it went offline on December 21. I just managed to bring it back online on January 13. Since then, even with an available bandwidth in the range of 5-10Mbit/s, the actually used bandwidth is averaging at 8-9kbit/s, with no increase in sight. As far the bandwidths and weights graphs are concerned, it seems like the relay is not weighted as high anymore (last known consensus weight before the crash: 2.22e-5. After the crash and rebuild: 2.01e-6). Is there anything I can do to improve the relay? Best regards, .jhw

2 2

Re: [tor-relays] Hibernating / Traffic limit and consequrnces for the network.
by Sebastian Urbach 03 Feb '15

03 Feb '15

On February 1, 2015 10:48:25 PM Markus Hitter <mah(a)jump-ing.de> wrote: > Am 01.02.2015 um 20:02 schrieb Sebastian Urbach: > > I would like to provide a good service for everyone, even at the end > > of the month. That's getting harder the more systems are not present > > at the end of the month. > > I could understand the discussion if it were about providing 500 kBit > continuously vs. 1 Mbit for 2 of 4 >weeks. But the particular case was > about providing no >less than 6 Mbit continuously, which is easily >enough > to comfortably browse the web, for doing large >downloads and probably > exhausts most internet >connections in unfree countries. Accordingly it's > >unlikely a single connection is hobbled by such a >bandwidth limitation. Ah, thats a misunderstanding. This is not part 2 of the discussion from a few days ago. I brought it up because i see this for quite a while right now and observed it again within the last days. I thought it was time for a broader discussion. -- 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.

2 1

Stats [was: freenode]
by grarpamp 02 Feb '15

02 Feb '15

On Sat, Jan 24, 2015 at 3:16 PM, cacahuatl <cacahuatl(a)autistici.org> wrote: > Most of the network is under-utilised guards and middle nodes, hidden > services don't stress exits, which are the limited resource. Exits can and do serve in all the other node roles too. I don't think there has yet been a study to determine the actual unused capacity of the relays as grouped by flag permutations. Nor has compass been enhanced to support that selection matrix. > Triples? A HS doubles vs exit.

1 0

two questions about bridge
by jchase 02 Feb '15

02 Feb '15

Hello, I have a bridge up and running for about 6 months. I have two questions. According to arm my fingerprint is 72DB4EE86C65856E3131A32D8E30EC8A2B72A73D . But if I look up rasptorholland in globe.torproject.org I find that my fingerprint is 1BCD3EBEFE17EEB86EEDE21D5E2DB8468E2864CF . And again according to globe.torproject.org my pool assignment is blank (the empty set). Are these related to each other and is something wrong? Thanks, J Chase

2 1

Hibernating / Traffic limit and consequrnces for the network.
by Sebastian Urbach 02 Feb '15

02 Feb '15

Dear list, I would like to discuss hibernating and the consequences for the network. As someone running unmetered GBit systems i like to point out that there is a downside for the network when it comes to hibernating. Usually a few days before the end of every month my systems are getting slammed with traffic / directory requests. I thought about that and came up with the theory that a lot of systems with traffic limitations are dropping out a few days before the end of the month. This means more pressure on the remaining systems in the network. If the trend that more systems with limitations are participating increases we are going to see a serious imbalance in the network at some point. I know, poor unmetered systems ;-) I would like everybody to bear this in mind when it comes to the decision "Adjust the Rate or just open the gates and burn it as fast as possible". I'm in the fortunate position to be able to tribute a nice amount of money / traffic, but even systems with unmetered traffic can just help until the bandwidth / hardware limits are reached. It would be awesome if i could conbince some of you to take a step back and take a moment to look at the bigger picture. I would like to provide a good service for everyone, even at the end of the month. That's getting harder the more systems are not present at the end of the month. At this point i like to quote G. K. Chesterton: “We are all in the same boat in a stormy sea, and we owe each other a terrible loyalty.” Thank you for reading this and my best wishes for all of you. -- 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.

6 5

Information leak through WebRTC in FF/Chrome
by JusticeRage 01 Feb '15

01 Feb '15

Hi everyone, I'm not sure this is the place to share this, but I though some of you might want to know: an information leak has been discovered on Firefox / Chrome, and it can be used to reveal a user's real IP address. The article is focused on VPN, but people who connect to the Tor network through a local SOCKS proxy are also affected. Demo here . -- JusticeRage

3 2

entry guard interference?
by starlight.2015q1＠binnacle.cx 01 Feb '15

01 Feb '15

A couple of months ago I hard-configured two entry nodes that I trust for my own browsing. Both are very fast, very reliable nodes on the opposite side of the Atlantic. For about 20 minutes this evening the 'tor' daemon appears to have lost connectivity to the both nodes and I could not browse via Tor. Quite a few instances of this message were logged: Jan 30 22:59:06 Tor[]: Failed to find node for hop 0 of our path. Discarding this circuit. Neither of the configured guards were restarted during the outage, and they are located in diverse networks. The BGP looking-glass routes are different except for the first hop, which is a massive AS aggregation presumably for a trans-Atlantic cable operated by AS1299 (Telianet). I presume that this "cable" is actually a fully redundant load-balanced set of cables and any outage would be measured in milliseconds, or at most two or three seconds. Looking now, I see roughly 200 occurrences of the above message on Jan 14, 26 and 30. The reason I hard-coded the guard nodes was that, after extending the guard lifetime to 18 months, the guards were changing fairly often anyway. This bothered me. So the slightly paranoid side of my personality wonders if this is the result of a determined effort by one of the various spooky organizations out there purposefully disrupting Tor connections with the intent of forcing guard reassignment, naturally with the idea that Tor users might end up selecting guard nodes controlled by same said spooky organizations. Thoughts, comments and sharing of similar experiences are all welcome.

2 6

Re: [tor-relays] Digital Ocean: Moving to better Plan (Abhiram Chintangal)
by Spencer Rhodes 01 Feb '15

01 Feb '15

On Feb 1, 2015, at 7:00 AM, tor-relays-request(a)lists.torproject.org wrote: > > On Sat, 31 Jan 2015 13:23:39 -0800, Spencer Rhodes <spencer(a)rhodespa.com <mailto:spencer@rhodespa.com>> wrote: >> If you are on the 1TB plan at DigitalOcean, you will want to set something like the following: >> >> RelayBandwidthRate 600 KB # Throttle traffic to 600KB/s >> RelayBandwidthBurst 1.2 MB # But allow bursts up to 1.2 MB/s >> >> rather than set a daily or monthly limit. The reason being that your server will stay up all the time instead of suddenly hibernating (essentially going offline) when it hits the cap. > > I'm not sure that's the best course of action. See the Tor Manual section for AccountingMax > > https://www.torproject.org/docs/tor-manual.html.en <https://www.torproject.org/docs/tor-manual.html.en> > > If you have bandwidth cost issues, enabling hibernation is preferable to setting a low bandwidth, since it provides users with a collection of fast servers that are up some of the time, which is more useful than a set of slow servers that are always "available". Yes, I suppose that for a non-exit relay speed is more important than uninterrupted service...

1 0

Re: [tor-relays] Digital Ocean: Moving to better Plan (Abhiram Chintangal)
by Spencer Rhodes 01 Feb '15

01 Feb '15

> > > I have been running a tor middle relay[1] for the past few months. > > 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 ). > If you are on the 1TB plan at DigitalOcean, you will want to set something like the following: RelayBandwidthRate 600 KB # Throttle traffic to 600KB/s RelayBandwidthBurst 1.2 MB # But allow bursts up to 1.2 MB/s rather than set a daily or monthly limit. The reason being that your server will stay up all the time instead of suddenly hibernating (essentially going offline) when it hits the cap.

3 2

Re: [tor-relays] moving digital ocean
by Jan Nielsen 31 Jan '15

31 Jan '15

Digital ocean does not currently charge for going over your data limit. On Jan 31, 2015 1:51 PM, <tor-relays-request(a)lists.torproject.org> wrote: > 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: entry guard interference? (starlight.2015q1(a)binnacle.cx) > 2. Re: entry guard interference? (starlight.2015q1(a)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(a)binnacle.cx) > 6. Re: Consensus weight dropped (starlight.2015q1(a)binnacle.cx) > 7. Re: Consensus weight dropped (Network Operations Center) > > > ---------- Forwarded message ---------- > From: starlight.2015q1(a)binnacle.cx > To: tor-relays(a)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(a)binnacle.cx > To: tor-relays(a)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(a)gmail.com> > To: tor-relays(a)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(a)urbach.org> > wrote: > >> On January 31, 2015 2:09:14 AM Abhiram Chintangal < >> abhiram.chintangal(a)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(a)lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> > > > > -- > Abhiram Chintangal > > > > > ---------- Forwarded message ---------- > From: Bram de Boer <list-tor-relays(a)nosur.com> > To: tor-relays(a)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(a)lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > > > > > > ---------- Forwarded message ---------- > From: starlight.2015q1(a)binnacle.cx > To: tor-relays(a)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(a)binnacle.cx > To: tor-relays(a)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(a)schokomil.ch> > To: tor-relays(a)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(a)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(a)lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> > > > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > >

1 0

Re: [tor-relays] Consensus weight dropped
by starlight.2015q1＠binnacle.cx 31 Jan '15

31 Jan '15

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.

3 6

Re: [tor-relays] Consensus weight dropped
by starlight.2015q1＠binnacle.cx 31 Jan '15

31 Jan '15

also, for recent data. . . https://collector.torproject.org/recent/

1 0

Consensus weight dropped
by Bram de Boer 31 Jan '15

31 Jan '15

All, In December consensus weight of both my "nosurveillance" Tor exits dropped: https://atlas.torproject.org/#details/7C3AE76BB9E9E6E4F2AE9270FD824DF54A944… https://atlas.torproject.org/#details/E6D740ABFFAAAD8052EDF95B2C8DC4059763F… I assumed this to be related to the directory authorities tweaking consensus weight in response to the Lizard Squad annoyance around that time. However, traffic has not yet picked up yet. Testing download and upload speeds of my server both maxed out the 100 Mbps line. I have even done a complete reinstall from a fresh Ubuntu image a week ago (while keeping the old keys, as not to restart building reputation from scratch) but that doesn't seem to help either. I am renting this dedicated server from my own private money, in my spare time as I hate surveillance and spying by governments. But right now I starting to feel silly spending that much money for a Tor exit of which only 50kbps bandwidth is used. AFAIK nothing has changed on my server, so I am puzzled why consensus has dropped and was never restored again. Please advice, Thanks, Bram de Boer

10 29

Digital Ocean: Moving to better Plan
by Abhiram Chintangal 31 Jan '15

31 Jan '15

Hello, I have been running a tor middle relay[1] for the past few months. Apart from tweaking the configuration a few times, I didn't have to do much to get things working. 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. Btw, here is my .torrc ORPort 443 DirPort 80 Exitpolicy reject *:* Nickname orpheus ContactInfo orpheus.tor(a)risup.net Log notice file /var/log/tor/notices.log RelayBandwidthRate 1024 KB RelayBandwidthBurst 1024 KB MaxAdvertisedBandwidth 1024 KB DisableDebuggerAttachment 0 AccountingMax 500GBytes AccountingStart month 1 0:00 Thank you! -- Abhiram Chintangal [1]: https://atlas.thecthulhu.com/#details/3045303283D4EAF74C8FA053054C691BB451A…

2 2

Re: [tor-relays] entry guard interference?
by starlight.2015q1＠binnacle.cx 31 Jan '15

31 Jan '15

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.

1 0

Re: [tor-relays] entry guard interference?
by starlight.2015q1＠binnacle.cx 31 Jan '15

31 Jan '15

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.

1 0

nearly no bandwith usage with high Consensus Weight?
by AFO-Admin 31 Jan '15

31 Jan '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi since some days my relays dropped to nearly zero bandwith but the consensus weight is still high. I never saw a behaivier like this before, maybe somebody can tell me what is going wrong here? Thanks for help https://atlas.torproject.org/#details/F5D03B59A330BE399EAA793FA35353ADD7E4A… https://atlas.torproject.org/#details/14EC9284918461506FC47D6FD9F1C71C3DA11… -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJUzHNkAAoJEOExTryL2+47hKEP/Rz7HTULqcLi8ssZXqDwe0LJ GVoNVi+wOByB9BkcT6tC+imdJf6TabQY/WdfmkdNCd0rtGkDyz+kCExwU3xJNTlP 8yaPCuyr9wJMjkMR7F7P3ZA3LvzQ/PQE9z5L1PrvYZOVv7g22aR5KaebrrvhMLWJ RiBgUEGusrmQIdz3WOqTApRE4IOGr7UMg9HrLpK8KWdKT7dUvA0BauonentLxK5D njS5ZbZNIpvN+uPfVGzuJTAL3jIi4QZP8JVyz1kKdIaH2argxP7ReEYakOxNlxqy UkTVIBO1/7/VI1m8NhCSjzE07xagxtjDedGLCJW6b7VxeZ6g3fAgKWFnhc8Fej8c NJzTJXDfmiBjv20v1F9Q7lrxDjSiF8290zSfj99iLN6MsYJgfWthJfoLgwAn4sO6 4HYCyLfwqkZmtZM/UAwR3tfGp/uAi8KRpYrXUqMPjlgQgsh0/dHyIj6eewe93ED6 AThOTeTxz+azOkt0/i9efpppgAWJNd0dzeNDy2drLihDtByJ2e3Zb5MdxisXUGBg 396UOBgm67/rfJJkRqlMcjbWbX8xk3uYVmxM+JO7AHmRFRXcaBhS/EBnjdf9PUr/ K9bcBGK0CXvpwvsQceh+DyBe257tb6a8yU653LQARPfVa3uqBhjMTAP+Zda7ErZa EAUl9lT22QiAYw6QET4l =tuIU -----END PGP SIGNATURE-----

1 0

Mozilla's 'deploying tor relays' blog post
by Sebastian Urbach 28 Jan '15

28 Jan '15

Hi, The ramp up time is not 2 months. It's 3 months with the actual version. Lets see if they read the comments ;-) -- 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.

1 0

Mozilla's 'deploying tor relays' blog post
by Nusenu 28 Jan '15

28 Jan '15

https://blog.mozilla.org/it/2015/01/28/deploying-tor-relays/ ansible configuration https://github.com/XioNoX/moz-tor-relays/

1 0

GHOST: glibc gethostbyname buffer overflow
by goll 28 Jan '15

28 Jan '15

Hello operators, If you have not done so already, update your glibc: "as a result, most stable and long-term-support distributions were left exposed (and still are): Debian 7 (wheezy), Red Hat Enterprise Linux 6 & 7, CentOS 6 & 7, Ubuntu 12.04, for example." http://www.openwall.com/lists/oss-security/2015/01/27/9 Best regards

1 0

could smoothing/smearing a consensus weights change makes sense
by Toralf Förster 24 Jan '15

24 Jan '15

I am wondering if an adversary would be able to derive useful information due to the fact that the consensus weights are changed abrupt ? (screen shot attached) -- Toralf pgp key: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 0076 E94E

2 1