- tor-relays - lists.torproject.org

VPS/Tor Final Thoughts
by Kurt Besig 09 Dec '15

09 Dec '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I thought it might be helpful to any other volunteer that may have been silently following this thread to quickly post the issues with my VPS Tor server that were resolved. 1. Setting up iptables allowed connections to my server. 2. Adding my server's [ip address] to the /etc/torrc resolved the problem of tor attempting to connect to the "node" my server is on rather than the actual ip my server is on. 3. Checking the user groups and permissions necessary to allow access to tor files. Other thoughts: As mentioned numerous times arm is a comfy frontend, but certainly not necessary after investigating system tools such as lsof and utilizing nload or munin. Also having ntp installed and running is helpful I think. Again thanks for all the help and have a very happy holiday season! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJWaDXxAAoJEJQqkaGlFNDPGh4H/0uDGiSIq9dYjDBNSIrVRoBQ sBGjLdFhvdFSJ4dsTRPspAKC+6zg4FnGSj1isBFBmJOLIN71oIo6qXkrXoQgyS+Q crnNYucyC6Vo8vQdK72QabuAJZGE2+VXfwTw/82NhldIQnKJzyfnjNKZYamR486y KQJGzPHls2abZPu0zyx/ay7pZRUZWzGvfc1yShQ6yTsiVqCJk456aPRd0/rbkLMQ dG/TOHHSOAJzMsZXk92rzk0JNBBYhwkOTiNyPQDd+S68IWyLXp5wC0hE4KTdRmf/ Osa8NIB3FQyYeg6XAjxZ1PhYSc8Lp91+K220znS/2lXStxjrdUFY4TU7119iYpA= =a7HY -----END PGP SIGNATURE-----

1 0

Mozilla11
by tor-server-creator＠use.startmail.com 08 Dec '15

08 Dec '15

seems like one instance didnt made it from 02510 to 0275: Mozilla11 - probably the other instances will handle the unused bandwidth but its a bit of a pity isnt it... if its running some hundret days we should poke now still its known by consensus otherwise its waste of electricity. thanks Mozilla <3

1 0

(no subject)
by 海洋 08 Dec '15

08 Dec '15

1 0

Custom bandwith for different time ranges
by Zalezny Niezalezny 08 Dec '15

08 Dec '15

Hi All, this is my first post on this list so warm welcome to every one a specialy to Tor developers. On my servers I`m running paralllel prod servers with tor relays on the separate IP. I`m supporting tor network for free with high speed tor relays but I need to customize the time when my server will share 100% of its resources for tor and when traffic will be limited. Is it possible to schedule the time when bandwith will looks as follow: 8:00 - 18:00 - Tor relay bandwith 250kb/s 18:00 - 8:00 - Tor relay bandwith 10 000kb/s How may I schedule this in tor relay ? Is it possible to limit traffic on the client or I need to do it on my firewall ? Thanks in advance for any feedback.

6 7

ANN: TCP injection attack detection tool - honeybadger
by David Stainton 07 Dec '15

07 Dec '15

