[tor-relays] Tor relays Bazinga and JPsi2 to be shut down
Hi all, I have been operating the relays - Bazinga B198C0B4B8C551F174FBB841A172616E3DB3124D - JPsi2 F6EC46933CE8D4FAD5CCDAA8B1C5A377685FC521 for about 10 years. The hosting provider stops providing their current service and their successor services are not Tor-friendly anymore. Hence, these relays will be shut down by June 2 2024. My third relay - SafeAndEffective A508096AA0C899F4E6ECD1D9C35037B89008BCBA is unaffected. OpenPGP_signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Block certain .onion websites
Exit relays have nothing to do with .onion sites. By design you cannot block them in your relay. On 5/27/21 6:43 PM, Tor Operator wrote: > Hello, exit node operator here. I share the values of the TOR > foundation, that’s why I’m operating an exit node but I can’t unsee all > the bad it is used for. I know it would sound like censorship but > wouldn’t it be possible for an exit relay to block certain (mainly cp) > .onion websites so that they cannot be visited from certain exit nodes? > Thanks in advance > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Many SSH requests
Happens on all internet-facing ssh daemons. Independently of tor. On 3/31/21 6:35 PM, Cristiano Kubiaki Gomes wrote: > Hi there, > O noticed many ssh requests to my Debian VM running a Relay and I am > wondering if this is normal or if this is happening only with me. > > Anyone else see this ssh attemptives? Is it normal? > > sshd[27004]: Failed password for root from 45.91.226.235 port 41012 ssh2 > sshd[27004]: Received disconnect from 45.91.226.235 port 41012:11: Bye > Bye [preauth] > sshd[27004]: Disconnected from authenticating user root 45.91.226.235 > port 41012 [preauth] > sshd[27006]: pam_unix(sshd:auth): authentication failure; logname= uid=0 > euid=0 tty=ssh ruser= rhost=108.36.253.227 user=root > > It's many different ips and trying to access in many different ports. > > Thank you! > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor project helping to attempt to cancel Richard Stallman
I believe to have observed a worrying pattern lately. A small number of people select a person for a perceived or actual wrongdoing and do their best at destroying their target's lives though any and all means available. Including by exerting pressure on their target's workplace to throw the target out, shun them, destroying them completely. This group of attackers usually comes with a larger group of followers on certain "social" networks. Too often the initially innocent bystanders give in to the attacks out of fear of becoming themselves a target of the attackers. They grant the attacker's wish and (consciously or not) become accomplice of the attacker. I am under the impression this might be the case here. RMS may or may not have said something bad, I don't want to get into that. As far as I heard, the accusations are limited to RMS having stated an opinion, not having actually done something. A "mob" decided to destroy him, and my impression is that TPO is now giving in and gives RMS another media-effective shove while others are in the process of throwing him under the bus, in an attempt at virtue-signalling to the attackers, so they'd leave TPO alone. It looks like an example of falling victim to divide and conquer. There are strong enemies of privacy, freedom of speech, civil liberties out there. We should try fighting them instead of fighting amongst one another, fighting someone who has done a priceless job for the free software movement for many many years. My 2 modest guard/mid relays will keep running independent of this embarrassing issue. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Relay JPsi2 not getting into consensus anymore
Hi all, some weeks ago, my relay JPsi2 (F6EC46933CE8D4FAD5CCDAA8B1C5A377685FC521) started experiencing moderate stability problems. It would freeze after a few hours or days. The provider said it was due to Spectre mitigations and the only way for me to fix this would be to switch to a newer (more expensive) plan... Some time later I did so and reinstalled it with Ubuntu 18.04 and placed the old keys into the new installation. It seems they are now expected to be in /var/lib/tor/.tor/keys, as opposed to /var/lib/tor/keys as I was used to in Ubuntu 16.04. However, it does not seem to be making it into the consensus anymore. Only the authority nodes moria1, dizum, and longclaw vote for Running. The others don't. So far I haven't been able to figure out the reason for that, so any help is appreciated. Here is part of the output of journalctl -u tor and the torrc file: Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] Heartbeat: It seems like we are not in the cached consensus. Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] Heartbeat: Tor's uptime is 8 days 0:00 hours, with 0 circuits open. I've sent 54.04 MB and received 163.30 MB. Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] While bootstrapping, fetched this many bytes: Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] 9368438 (server descriptor fetch) Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] 1060775 (consensus network-status fetch) Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] 13332 (authority cert fetch) Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] 2762395 (microdescriptor fetch) Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] While not bootstrapping, fetched this many bytes: Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] 111548029 (server descriptor fetch) Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] 100899 (server descriptor upload) Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] 15307429 (consensus network-status fetch) Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] 1785 (authority cert fetch) Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] 942746 (microdescriptor fetch) Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] Average packaged cell fullness: 96.710%. TLS write overhead: 31% Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] Circuit handshake stats since last time: 1/1 TAP, 0/0 NTor. Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] Since startup we initiated 0 and received 0 v1 connections; initiated 0 and received 2 v2 connections; initiated 0 and received 114 v3 connections; initiated 0 and received 1899 v4 connections; initiated 46 and received 5694 v5 connections. Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] DoS mitigation since startup: 0 circuits killed with too many cells. 0 circuits rejected, 0 marked addresses. 0 connections closed. 0 single hop clients refused. 0 INTRODUCE2 rejected. Oct 11 18:14:03 j60204.servers. # cat /etc/tor/torrc OfflineMasterKey 1 SOCKSPort 0 SOCKSPolicy reject * RunAsDaemon 1 ControlPort 9051 HashedControlPassword 16:28CD63819CB35660601EB9CED4BC2A4252D3DB80488DFD4F22CA4AE930 ORPort 9001 ORPort [2a00:1158:3::1ba]:9001 Nickname JPsi2 RelayBandwidthRate 12500 KB RelayBandwidthBurst 12500 KB ContactInfo 0xF1ADC390 Random Tor Node Operator bitcoin:1LBoEppezy2HauE957HzfFn9UGywK6aboB DirPort 9030 MyFamily $B198C0B4B8C551F174FBB841A172616E3DB3124D, $F6EC46933CE8D4FAD5CCDAA8B1C5A377685FC521 IPv6Exit 0 ExitPolicy reject *:* ExitPolicy reject6 *:* signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Relay uptime after restarting Tor service
On 10/07/2016 12:55 PM, Zac wrote: > that my uptime on Atlas is reset to zero when I need to restart > the service, i.e. for updates or configuration changes. > Is this expected behaviour Yes signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] British Airways website blocking non exit relays IPs?
On 05/20/2016 01:18 PM, Pascal Terjan wrote: > I haven't been able to access BA website from home for the last few weeks. > > I have failed to get any other answer on the phone that to try using > Internet Explorer or to wait for things to maybe get fixed. Twitter > support was not more helpful. > > I am now wondering is this is because I run a (non exit) relay. Can > anyone confirm if they also have the problem? > http://ba.com/ I can confirm this. From my home IP: $ curl http://ba.com 301 Moved Permanently Moved Permanently The document has moved http://www.britishairways.com/;>here. From one of my relays (non-exit): $ curl http://ba.com Request RejectedThe requested URL was rejected. Please contact our support team on Telephone: (+44) 0344 493 0787 option 3 (calls charged at local rate within the UK) Daily 06:00-20:00 UK time. Please quote support ID 13240401227566764688 signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Slow bandwidth, bridge + obfsproxy project (+Socks for LAN?)
On 25.04.2016 11:45, Petrusko wrote: > 4. I'm confused, the "bridge" is acting like a relay ? (like a router on > a network, 50% upload / 50% download...?). Or like a hidden door to > contact the Tor network, and the client will only use relays after > without the bridge ? > (I don't want this server to be a bottleneck...!) A bridge is the first hop of a bridge-using client, followed by the other regular hops for a Tor circuit. The bridge's upload and download will directly correspond to the upload/download of the specific user(s) of your bridge. (Plus some overhead for directory requests etc) So if your bridge's internet connection can handle another user next to you, it can handle the bridge. signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] relay maintenance without losing consensus weight?
On 08.03.2016 19:30, Volker Mink wrote: > You can take it down for some days without losing any flags or consensus > weight. > Had it with my exit i have at home. > I had to reinstall it and i have the same stats as before. The HSDir flag will be cleared after each restart of the Tor daemon, and be set again after a certain amount of uptime. The consensus weight doesn't change significantly due to short maintenance outages. signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor Process Being Killed on VPS
On 26.02.2016 00:19, Stephen R Guglielmo wrote: > I have a VPS with 512 MB RAM. [...] The relay is an entry guard and moves > about 20 MB/s. Is that really 20 MegaByte per second? If so, I fear 512 MB RAM won't cut it. According to my experience, for a 100 Mbit/s relay you need at least 1 GB RAM. signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Feedback
On 26.02.2016 13:50, Roman Mamedov wrote: > On Fri, 26 Feb 2016 12:27:07 +0100 > Random Tor Node Operator <t...@unterderbruecke.de> wrote: > >> So in terms of censorship resistance, bridges with occasionally changing >> IP are better for the Tor network than those with static IP. > > EVERY DAY != "occasionally". > > Your idea may have some reason to it, but when the IP changes daily, users > won't learn about the bridge's new IP in time to even get any good use out of > it (few hours at most?) before it changes again. Yes, the time span in which the bridge will be useful is limited, but that is no reason not to keep up the bridge. A bridge that is useful for a couple hours each day is more useful than a bridge which is not available at all. Such short-lived bridge IPs are increasingly important against quickly responding adversaries, which are fast at blacklisting bridge IPs. In such a scenario, short-lived bridges will be the only ones that a user can reach. > Does not help that getting and adding bridges to the client is not an > automated but an entirely manual process currently (as perhaps it needs to > be). That is a completely different issue. signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Feedback
On 26.02.2016 11:54, Tim Wilson-Brown - teor wrote: > >> On 26 Feb 2016, at 11:52, Random Tor Node Operator >> <t...@unterderbruecke.de <mailto:t...@unterderbruecke.de>> wrote: >> >> On 26.02.2016 05:15, torser...@datakanja.de >> <mailto:torser...@datakanja.de> wrote: >>> * Next, i noticed a frequent (daily) behavior of the Tor server >>>dropping traffic to around zero. Inspecting this, let me to >>>understand, my provider was disconnecting me and reassigning a new >>>IP on a daily basis, which took some time to propagate. Even worse: >>>It did not propagate on its own, i needed to restart the tor service >>>to reinitialise... >> >> >> Instead of a Tor Relay, you can operate a Tor Bridge, perhaps with obfs4. >> A regularly changing IP address is less of a problem for bridges. It may >> even be of advantage. Once its IP address gets blacklisted by >> adversarial actors, you already have a new one. > > But how do users find that new address? > (For some users, the bridge authority might tell them when provided with > the bridge's fingerprint, but only if their other bridges work.) Yes, that's the thing when being within a censored environment. A user needs to have at least one bridge or other way to find their way into the Tor network. Imagine a world where all Tor bridges have a static IP. After a while, the adversarial actors would have a complete list of all bridges and successfully block all access to the Tor network. (Except when a brand new bridge pops up) Every bridge would only be useful until first detection by the adversary. But with bridges with dynamic IP, the adversary has to play whack-a-mole with the bridges and chances are, the user within the censored environment will have *some* moles (bridges) which haven't been whacked yet, allowing them access to the Tor network. So in terms of censorship resistance, bridges with occasionally changing IP are better for the Tor network than those with static IP. signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Feedback
On 26.02.2016 05:15, torser...@datakanja.de wrote: > * Next, i noticed a frequent (daily) behavior of the Tor server > dropping traffic to around zero. Inspecting this, let me to > understand, my provider was disconnecting me and reassigning a new > IP on a daily basis, which took some time to propagate. Even worse: > It did not propagate on its own, i needed to restart the tor service > to reinitialise... Instead of a Tor Relay, you can operate a Tor Bridge, perhaps with obfs4. A regularly changing IP address is less of a problem for bridges. It may even be of advantage. Once its IP address gets blacklisted by adversarial actors, you already have a new one. (Of course they could still simply block the whole /16 or whatever your ISP has) A bridge will get a lot less traffic than a relay though. Mine is sometimes idle for weeks, some other time is get a couple GB per month. signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] CVE-2015-7547 Tor network stats
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 23.02.2016 22:12, Tom van der Woerdt wrote:
> Op 23/02/16 om 22:10 schreef Toralf Förster:
>> Louie Cardone-Noott:
>>> Those like me running debian and putting off doing a reboot
>>> might find needrestart (package of same name) and checkrestart
>>> (package debian-goodies) useful.
>>
>> Under Gentoo "lib_users -s" is a useful command IMO to see if a
>> in-use lib was changed.
>
> On most linuxes you can do this with "lsof | grep DEL | grep lib"
Here is a version with better filtering and output:
lsof -n +c 0 | grep 'DEL.*lib' | awk '1 { print $1 ": " $NF }' | sort -u
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBAgAGBQJWzNLfAAoJEJe61A/xrcOQA5AQAI+cXfFAqLcEYdeupGcqjLtf
8Mjyyxq10jtB/zpqbxWqdIxyiDJmF3tzKJmzmrKzNmLsz8hfQbFxYLsZjlhdOHX4
N4fMxCX1FNrxKC4TuGFu3PMeFZlmieIGYF8MVg/yZJ0rx4LlA86t2cDXOzi2Qn57
5DGSoyQ8Ll3XBzDhBYJvPmz7kCc0oyjVO+S0m6+uJc9UMeJtuIrMJGEqQzk//pFC
ltV24qPF1NhtHbHIsNbmjAnTj+KZ5lDnwWHfc6YNGeiPYH+3DtgT8H/rd9I0Vdv/
QkBaq90okwu0UC1K1PeREol60StSkDbCPzVpqWzVgbB0sq2GoVlccgSog2hwuzUJ
mriWh4JxF41NCF0sKNAUVEBHb1VsQQQPn7RVjfHBurDYsDcmPK1LXMDI/AeuWEU0
EX10Fwl7YRzk3UfRICZwT2yVXm3ep9kweKXdMWs4Ql5dM/Y3LQl0/fTm4IzCrO5C
wp5qDQqD5OHRsroG5KTKTS5u0Vw2mkESmVfx40NxWhxPZCsYE35IVsarSfSvDFxt
88mKimYqJUYShBAjKfVtB+yWKzHXOMm5TaQdxYbLHVxYo/b9ndlM/IiyFP4U/HuJ
YmnjMywZE44bJr+SYfgcUn3SWNFY4VrO9qf2Uoh8VtKbHsGOj+SLdG1nLnQOfELU
eaCkGMX0sBif5lhe/Tr+
=v/3o
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Relay isn't getting HSDir flags
Hi, you didn't get the V2Dir flag with AccountingMax set on... I had to have the same experience with that. Random Tor Node Operator hi Am 13.12.2015 um 23:32 schrieb Lucas Werkmeister: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi all! For some reason, my relay[1] isn't getting the HSDir and V2Dir flags. This is the full config, sans comments (sed '/^#\|^$/d' /etc/tor/torrc): SocksPort 0 DataDirectory /var/lib/tor ORPort 9001 Address 78.46.139.153 Nickname BotIfMuvasfo AccountingMax 7900 GB AccountingStart month 15 00:00 ContactInfo Lucas Werkmeister "6B89 5B8B 11A4 75B1 EC93 1698 FC46 2872 72AE 323F" <m...@lucaswerkmeister.de> DirPort 9030 # what port to advertise for directory connections ExitPolicy reject *:* # no exits allowed I reloaded the config several times since I uncommented the DirPort line, and even restarted the relay earlier today just in case enabling DirPort wasn't supported without restart. No luck - both Globe[1] and Atlas[2] don't show the HSDir or V2Dir flags. A few months ago, I had the relay running on a different server. I had enabled the DirPort there for a while, but eventually was forced to disable it since the server couldn't handle the load. But back then, the relay got the flags without any problem. Since I moved to a new server (copying over the torrc and data directories), this doesn't seem to be working anymore. (I am now on Debian 8, tor version 0.2.5.12; the old server was on Debian 7, tor version 0.2.4.27.) Any ideas on what the problem here could be? Thanks a lot, Lucas [1]: https://globe.torproject.org/#/relay/C527AD7D47E9DEC163537A444F4F790433CD67F7 [2]: https://atlas.torproject.org/#details/C527AD7D47E9DEC163537A444F4F790433CD67F7 -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJWbfIFAAoJEPxGKHJyrjI/B3AP/18uMBavSAQeHyYDr5D89bBQ JlTmDwWdolNc7SwNeaUTB8w+KYEatyVXJh7uAF4jrjKIS9eplMMU+1rcLS6C2tO4 4hvu9cYGwXepkuh742ikPIXivj7X08BqP+c38GYyXIC/mxdUJ44AZwGa3z4guWEl 6Qb9FtdxJ2NBMdtHjvmyFTUN2qYK0k6qYzoHygCyrf/OyoHjynkMRPKwaoHEgZhG yBIcf8AlOnKUf5+cVwkUZeurZ0l0KPl0hawUNDELciOMkGchMDyb6ui6u7LbCDVL gRiBToU6RJIiPo6vKw7UbAZeNeodNeXalmLMTL7vuKzhJjYgDae1bTJEQvMWdz6i nNxssOLHhBkTwdJosj1Kaw4a+opcqA8bPJY0KeAaZUnvAGro/lOwb0Tc7oDkbg2b Xb5IuQfWpZzpOuGldfisdqXRL1rySsnCaGSsFT9ulrkXaz42UDQE8pyxy8ErqL4j byhGiQF0F04sWldQPy3AjfZEImtBROx9PetESMLLyD6UYWffEGr6JLtIoolPEA0x OjMOGuyq91gJEZ2xIdlN+kJaylmnu/8kGKD6vAJwBxX8wVHWIyD5KbQOyL2RjCT8 gtiSFdIj8mZmvKUR5svWrgxfGoVGc5a76CUyLF+7Jd+d3DPPOlGXX+dJ/WErjgjH JbmjWbI1OIBai6gKvlSE =BmwK -END PGP SIGNATURE- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] authority signatures consensus-health
hmm weight-drops again? i am loosing my whole traffic / consensus weight... since 7 pm CET. Random Tor Node Operator Am 09.12.2015 um 01:27 schrieb Tim Wilson-Brown - teor: On 9 Dec 2015, at 06:07, tor-server-crea...@use.startmail.com <mailto:tor-server-crea...@use.startmail.com> wrote: hi, wondering what happened to consensus lately? weight-drops, list says was missing authority signatures Some authorities have been down a little recently. Another authority has changed keys recently. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] simple questions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, On 28.11.2015 17:43, David Schulz wrote: > can i get problems as an german citizen with an non exit tor relay > in germany with an italien ip? not realy or? i think of TMG § 8. As a non-exit relay operator, you are most certainly not going to get any legal trouble. - -RTNO -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJWWeXGAAoJEJe61A/xrcOQgggP/iCemXOAMRUe1tuVMvTO5koL VFNBTELa3qztE2Oqt8yfB0TtMStrN3tq6/YvwzySiy0Z1jSDWq4/E0kvUFUSl1EU pZmjoww4K/imfxLqIL9BSiO2l+FV3GF9ZlfaWtDLA4AN5EK6oG883m6KyF73+tKR JMBC7AYHhGbVTSATaRT8GoxaO8ahFG9l9S9hS59qApbXB6/mzSHmFEGG/HRC9128 yLOdtkFZ3qPxULrcm4+CdssSWqjOGyyKgnymlhcPpMEwgDZjjl2G3B/nrTQtzfDS /AT/74IfGZWRDvrXAYwq2JbZ3VxCEbAwfWdquvPi8zvNlvsZ5vJwqtNv+/JxwjtR 4cp+m/Djts5zh2fg8F3QYPzvKi80aBZxpYZxQMUl9vJuWl9TxL+sS8eJcjBHsQAt FRSw5kxrIRGGKsB7bqyT81r2OgMIhZPitu1VNqacUNfTW5yb1Cyd8O4qKxG0MB/i sU6wBzVm0iK9dcU6cNthFGcR6Py8h0o2uIIuxWV6HujyDOW+iczBDPlRhAFl7s0Z Z3tMzoj4BV+SfTcH9YeQF/Ke97+Gbl+02LFlbLQtatfVVtwabt7FjgktCi+1+vv/ r8IXhXeC1GL31F1bmxMYtlJJRkB+TZNcY+llulc+h69yQWQqSMikv7w41qA+H7xl P+QFLGAgN4FlVnLYUz3E =Lm21 -END PGP SIGNATURE- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Out of memory message
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07.12.2014 12:20, Roger Dingledine wrote: Has anybody else here seen messages like this? Some days ago I had a message like that on my relay JPsi2 (F6EC46933CE8D4FAD5CCDAA8B1C5A377685FC521). Tor's memory consumption is rather high there lately. On December 1st, the tor process' memory consumption went up and up until the Linux kernel decided to kill it. Monit has subsequently restarted it, and it settles at roughly 1.7 GB since then. The logs of the corresponding days have already been rotated out, so I cannot post the exact messages I'm afraid. On my other relay Bazinga (B198C0B4B8C551F174FBB841A172616E3DB3124D), the tor process typically uses 0.7 GB memory and did not experience anything like that. Both relays are running at 100 Mbit/s and have 2 GB memory. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJUhEI5AAoJEJe61A/xrcOQb6AP/1QmzXkXD8i6kXIyYH1ME4nz UrjeIhVRVaAXHqnzsc4V5VOYMN1cifjTYtVph5nZUiEaq1j1TqM0fvHE8D9u7Tlk 2Okp1/KmvCNCWx/bsyZYqTeXMSBtqDqPVDtBd/4k+hRG2dnnp9JbaRZJk03nrY9m AQnF0kOp5Eg6Cl0qcOViLzxJBcdboYFeQoGGV5s0mgjXJLubhGsFIAuZXH7Luszn RdxcRXM9R0iOsRgHyyZ+QXNVdWFWcuDjfm9HxQhUFlBFYoJj2QBbpm+KXNODJatZ iimW9sZ+y9VJ+Hgfztf01GQwpu6E0CjzpdNzjz748Z57Jy026yYXmYzLh8XTDrlv yQ6PwHtzqLvnBuEzvnTxG+IbixVL+qyUXW3jvu/ECCVT3lZHkHjHLI/MNbpkVif/ oM9m5ZnDqIAEcQwbY4Z340938jtlXVlhNFTMBluTZPtG2Fpn96hixuN4QoEhJv6z 9OZLpEPtJWpdxb9RHchmjSUekxHHC4lATEDmBPOa53vm4xByepV5qe5/C1hxSUGl TGi3T1tPswmqotB7V3BKsf0CdOYtoAEmZrLJzCJ3sZD1MgY05rx9vS6f9jRlRIBi WFP14EgoVOgpKxp216WVr8PKxjX2q5pVSHqAkswq8l/cis7sj9ln9c0/H3OIhHAZ +onzOLff/vDzlOrbjcQu =8PfV -END PGP SIGNATURE- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] optimize performance of a relay running on a VM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 root@tor:/ # cat /proc/cpuinfo | grep aes cat: /proc/cpuinfo: No such file or directory According to a stackoverflow page [2], you can look for hints indicating the existence of AES-NI support in sysctl hw and /var/run/dmesg.boot PID USERNAMETHR PRI NICE SIZERES STATETIMEWCPU COMMAND 675 _tor 2 200 130M 126M sbwait 567:31 7.96% tor Uses maximum 10-12% of the available CPU. Uses maximum 150 - 160 MB of RAM. (~15%) okay, so CPU doesn't seem to be a bottleneck, as expected. You could try downloading a large (some 100 MBs) file from a fast server via wget to see whether you can saturate your downstream. here is one I am freebie hired to maintain: 6C36F9ACBA57AC9C10DBC39D330CFA337522E72B It is an Exit relay. I am not sure, maybe Tor is designed in a way that Exits are strongly preferred for Exit connections, so they get less traffic for HSDir/V2Dir requests or for being a Rendezvous Point or Introduction Point for Hidden Services. That is mostly speculation on my part though. I never had any Exit relays on my own. Probably the Tor Path Specification [3] has the answer to that question. Your relay seems to be the only one in that /16 subnet, so that wouldn't be a reason for less-than-normal traffic. [2] http://stackoverflow.com/questions/4083848/what-is-the-equivalent-of-proc-cpuinfo-on-freebsd-v8-1 [3] https://gitweb.torproject.org/torspec.git?a=blob_plain;hb=HEAD;f=path-spec.txt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTsxYkAAoJEJe61A/xrcOQ1WUQAKzb4xSA8Wz0u3T4sCn2Q41g URTA4Q9OGDxRvYpO2I9cXOuu4pj2g+jWsxOH1uX8g1O6uY7u6n5cYj0FYczbDSJm wn9ySxIo8wJAZCTStJmXQhgm9oceq7EDgiVsRQAXQilkv3i2JnfToNLMH80vMuKH x6Wj6lfzEWs2/8NG/WxNmJuv4O7w/mPJ1LeCqLsuL8O3ni03Ql0iPnohyhbQrJCo vAbKaj1ix65eSNahLqcH53MF3x+FkkG0ULTgWebjCg731kqVFOzsrRQQY4oZXo+k +fx+7kodjqQdQ7xSRpaTBe/15NE8Xk8hT9Ib9jVQ9Zyo19EcP6NIxnYC+zJD2G++ xQtcpur6N5XZCruuC+GoUsdYB/6lrLJHJ+SaqXachhEfqcXm1DaIH0wJb7Zre2Jf 4eS/H/Fp0+msKFHq3ElL7TcnxpMOMUkoAp4d7jbi8v/0u5DHuMRQDVTlIfpSX3fJ HMBQo9K1jf1iInCx7vpLFe7f+m5tH+PRTME8ZBTJ6PnAUbrrQW4khBF8P3J6gqm9 1DTH16BF+B2zNhQhyKI9c8T6CFIxXdnTwUAYFwHA8GQII6qP2M2ykK9ELpN1y/o8 dFTOMe017L4jM+73yhoNIddbGoCqBlIGu+1vv/OK/uk+s5Lmh3fveajOsECAcBpq HzlYGmmOy6UuWsClZL+X =fnHk -END PGP SIGNATURE- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] using Arm to manage nodes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/07/2014 07:24 PM, ja...@icetor.is wrote: Hello all, This is something that's bothered me for quite some time. I often use arm (https://www.torproject.org/projects/arm.html.en) for monitoring my relays and to keep a quick eye on things like overall bandwidth consumed, traffic stats and my favorite client locale statistics. I run it in a screen session and often when I re-attach the session often the keymapping is all messed up and the arrow keys will offer to close arm. Usually it will correct after I shift-m to get to the menu and switch around a few times. Has anyone else experienced this and how did you solve it? -Jason ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays It happens to me too, sporadically when arm sits around for a while. Also, sometimes the screen output gets garbled and arm thinks I was pressing a key, like x for SIGHUP or q for quit. It looks like the traffic to and from arm gets somehow corrupted. I haven't found a good explanation or any solution yet, other than quitting and restarting arm. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS9TiYAAoJEJe61A/xrcOQ0XwQALN4rJTYqnERtHP07OUjcvyA BgEXfQeUdAyaB7rrgX1/fed6jxaIXVQKyqMdVElY5XHKSWpC6fQxTdI9tO1D7Mez CS4qeOAI4H87PE3zzDgaOyDG3W2xAeeXhDTAwpMcyOvBUOwmw9RMZ8gNye2pUTeB MWD2y0NpnD1iyVaOdQ5eoTJ1LqCLKKDfKc6U71roMdyXLJzcOqPskEfg+o8P3irD ZbV6KglwD+H0qzc0AZCuqVifM4UnZgUleAKe0NsawzetafZQ1cmRSiyStT85WSrj h4qQeI9dY5SRxvVF8/cWVF7ib9c/NEIkS9Za16PocYViyb62q80jV34BAYaB0QHK JorQgzhdbrZ3YL78QwDfpV0UmnQnxqsWjPL+XrCRttwjS/Kvq/CVXzGiLemaPKK2 +iI2MjwKA1aTNdJvfKTQLTWOCdZLKnsm6CBjZKWmxHDRkA505YCIjfHlKa6c5jjg Y1w75OiwkNpyIFITUM3ZG1yys5dD2q9NYeFh8dBNjHQS9jPG+WjWeZoNx41uthqg ns5wp/Tgw1JHIUOEBTZHTVqXNdmkwl39VJIzy8paXyTCm5BsZo1uByXux0UMP3DZ kPU2Iz4F/39XFZpZmJhCSPGObrjkHi90Y+vkLqRsieN/1ZyyBZQhzch6hz8EjpUd eLn/N3MCF9Y41nVupo/5 =ODX7 -END PGP SIGNATURE- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Tor crashes frequently on fast relay
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello everybody, since this botnet started flooding Tor, my Tor relay Bazinga ($196832C61F30E9D6D179393C9AED4E47FD29796B) has been experiencing some issues. Previously, it was relaying 100 Mbit/s for a few months without problem. When the botnet came along, at first the throughput dropped to about 30 Mbit/s and Tor kept spamming Your CPU is too slow and crashed every hour or so. I set RelayBandwidthRate to 20 Mbit/s which reduced the crash frequency. Then, 0.2.4.17-rc was released and I lifted RelayBandwidthRate back to 100 Mbit/s. At first it was running fine, but then the crashes came back. This is from yesterday and the day before: $ sudo grep -i interrupt /var/log/tor/log.1 Sep 10 08:59:40.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 10 10:01:45.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 10 11:04:50.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 10 12:49:56.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 10 13:51:01.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 10 15:22:18.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 10 16:07:27.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 10 18:56:03.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. $ sudo zcat /var/log/tor/log.2.gz|grep -i interrupt Sep 09 06:51:20.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 07:54:30.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 08:48:36.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 09:51:56.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 10:20:01.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 10:49:06.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 13:03:26.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 13:26:40.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 13:50:47.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 14:02:54.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 14:26:06.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 14:42:11.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 14:52:17.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 15:08:31.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 15:21:37.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 15:31:27.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 15:44:32.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 15:53:38.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 16:02:45.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 16:08:50.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 16:16:56.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds.
Re: [tor-relays] Tor crashes frequently on fast relay
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/11/2013 12:37 PM, Roger Dingledine wrote: In my case I use 'monit' to monitor my server and the running services - including tor. Once in a while the automated TCP check on either the OR-Port or the DIR-Port failed which resulted in monit stopping and starting tor. Yow. That doesn't sound like what you wanted (nor does it sound good for the Tor network). Do you only mean the unneccesary restarts or the way of checking for a running tor instance by checking the reachability of the ORPort? If the latter, which (preferably monit-compatible) other method would you prefer? - --RTNO -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSMFaAAAoJEJe61A/xrcOQWtIP/0AXixNfgsBJfUNwpk7Bl3ew CnInGn+Ad28AXpSCixMMa/1e+6h3+AH0dVv64HLeqVxeNWelKD4icu2+r/RUzrYW VNJTN60tJFFZOrvZXVWsXsDSq7v+dPn2kxDGlcPVclvte9TueHpAfou/k0757jOe 4zK1SAnkFK1ybebubvNtDghsUeRSbtZB6dsQgpa3qV5SfqXWkJ/uAsQvoGhplYcx 9ouzoGe5mil+Zxlt3e2kTJv9Nj0mCfFPtnWCTV5Df4xZ6UUvT9bSlV1dfKV0Rv1f MGPHr4xQ2hAaW1NmvBUuzVZ9LIPHcrf+0sOXbO9I9g4GwbgHHZKd/4b6fH+xnI35 PL+O6j4KErSQnX4gdXZa4I6B3L9Esa/cmejxqeddVdqs7L9GU1HvUcM/XqSXyWhx TD9L4nfgNy1ZtP0xo6BK3JgwBlHiJqywenacFlVDzl0fCHSicMOgAyznW/Fb7ytC 5E+5sR1XSvdlTx3yVEGZQoEQwDqK7PPm8tKZZCB67lJK4Xj0Bfy51R0AQx9CbTGm cUKbl7gd6L8yLayXCWWKkEHFpwh2klmPEaS4eG7vSielGWPLzxxWjig0sI4AvOfT iFFmoxt6AjQgtuvhZoHtD/1kI5VVnQlQeLMxogCl7DyFrrXrQKdZ1SUKsovGLKhf LvKVgwAMVzrpuFcVSw0K =cdxC -END PGP SIGNATURE- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor crashes frequently on fast relay
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/11/2013 02:18 PM, Stephan wrote:
On 11.09.2013 13:33, Random Tor Node Operator wrote:
Could you post the corresponding line(s) in your monitrc?
Of course. I use the default of set daemon 120, so tor is checked
once every 120 seconds ('one cycle'). The tor specific part of the
configuration is this:
if failed host 127.0.0.1 port 9030 type tcp for 10 cycles then
restart if failed host 127.0.0.1 port 9001 type tcp for 10 cycles
then restart if 5 restarts within 100 cycles then timeout
I'm still experimenting with the exact numbers. Restarting after
only one failed check was obviously too fast. Waiting for 10
consecutive failed checks (i.e. tor is not responding for 20
minutes) may be too long, but I don't want to ruin the 'stable'
flag only because a botnet is wreaking havoc for a few minutes.
The last line is kind of a safeguard. I get monit alerts by email.
If something is seriously broken with my server (or tor) five mails
will suffice. Even if I am on vacation for a few weeks, I don't
need a reminder every 20 minutes. ;-)
Thanks. My cycle time is 60 seconds and I'm now trying out 5 cycles
for restarting.
Bazinga's Stable flag is already gone due to those rogue restarts.
It'll hopefully recover soon.
- --RTNO
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJSMIK6AAoJEJe61A/xrcOQa9oQAKu7qNF96HgcAjvYHSI5tkwb
CX5U/hvxaXQj1wvYDKcoodVBL8rTmUNzeblI0pGIsAZ57znwPOII05OwspUJznor
kDdmZbihtqwENwQ/Z02iGH2mLu9HMpcm8el5X8gTtSHyWM3vU2UrvVUxV2VJBsal
U/TUGILNLv/aETGslQxcXM8d1h5IdOsbGts61VpjbITEqfTepXF3/zzrp0ZaxjD6
AXyLAdIs2uZRo1AtrYDwfOw2yb11qEpKnXfd6foB1+9EVLoVuJyJnR95IYipY8Wa
krFHdY32IkOljZhtVy9nIS6DUQP4Ld57FqvNHJ2sHIUNc3vUmtY88pDgjaFqHln/
5qdogx+3IiRsGYQpg/xQmNl0y+elKfw+3YRKkSWE0eI2htTBdrqw/FShRFeH83YI
e7tmJZrj0WEcVM+yl4RcsXPvLC0wY64JFo1tqTICvqmFwHxqyikw6+FUKg0knygU
/O14i0BC6o3dl8VzN80dlLZrbeDd/MFDKw/rO8UbC1GfufaklQ/i+qvArgpwwqz0
6H9NeEzmz8xrS5jVdLu3TAH8IAcDl93xlPzjDWpoTwbpLOK/B8/hFvph/7xTlPfy
fOd7MlzStPyrbQftWg3LYU9svQphMbC1dGZFGm9gcuiYAB68KAz42ymWIPu6JWoy
mxt725/8dzu/bv8b6Kek
=Xy7A
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
