- 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 21 Feb '15

21 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