Dear Golang community, Edward Snowden, cypherpunks, Tor-relay operators, low-level network hackers and TCP abolitionists, I was inspired by the Snowden documents to write a TCP injection attack detection tool. Powerful entities world wide are stock piling zero-days. TCP injection attacks can be used to deliver many of these attacks. source: https://github.com/david415/HoneyBadger docs: https://honeybadger.readthedocs.org/en/latest/ tasty pcap for "integration testing": https://github.com/david415/honeybadger-pcap-files HoneyBadger does bidirectional TCP stream reassembly... temporarily storing segments in ring buffer for comparison to later received overlapping stream segments. In other words it doesn't rely on simply matching duplicate sequence numbers but compares the actual overlapping stream segment contents. This more thorough approach is needed to account for TCP's retransmission which can send various segments sizes that can differ from the original dropped segment length. Furthermore we also detect the other injection types such as handshake hijack. The literature (go ahead and scour the Internet) does NOT mention all of the TCP injection attacks that are possible. I assert that there are 5 possible types of TCP injection attack. I describe them here: https://github.com/david415/HoneyBadger_docs/blob/hackpad1/source/how-to-de… https://github.com/david415/HoneyBadger_docs/blob/hackpad1/source/how-to-de… current honeybadger project status: - honeybadger seems mostly useable for use in the wild, though we are pretty sure that bugs exist and probably some false positive bugs at that. - active development halted several months ago when the implementation seemed good enough to deploy and sniff packets in the wild. - if in the future the gopacket dev team releases a new "sufficient" TCP reassembly API then I could severely reduce HoneyBadger's code size. - pull requests and github issue comments will inspire me to contribute feature additions and fixes It runs on Linux but does honeybadger work on *BSD? Of course it does... I wrote the gopacket BSD BPF sniffer API ;-p and tested honeybadger on NetBSD, FreeBSD and OpenBSD. I'd like to explore the possibility of writing a similar TCP injection attack detector in rust using libpnet as soon as libpnet is sufficiently mature to use for TCP analysis: https://github.com/libpnet/libpnet So what? 1. So... all TCP analyzers need to be rewritten to account for TCP injection attacks, otherwise you are doing it wrong. 2. So feel free to use HoneyBadger to analyze your own traffic over the wire or sketchy pcap files that you acquire; perhaps our data collection efforts will result in responsible disclosure of 0-days... and publicly reporting that in fact these TCP injection attacks do happen as targeted attacks against real people to violate their human rights. 3. So use my design in your software; The description of how to detect the 5 possible TCP injection attacks can serve as a part of a design document for other software projects to implement their own TCP injection attack detection. cheers from the Internet, David Stainton

2 1

VPS/Tor
by Kurt Besig 07 Dec '15

07 Dec '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I want to thank everyone for the multitude of great suggestions regarding getting my relay up on a VPS. I reviewed every email and all the input was useful. The relay is up and running: E65D 300F 11E1 DB12 C534 B014 6BDA B697 2F1A 8A48 As well as my home relay: F527 3098 A711 F845 E5D1 A24F 9D38 F93B 86A0 F220 While all the information culminated in a successful outcome the suggestion of installing ufw as a means of setting up iptables was exceptionally valuable, thank you. Hopefully in the future I can return the kindness. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJWZZzuAAoJEJQqkaGlFNDPifYIAIGF6EZIxvuRCz2pTQa9+vg1 6OX1YJ/Z/fP4sGhhS+VtpGzhjewFf4Yv1FYXvWdRQWVW204Ms6wR6ibul4jLd58u ENr75uDqK/ro8kLWQpWsLeJoh3zp8cAc5dpH/u9Itftj0o/td8fGVeV6YIOw9q3L oA90pIVRNXun49Tb4cZjYm71+KBRwSekyXUoXccAcFzw+1WvLkW9TD8Xtd25/D7E 2VBfsYZinqia+7kqcCfUzoO4Ekg4JTkgBt/PkQ9eONz3w5g6+e52hh3kNurW3wfO 61BQ5Nq/0Q2u+cmgp+DItkD5+XSLPop8HZnwJM17M1nGxZ+/cBFYGZQmrlXpFUs= =nGYI -----END PGP SIGNATURE-----

1 0

Re: [tor-relays] Custom bandwith for different time ranges
by starlight.2015q3＠binnacle.cx 07 Dec '15

07 Dec '15

>Is it possible to schedule the time when bandwith . . . >How may I schedule this in tor relay? >Is it possible to limit traffic on >the client or I need to do it on my firewall ? As suggested in an earlier reply, configuring 'cron' jobs to adjust the rate usually makes sense. As an alternative to modifying 'torrc' and sending SIGHUP to the daemon, you could use a control-channel script similar to: nc 127.0.0.1 9151 <<EOF AUTHENTICATE "passphrase" SETCONF BandwidthRate=Y BandwidthBurst=Y QUIT EOF An even better way is to use the 'tc' or "traffic control" command to limit ingress traffic to the relay via a 'police' filter, as rate-limiting through discarding of packets result in better performance from daemon during overload conditions than the daemon rate-limit algorithm. But 'tc' only works if an interface or alternate IP on an interface can be dedicated to the Tor router, and it's more technical to configure. If the firewall is an Cisco ASA, an ingress rate 'police' policy can be constructed with results similar to the 'tc' approach. However one must dedicate an entire ASA Ethernet port to the relay as this type of filter cannot be applied to a limited set of flows. A problem with altering bandwidth significantly on a schedule is that the BWauths that measure and rate relays will produce erratic results for the relay. BWauths are erratic when rating stable relays due to some issues with the implementation, and the results for a moving target is even worse.

1 0

VPS/Tor Almost There
by Kurt Besig 07 Dec '15

07 Dec '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thanks again for all the support everyone has bee extremely helpful. So, I reinstalled the OS on the VPS: lsb_release -d Description: Ubuntu 14.04.3 LTS uname -r 2.6.32-042stab102.9 Finally solved all the permissions problems, paths are correct, tor and arm open properly. The problem now boils down to this: The VPS isn't allowing Ports 9001 and 9030 Should I investigate further getting my iptables up and running or just contact the admin and have them allow the ports? As I mentioned previously even after saving the tables upon reboot iptables -L shows no rules, the file is empty. :~$ iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Any further suggestions would be appreciated. Thanks -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJWZF8qAAoJEJQqkaGlFNDPO18H/2Axj4EeGf5joYQ3n2SH1cgs HhDAawaiMaSKMcfC/Oc9TudwKAxkoY+QkhegZr5senNKXrXjNPeLucfejkRBiUoJ 8KLOZabSGH2Uf89JNa4ZFbf9QVIiU8GdNJ0vSGy55iAuJQl14ZUpDRQeNnGkmwb5 uhADchwTVjK7Pq+ELyG6OI6l0jlQ69TWCpgH4lnMjQ5U+Nr1QKyApxXqr1ap5Heb KJmlwchTv4zAxX2eBc1DPqAXdc9OsvEsPG/r/zp4Z/wPWxsUTGoZWoXsWv4xyjPQ xzAzUKD+b+AvqGQ3ehQbdXtg423kO7/amVidAzux8mDmMeZuFoP3tpfqLd8cH+s= =uoin -----END PGP SIGNATURE-----

5 4

Re: [tor-relays] tor-relays Digest, Vol 59, Issue 8
by Manager Bahia del Sol LLC 06 Dec '15

06 Dec '15

1 0

Re: [tor-relays] Unbelieveable
by Manager Bahia del Sol LLC 06 Dec '15

06 Dec '15

5 6

Unbelieveable
by Kurt Besig 06 Dec '15

06 Dec '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 That I got two responses after posting to tor-relays regarding a fairly simple, I thought, CntrolPort question on a new VPS relay.. That's pathetic. Thanks for all your input. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJWYP6FAAoJEJQqkaGlFNDPTCUIAKGRC9/XUKeBLrhIlXUrZd03 oTiWdNJebmCRJ55gXbXv+2VxwM18YipkkwEIRmxrSdUsvzn2zRZ11FOnv1Yi8tFY oiD8HgqLVe6pcDepslPPe/SJyMz6tIqBnosYG6yADOpYCXRR22ehRlPQHkdg2kZ+ ePBWJwDVop8WXUDwgAxRFd/jp/WWjLRt90bgHpcupEzbGi7GMTvNbftHEBeJvhwc g1xp5gZlvBgCT8Kb03dXQCUaYQ8hpjc9zbo4sQwnJNOZpyU6ftLdsoODa8NRW73s bslUj6EjQ5P2+tC2d9Q7s669XpLoxipJm1QiYVqFPIfLo48F4GjW1r64SKBxHVw= =mddV -----END PGP SIGNATURE-----

14 22

VPS Connection Refused
by Kurt Besig 04 Dec '15

04 Dec '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I just set up a VPS on PulseServers as I noticed quite a few running relays had mostly good things to say about the service. So Far the people operating the servers seem very cooperative and responsive. Anyway I've been running a middle relay for 1.5 years and know the "ropes" pretty well, however a VPS is new to me. After setting up Tor and tor-arm on the VPS I'm not able to connect with this error: unable to reconnect (connection refused. Is the ControlPort Enabled?) I've edited ~/home/.arm/torrc and /etc/tor/torrc un-commenting the ControlPort 9052 and all the other typical ports, etc.. Obviously I'm not able to forward or enable ports on the VPS, so do I need to ask the admin to make some changes? Thanks -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJWX3RnAAoJEJQqkaGlFNDPiS4H/2g/stKLNl0R1ZzbM2/MmC45 D0t2K8E7mcuIhxDiQJ/klaluJWnTHUrUPonSXTZuMYQJOBjdQIV6Mbq61/2g/TK9 VOdiTIsJSD30wmPIUZXlFb7xGX98DNedsySbCG4evJGmJvmEKXiAwg9i/K0iz5Ar KmRTRxtqCUJcmS+L0s0chV2A7TsIpP2h/WUS/tzc+AmAlbx1jZ4K1zu2uzCqZIjQ 69nkbbHd9DDlmSXvC9aKCB1MO3HcJUgA6gUin4UBOhkrTokbfRQBtizuHqlI4RSG sL9CyOocs9d1DEQVF1pN3PPNjWh/Owm4WzMTm3dMJ+DuRQQ5ls3R+4Fn9I//2Mg= =26fO -----END PGP SIGNATURE-----

6 11

(no subject)
by 海洋 04 Dec '15

04 Dec '15

1 0

webiron requesting to block several /24 subnet
by WubTheCaptain 03 Dec '15

03 Dec '15

This will be my lengthy opinion on Webiron to get everything out of my mind without redactions. > Webiron's system sends notifications to both the abusix.org contact > for the IP and to abuse at base-domain.tld for the reverse-DNS name of > the relay IP. This doesn't seem to be the case for us. Our rDNS is set to tor-exit.se.partyvan.eu. Back when I received our first abuse complaint from Webiron, the WHOIS for the Tor exit IP-address had an abuse-mailbox contact for us but the abuse-c was still pointed at our data center. Webiron emailed three email addresses: - abuse(a)portlane.com (abuse-c, mnt-by for all of our /29) - info(a)partyvan.eu (unlisted, unused RFC 2142 address) - abuse(a)partyvan.eu (abuse-mailbox) By the time I had received a second or third abuse report from Webiron, I had made some voluntary changes to get the abuse-c assigned to us after registering to RIPE database. Despite this, Webiron's system still contacted two addressses: - abuse(a)portlane.com (mnt-by for netnum) - abuse(a)partyvan.eu (abuse-c and abuse-mailbox) More accurately, Webiron may employ caching of results or go for the netnum abuse-c/abuse-mailbox instead. Other abuse complaints we've received such as one from the Brazilian Army have contacted our abuse@ role only and never bothered our data center. For what it's worth, abuse.net also lists our abuse@ contact for the domain. > I'm currently in the middle of a somewhat heated e-mail debate with > their vice-president. > Pasting the e-mails below would be indelicate, but their position is > that the Tor network is responsible for the abuse it generates and > should take measures to prevent/block malicious traffic. > They also state that according to their measurements, 99% of the > traffic coming out of Tor is hostile, and they're going to release a > report on the matter soon. Webiron's policies are dodgy at best. They even claim that Tor exit operators are legally liable for the traffic they route [1], which is obviously false given our real legislative liability protection for service providers. I immediately lost sense of their credibility. They say: > Groups hosting exit nodes are responsible for the abuse that comes out > of exit nodes. By refusing to take action to stop attacks originating > from your proxies it can make you legally responsible to international > law as well as laws in most regions (IE EU) as it shows a willingness > to facilitate further attacks. Our data center doesn't seem to mind Webiron's abuse reports regarding our Tor exit, and while they also get copies of the abuse complaints they've never bothered us about it. (For the curious, Portlane used to house Serious Tubes which housed The Pirate Bay until a raid on December 2014.[2]) After receiving six or so abuse complaints from Webiron [3] and acknowledging each to support(a)webiron.com explaining it's a Tor exit, I've not heard back from them again for a while. Banning /32 or /24 seems out of question for us to keep the limited liability protection. It wouldn't solve the issue anyway due to 1000+ other exits available, so the best solution remains to block Tor temporarily from the other end or implement CAPTCHAs for Tor users to slow down or defeat bruteforce attacks. As an example, CloudFlare implements CAPTCHA for visitors from Tor. Webiron could do something similar if they wished to act on these as a reverse proxy service. Their requests are too unreasonable for Tor exit operators. By their ideology, I understood they're saying stores selling ski equipment for skiing should be held liable for crimes commited by their customers who bought their skiing masks: > You chose to allow this to run from the network you are responsible > for. Proxing attacks is translatable to providing the mask before an > assault or robbery. At this point we feel your company is complicit in > these attacks by allowing them to continue. For me this does not sound credible, and I didn't bother trying to give their argument more credibility with a reply. They wished me "good luck" [4] after mentioning my Tor exit will be on their blacklist and referencing to IBM's research on "recommending a blanket ban on Tor".[5] At least I still remain to have some sense of credibility in SpamCop and Spamhaus, despite few controversies involved with the latter. This is why we can't have nice things and why I've given up with most hosting providers. PS: Portlane is not yet listed on GoodBadISPs [6] wiki page. -Wub [1]: https://archive.is/Obhnk [2]: http://www.bbc.com/news/technology-30411782 [3]: https://partyvan.eu/transparency/emails/abuse/ [4]: https://partyvan.eu/transparency/emails/abuse/2015-11-13-webiron-tor-exit.m… [5]: http://www.techweekeurope.co.uk/security/ibm-companies-tor-175468 [6]: https://trac.torproject.org/projects/tor/wiki/doc/GoodBadISPs

1 0

PASSWORD
by John favino 29 Nov '15

29 Nov '15

I NEVER RECEIVED A PASSWORD.

3 2

Re: [tor-relays] webiron requesting to block several /24 subnet
by Dhalgren Tor 28 Nov '15

28 Nov '15

>. . .I have to understand how my ISP reacts to this kind of things. >For the moment I will keep a low profile and I will block the >mentioned IP range for a month. Webiron's system sends notifications to both the abusix.org contact for the IP and to abuse(a)base-domain.tld for the reverse-DNS name of the relay IP. So if you can configure abuse@ for the relay domain to forward to you, you will see their notices at the same time as the ISP abuse desk. Might be helpful to know about it before they contact you and/or to see if they become familiar enough with the notices to ignore them. Automated abuse complaints from other sources do not always go to the domain-based address. http://multirbl.valli.org/ is a handy resource that shows the abuseix.org and abuse.net information, as well as how many DNSBLs the relay has racked up. You can change the abuse.net contact but Webiron appears to ignore this source and simply construct the abuse@ from the rDNS domain name.

7 8

Any experience with Pulse Servers?
by Jesse V 28 Nov '15

28 Nov '15

Hi everyone, I've been looking around for a new host for my Tor infrastructure, which includes exits, relays, and a bridge. I've been reviewing https://trac.torproject.org/projects/tor/wiki/doc/GoodBadISPs and ran across Pulse Servers, which seems Tor friendly. They have VPSs in Canada and the UK and have really low prices on VPSs, which I'm trying to understand. I've been trying to learn more but I think they have a pretty small setup (apparently the owner does tech support) and documentation is limited. Does anyone have any experience or opinions on them? -- Jesse V

4 3

Arm thinks Tor is not running as a Daemon?
by Jannis Wiese 27 Nov '15

27 Nov '15

Hi, I’m a bit confused right now. I’ve upgraded my relay to Debian Jessie yesterday and since then, arm keeps telling me > [ARM_WARN] The torrc differs from what tor's using. You can issue a > sighup to reload the torrc values by pressing x. > - configuration value is missing from the torrc: RunAsDaemon I’m running the same configuration as before (running Debian Wheezy), where it worked without any warning. RunAsDaemon is set to 1 in tor-service-defaults-torrc, still arm is showing me on the Tor configuration page “RunAsDaemon False”. Putting RunAsDaemon into torrc as well triggers this: > [ARM_WARN] The torrc differs from what tor's using. You can issue a > sighup to reload the torrc values by pressing x. > - torrc value differs on line: 17 The problem here: There is no line 17 in my torrc… I’ve already read tickets like #16459[1] and #2501[2] but it didn’t help much. Damian says in Ticket #16459 > […] This message is meant to help people who edit their torrc, forget to restart tor, and are then confused why the settings didn't take effect. [...] I did restart tor (a couple times) and apparently it is running as a Daemon (service --status-all). So I hope this is “just” an issue with arm… Maybe someone of you has an idea? I’m running arm 1.4.5.0 and tor 0.2.7.5 (from deb.torproject.org <http://deb.torproject.org/>) Cheers, Jannis [1] https://trac.torproject.org/projects/tor/ticket/16459 [2] https://trac.torproject.org/projects/tor/ticket/2501

2 2

Re: [tor-relays] Faravahar messing with my IP address
by SiNA Rabbani 26 Nov '15

26 Nov '15

Dear Relay Operator, I am the operator of Faravahar, It has been having some network issues, specifically very long latency. But this is the first time I hear of an issue like this. 154.35.32.5 is Faravahr's older IP addresses which was replaced with and 154.35.175.225 is the new IP (current). There are iptable rules forwarding the traffic from OLD IP to the new one for the clients that have not updated yet. Are you running the latest version of tor software? I'll be sure to keep an eye on this email and open a ticket as needed. Thank you for reporting the issue and running a relay. All the best, Sina "Be the change that you wish to see in the world." - Mahatma Gandhi ----- On Oct 22, 2015, at 11:22 AM, Logforme m7527(a)abc.se wrote: > I run the relay Logforme (855BC2DABE24C861CD887DB9B2E950424B49FC34) > > Saw this in yesterday's log file: > Oct 22 03:17:55.000 [notice] Our IP Address has changed from > 84.219.173.60 to 154.35.32.5; rebuilding descriptor (source: > 154.35.175.225). > Oct 22 03:17:55.000 [notice] Self-testing indicates your ORPort is > reachable from the outside. Excellent. Publishing server descriptor. > Oct 22 03:17:56.000 [notice] Performing bandwidth self-test...done. > Oct 22 03:26:55.000 [notice] Our IP Address has changed from 154.35.32.5 > to 84.219.173.60; rebuilding descriptor (source: 194.109.206.212). > > 84.219.173.60: <- My real IP address > 154.35.32.5: faravahar.rabbani.jp <- No idea > 154.35.175.225: faravahar.redteam.net <- Authority server > 194.109.206.212: tor.dizum.com <- Better authority server > > So if I read it right my relay asked the authority server Faravahar what > my IP address is and got the wrong answer. 9 minutes later my relay > asked another authority server and got the right answer. My relay show > an uptime starting from this time and if the relay did a full restart it > meant all the circuits got dropped? Inconvenient for users. > > My relay have "restarted" like this a few times the last weeks (only Tor > daemon "restarting", not the machine). Don't know if Faravahar is behind > the other "restarts". This time I just caught it in the log file before > it got archived. > > Is this a know issue with Faravahar? If so, should it be fixed? > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

7 12

Nagios/Icinga plugin check_tor_bandwidth for gathering bandwidth data
by Josef Stautner 26 Nov '15

26 Nov '15

Hello @all, (I'm not sure if you guys are interested in a topic like this) I wrote a perl script to gather bandwidth data from my Tor exit relay. The script connects to the Tor control socket, fetches the running config to extract the bandwidth limits and the reject rule count. Afterwards the last 60 bw-cache entries are fetched and average values are built for bandwidth in and out. All this performance data is then forwarded to Nagios/Icinga where you can do anything with that values. Every 30 minutes a cronjob renders the graph showing the datapoints of the last 6 houres and uploads the resulting image to my website. You can find the image here (Hint: The values for in and out are stacked): https://blog.veloc1ty.de/bandwidth-large.png The source of the script can be found here on GitHub: https://github.com/vlcty/check_tor_bandwidth It's released under the GPLv3 Maybe somebody will find it usefull :-) ~Josef

4 4

(no subject)
by 海洋 24 Nov '15

24 Nov '15

1 0

keypair issue after backing up relay
by Matlink 23 Nov '15

23 Nov '15

Hi, I'm running a tor relay. I once had some trouble about running it, and I decided to reinstall tor via apt-get. Of course, it did erased all my private and public keys, that I missed to backup before reinstalling tor. Then I ran tor again, with the new identity. As I have a container backup running every day, I was able to recover the erased private and public keys, that I put them back. I can run tor with my original identity, but the directory server is saying me '[WARN] http status 400 ("Looks like your keypair does not match its older value.")'. How can I fix it ? I would like to keep the original identity, since I had all the convenient flags and don't want to wait another couple of weeks to get them back with a new identity. Sincerly, -- Matlink - Sysadmin matlink.fr Sortez couverts, chiffrez vos mails : https://café-vie-privée.fr/ XMPP/Jabber : matlink(a)matlink.fr Clé publique PGP : 0x186BB3CA Empreinte Off-the-record : 572174BF 6983EA74 91417CA7 705ED899 DE9D05B2

2 2

warning in my relay log
by DARKNET.IT 23 Nov '15

23 Nov '15

I have changed server and tor version (from Tor 0.2.6.10 to Tor 0.2.7.5). My relay works but I have this warning: "http status 400 ("Looks like your keypair does not match its older value.") response from dirserver '208.83.223.34:443'. Please correct." This is my relay fingerprint: 59573AB90614D929360C7D9BCBF3313497A22AA2 What means and what I have to do? The keys for me is correct. Thanks for reply

3 2

Actions required after update?
by kingqueen 23 Nov '15

23 Nov '15

Hi That's a hefty changelog for the new stable release of Tor. I'm in awe of and grateful to the developers, as it's all well beyond me. Please could anybody confirm, is there any action required for somebody running the relay on a pretty bog-standard Ubuntu 12.04 Linux dedi, other than sudo apt-get update && sudo apt-get dist-upgrade ? Thank you!

3 3

IP-Echelon complains about claimed infringement
by Riccardo Mori 22 Nov '15

22 Nov '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi everyone, It's almost a week that I am receiving dozens of "Notices of Claimed Infringement" a day from IP-Echelon, all equals, saying that they "are contacting" me "on behalf of Paramount Pictures Corporation (Paramount)" and asking me to remove the film in question that is being shared via bittorent (the port varies each time). The first time I wrote them that the ip address in question is a Tor exit node, I explained briefly what is Tor and that I can't do anything to help them. I also wrote to MyLoc (the ISP) saying pretty much the same. I wrote to IP-Echelon another time but they never replied. Usually I wouldn't care about them but this time MyLoc told me to "fix the problem or" they "will block" my "server". I modified the exit policy so now I am running the reduced one[1] That (in theory) should fix the problem but I would like to avoid the reduced policy. Is there anyone that had the same issues with IP-Echelon and can help me? Usually how do you handle those annoying auto generated reports? Thanks, patacca [1] https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWT+YZAAoJEE1LNuolWAxgl90P/Rq5DCCc4FrrFqqOSKjisJ57 zBVOpzrfDxAG0ArRFWdhUBi8etpvbNtq042mjevVGp3N3p+IPpyl9bKvZWM7ACID BtBnra7WwMEW21BHqKGmzXJ6CG35AdVRUaJMaJXXSaNGNThFh+mXDGm4B8iHUoI3 3vZxiIHG17INY7lZM7RimYA1MKRQAcICldIYaCA2Nwt/n4gbUlZ3OUXmeGbJins/ NZrN98ZOhxeNg93+wk3f5ns1mQk137ZIcsdb+86uyaqDCxGn7fja2/MXBeHBUonM cZcBUSw1SKdY3XbYh6VyHRhRxWfmHeB/e2MLlDiOZbVc5QgGsOkmwmPKFuNA1dvg w5QoXcUSpUh01mxEK0x1IRl5BAD1zya4ZyITxLAr7OXGVx1jifCvkCKq6rDrLzsX XP8hq8w6Hp9GuFr8QrOx08Q6kvAvQjcF59s6/h0P3ehdbLnNaquEgQA86+WDtlNU lON0MnCf5vmZbww0TP5ymhiiZZIy6uilaqfVJry9lXdiXJvu/xeWs1p2VkxlUpaD ySnjFArg8iT5+veZro1ui0tmqseyu2BdEPfAyu86FcrS3wpbvI983aPDZOEpDoJh NaiE5pQCtsxj7moL1pDfHfFfS23aTGerpj9VTXYE9vd/hO8gqZTWCFA7coDZcXQV 0ZdIkA2C4EI7Rd6ui/cS =CxVx -----END PGP SIGNATURE-----

5 4