Re: [tor-relays] DoS stats from exits running 0.3.3.2-alpha

[Tyler Johnson]

Sometimes I get lost, and only now realize you wanted statistics from exit
relays, my bad.

As an operator of two guard relays that were impacted by the recent
disruptive activity, the update has also made a difference.

I'll just go crawl back under my rock now...

On Feb 17, 2018 09:13, "Tyler Johnson" <tylrcjh...@gmail.com> wrote:

Updated yesterday to 0.3.3.2-alpha on OpenBSD 6.2 with KISTLite
scheduler and no firewall rules to hinder the onslaught.

SVnode01 9CAFA2463A0DBE02847ED3405185CF67DA38BF8E

Heartbeat: Tor's uptime is 17:59 hours, with 17370 circuits open. I've
sent 330.92 GB and received 327.63 GB.
Circuit handshake stats since last time: 25697/25697 TAP, 2762784/2762784
NTor.
Since startup, we have initiated 0 v1 connections, 0 v2 connections, 0
v3 connections, and 13287 v4 connections; and received 2 v1
connections, 1428 v2 connections, 2589 v3 connections, and 82690 v4
connections.
DoS mitigation since startup: 1009480 circuits rejected, 37 marked
addresses. 11194 connections closed. 123 single hop clients refused.

SVnode02 4145156A89030F19F6581352028F024621F93AA4

Heartbeat: Tor's uptime is 17:59 hours, with 15093 circuits open. I've
sent 295.51 GB and received 293.41 GB.
Circuit handshake stats since last time: 48546/48546 TAP, 2589921/2589921
NTor.
Since startup, we have initiated 0 v1 connections, 0 v2 connections, 0
v3 connections, and 14303 v4 connections; and received 5 v1
connections, 1281 v2 connections, 2297 v3 connections, and 83297 v4
connections.
DoS mitigation since startup: 3909995 circuits rejected, 45 marked
addresses. 527051 connections closed. 90 single hop clients refused.

SVnode03 869B0F952905601BE1B5D8062964FA436DC3FD96

Heartbeat: Tor's uptime is 17:59 hours, with 22207 circuits open. I've
sent 276.00 GB and received 277.80 GB.
Circuit handshake stats since last time: 241061/241061 TAP,
7074179/7074179 NTor.
Since startup, we have initiated 0 v1 connections, 0 v2 connections, 0
v3 connections, and 9712 v4 connections; and received 2 v1
connections, 3273 v2 connections, 4556 v3 connections, and 82336 v4
connections.
DoS mitigation since startup: 242 circuits rejected, 2 marked
addresses. 12495 connections closed. 231 single hop clients refused.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] DoS stats from exits running 0.3.3.2-alpha

[Tyler Johnson]

Updated yesterday to 0.3.3.2-alpha on OpenBSD 6.2 with KISTLite
scheduler and no firewall rules to hinder the onslaught.

SVnode01 9CAFA2463A0DBE02847ED3405185CF67DA38BF8E

Heartbeat: Tor's uptime is 17:59 hours, with 17370 circuits open. I've
sent 330.92 GB and received 327.63 GB.
Circuit handshake stats since last time: 25697/25697 TAP, 2762784/2762784 NTor.
Since startup, we have initiated 0 v1 connections, 0 v2 connections, 0
v3 connections, and 13287 v4 connections; and received 2 v1
connections, 1428 v2 connections, 2589 v3 connections, and 82690 v4
connections.
DoS mitigation since startup: 1009480 circuits rejected, 37 marked
addresses. 11194 connections closed. 123 single hop clients refused.

SVnode02 4145156A89030F19F6581352028F024621F93AA4

Heartbeat: Tor's uptime is 17:59 hours, with 15093 circuits open. I've
sent 295.51 GB and received 293.41 GB.
Circuit handshake stats since last time: 48546/48546 TAP, 2589921/2589921 NTor.
Since startup, we have initiated 0 v1 connections, 0 v2 connections, 0
v3 connections, and 14303 v4 connections; and received 5 v1
connections, 1281 v2 connections, 2297 v3 connections, and 83297 v4
connections.
DoS mitigation since startup: 3909995 circuits rejected, 45 marked
addresses. 527051 connections closed. 90 single hop clients refused.

SVnode03 869B0F952905601BE1B5D8062964FA436DC3FD96

Heartbeat: Tor's uptime is 17:59 hours, with 22207 circuits open. I've
sent 276.00 GB and received 277.80 GB.
Circuit handshake stats since last time: 241061/241061 TAP,
7074179/7074179 NTor.
Since startup, we have initiated 0 v1 connections, 0 v2 connections, 0
v3 connections, and 9712 v4 connections; and received 2 v1
connections, 3273 v2 connections, 4556 v3 connections, and 82336 v4
connections.
DoS mitigation since startup: 242 circuits rejected, 2 marked
addresses. 12495 connections closed. 231 single hop clients refused.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Api for atlas.torproject.org

[Tyler Johnson]

On Thu, Feb 15, 2018 at 7:26 PM, flipchan  wrote:

> Hey,
> Im trying to write an ip checker script for a mail server/firewall and i
> want to be able check if the ip is a tor relay, is their a api for looking
> up ips on atlas.torproject.org ?
>


 I found querying https://onionite.now.sh and grepping the result was an
easy way to determine if an IP address is a relay or not.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Experimental DoS mitigation is in tor master

[Tyler Johnson]

at a first glance master (tor-0.3.3.1-alpha-42-g2294e330b) works like a
charm here at a hardened stable Gentoo with vanilla kernel 4.14.16 at both
Tor exit relays


Is that with or without additional firewall rules to combat the abundant
connection issues?
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] High number of simultaneous connections from a single host

[Tyler Johnson]

>
>
>
> However I'm still interested in how to block this kind of abuse outside of
> tor
> itself. I'm looking to implement some iptables limiting and I'm wondering
> how
> the limits should be so that I don't deny normal tor traffic.
>
> Would a 10 connections per IP limit be OK? Should be higher than that?
>
>
https://lists.torproject.org/pipermail/tor-relays/2018-January/014100.html
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Good vsp providers

[Tyler Johnson]

Thank you!

On Jan 19, 2018 20:42, "teor" <teor2...@gmail.com> wrote:

>
> On Jan 19, 2018 08:07, "niftybunny" <ab...@to-surf-and-protect.net> wrote:
>
> I got around 80-100mbit with an 200mbit VPS. Please remember: Tor will NOT
> use all your bw. So this is as good as it gets.
>
>
> On 20 Jan 2018, at 01:45, Tyler Johnson <tylrcjh...@gmail.com> wrote:
>
> Even if RelayBandwidthRate is set to maximize the available bandwidth?
>
>
> Yes.
> RelayBandwidthRate is the maximum limit on your relay's traffic.
>
> The bandwidth authorities allocate a consensus weight to your relay
> based on the RelayBandwidthRate and measured bandwidth.
>
> Then clients use your relay in proportion to its weight.
> This usage is below your RelayBandwidthWeight.
>
> Here are some good reasons why usage isn't 100% :
> * Tor needs some extra bandwidth for SSL/TCP/IP, and directory fetches
> * Tor usage varies throughout the day
> * Networks need reserve bandwidth to provide good latency
> * Networks need extra bandwidth to handle extra loads
>
> T
>
> ___
> 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] Good vsp providers

[Tyler Johnson]

Even if RelayBandwidthRate is set to maximize the available bandwidth?

On Jan 19, 2018 08:07, "niftybunny"  wrote:

I got around 80-100mbit with an 200mbit VPS. Please remember: Tor will NOT
use all your bw. So this is as good as it gets.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Good vsp providers

[Tyler Johnson]

Are the advertised bandwidths from online.net what you will see in actual
practice? For instance, if one of their LTS servers comes with 300Mbps,
will you get close to that throughput?

 I have a few servers with oneprovider.com (online.net reseller I believe)
and it's about 1/10 what is advertised, which is still good, considering
the cost, but I'd like to run higher bandwidth relays.

Also, does anyone know if the KVM offered through online.net have virtual
media capabilities?

Thanks,

Tyler

On Jan 19, 2018 03:16, "niftybunny"  wrote:

Okay, you are from the US. Tor is legal in the US and legal in EU. You
should be fine. I would not recommend  running a Tor Exit if you are from
 Russia, UAE or Turkey. I used to have 20 Exists with Online.net and I got
lots of abuse but they were fine after verifying me. And by the way, you
dont have much choice with traffic flat and Tor exit friendly anyway.

Markus


On 19. Jan 2018, at 01:20, Fabian A. Santiago 
wrote:

On January 18, 2018 6:26:40 PM EST, Mirimir  wrote:

On 01/18/2018 11:54 AM, niftybunny wrote:

You will held responsible to your actions (traffic). So worst case

scenario is: They give your personal data to a LEA and you are now in
charge to explain to a LEO that this is a Tor Exit.

Depends on your country if this is a good idea. If you dont want any

personal data with your VPS, get a bulletproof VPS but even offshore
ISPs ban Tor Exists together with CP and hate speech.


Welcome to the wonderful world of Tor Exists.
Enjoy your stay.

Markus


How about HostSailor? They accept Bitcoin, and don't authenticate
customers. But I don't know how they'd handle Tor relays.

On 18. Jan 2018, at 23:45, Fabian A. Santiago

 wrote:


January 18, 2018 4:50 PM, "George"  wrote:

niftybunny:

online.net 
trabia.com  (ask first)

both offer 100mbit for less than 5 euros


This is a CSV file that TDP is slowly tinkering with. While it's

focused

on BSD-providing VPSs, most offer more.


https://github.com/torbsd/torbsd.github.io/blob/master/docs/bsd-vps.md


g

--

34A6 0A1F F8EF B465 866F F0C5 5D92 1FD1 ECF6 1682

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


I asked online.net about their cloud ssd vps service and tor and

have the following dialog going:


"
Hello. I'm interested in running a Tor relay exit node on your cloud

SSD vps product. Is this allowed? I would be running a reduced reduced
exit policy. Thank you.




Flavio Pastore 1/18/18 5:13 PM
Hello,

Thanks for your ticket.
Our platform is a IaaS one. So, if you're willing to set up legal

activities, you're more than welcome regardless of the service used. If
not, you will reported accordingly.


I hope I have this point clear, but we remain here at your entire

disposal for any further information.


Best regards,

Flavio
Online / Scaleway
Looking for an amazing job? Join us NOW !

https://careers.scaleway.com/




fabian.santi...@gmail.com 1/18/18 5:40 PM
By legal services, do you mean a mechanism in order to respond to

abuse reports? if so, i have covered that need by the following:


1.> i publish a tor readme html page on the server for anyone to

browse to learn about tor and what my server is doing. it also includes
links to the tor project's own pages with additional information. I
would also be published in the tor atlas showing my node's information
for all to see that i am a tor node.

2.> i publish contact information so that complaint concerns can be

addressed to me directly as needed.


will this suffice in your opinion? could you also make a note on

your end that I would be running an exit relay so that you know, in
case you do wind up receiving complaints about my node's traffic? I
find (and have read) that with a reduced reduced exit policy the chance
for complaint generating traffic is greatly minimized anyway. thank
you.

"

so they seem to be kewl with it but in your opinions, what does he

mean by "legal activities"? Thanks.


--

Thanks,

Fabian S.

OpenPGP: 3C3FA072ACCB7AC5DB0F723455502B0EEB9070FC
___
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

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


Uggh, monthly recurring Bitcoin payments sounds painful. Nah.

Maybe not a good idea then with online.net. they seem to 

Re: [tor-relays] Setting myfamily

[Tyler Johnson]

Each relay only needs to list the other servers in its family; it
doesn’t need to list itself, but it won’t hurt if it does.

On Thu, Jan 4, 2018 at 12:26 PM, Fabian A. Santiago
 wrote:
> When setting myfamily on a particular relay, do you list itself plus others 
> or only others?
>
> I ask because it's my understanding that you set itself + others but on 
> atlas, for one relay I see in its family listing, it shows itself plus the 
> 2nd one. And therefore it receives a (3) after it's nickname in the atlas 
> listing.
>
> On the other relay it only lists the other in family listing. And it has a 
> (2) in it's atlas listing next to nickname.
>
> They're both set the same as in they each list themselves + the other.
>
> Thanks.
> --
>
> Thanks,
>
> Fabian S.
>
> OpenPGP: 3C3FA072ACCB7AC5DB0F723455502B0EEB9070FC
> ___
> 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] Recent wave of abuse on Tor guards

[Tyler Johnson]

Every IP I was checking through Atlas which are part of the mentioned hosts
were NOT relays, all client connections.

On Dec 22, 2017 9:20 AM, "niftybunny" <ab...@to-surf-and-protect.net> wrote:

> Thats “only” “relays” with multiple connections to your relay?
> Interesting to see Hetzner there …
>
> Markus
>
>
> On 22. Dec 2017, at 16:14, Tyler Johnson <tylrcjh...@gmail.com> wrote:
>
> Out off 133 IPs blocked with my rather aggressive firewall ruleset:
>
> leaseweb.com - 26
> your-server.de - 66
> ip-54-36-51.eu - 17
>
> That was in < 24hrs.
>
> On Dec 22, 2017 3:38 AM, "niftybunny" <ab...@to-surf-and-protect.net>
> wrote:
>
>> Short answer:
>>
>> https://i.imgur.com/8QLptcz.png
>>
>> Around 15000 - 18000 connections I can see with netstat. Even my 300 mbit
>> exit has less and there a a lot of Leaseweb clients connecting to me ...
>> The interesting thing is, it comes and goes in waves. From 6000 (normal)
>> to 2 connections within an hour.
>> Someone doesn't like me very much :(
>>
>> Markus
>>
>>
>>
>> On 22. Dec 2017, at 08:42, Felix <zwie...@quantentunnel.de> wrote:
>>
>> Am 22-Dec-17 um 08:25 schrieb niftybunny:
>>
>> Still under heavy attack even with the MaxMemInQueues and 0.3.2.8-rc. I
>> need 2 xeons to push 30 mbit as a guard/middle …
>>
>>
>> Do you want to share some information:
>>
>> Type i)
>> (memory exhaustion by too many circuits)
>> What is the memory(top) per tor and its MaxMemInQueues ?
>> How many circuits per hour in log ?
>>
>> Type ii)
>> (cpu exhaustion by too many 'half open' tor connections)
>> Is your number of open files normal (fw in place) and moderate
>> connection counts per remote IP ?
>>
>> Type iii)
>> (One fills your server with too many long fat pipes, first ACK and RTT)
>> If on Freebsd, is "mbuf clusters in use" (netstat -m) moderate ?
>> Do you get "kern.ipc.nmbclusters limit reached" in messages ?
>>
>> --
>> Cheers, Felix
>> ___
>> 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
>>
>> ___
> 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
>
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Recent wave of abuse on Tor guards

[Tyler Johnson]

Out off 133 IPs blocked with my rather aggressive firewall ruleset:

leaseweb.com - 26
your-server.de - 66
ip-54-36-51.eu - 17

That was in < 24hrs.

On Dec 22, 2017 3:38 AM, "niftybunny"  wrote:

> Short answer:
>
> https://i.imgur.com/8QLptcz.png
>
> Around 15000 - 18000 connections I can see with netstat. Even my 300 mbit
> exit has less and there a a lot of Leaseweb clients connecting to me ...
> The interesting thing is, it comes and goes in waves. From 6000 (normal)
> to 2 connections within an hour.
> Someone doesn't like me very much :(
>
> Markus
>
>
>
> On 22. Dec 2017, at 08:42, Felix  wrote:
>
> Am 22-Dec-17 um 08:25 schrieb niftybunny:
>
> Still under heavy attack even with the MaxMemInQueues and 0.3.2.8-rc. I
> need 2 xeons to push 30 mbit as a guard/middle …
>
>
> Do you want to share some information:
>
> Type i)
> (memory exhaustion by too many circuits)
> What is the memory(top) per tor and its MaxMemInQueues ?
> How many circuits per hour in log ?
>
> Type ii)
> (cpu exhaustion by too many 'half open' tor connections)
> Is your number of open files normal (fw in place) and moderate
> connection counts per remote IP ?
>
> Type iii)
> (One fills your server with too many long fat pipes, first ACK and RTT)
> If on Freebsd, is "mbuf clusters in use" (netstat -m) moderate ?
> Do you get "kern.ipc.nmbclusters limit reached" in messages ?
>
> --
> Cheers, Felix
> ___
> 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
>
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Too many connections warning

[Tyler Johnson]

I believe this warning describes a lack of available file descriptors,
limiting the amount of connections your tor relay is able to make.

ulimit -n is exactly the command you want to use to raise that limit from
your current 1024.

What exactly that number should be, I couldn't say, but you could start at
1 and raise / lower based on your needs and resources.

Raising a similar limit on OpenBSD from the default to 2 helped
eliminate the error for me.



On Dec 7, 2017 7:28 AM, "Logforme"  wrote:

> I run the non-exit relay Logforme (855BC2DABE24C861CD887DB9B2E95
> 0424B49FC34).
>
> Today I saw a new warning in my tor log file:
> Dec 07 09:48:12.000 [warn] Failing because we have 32735 connections
> already. Please read doc/TUNING for guidance.
>
> The relay runs on an old Debian Wheezy machine. Me being a Linux noob I
> tried to read the doc/TUNING document (https://gitweb.torproject.org
> /tor.git/tree/doc/TUNING) but the only information I deemed suitable for
> me was "Use ulimit -n", which I ran and it reported "1024". I guess that's
> not of interest for this warning.
>
> Over the years I have added some stuff to my sysctl.conf file that I have
> picked up. Don't remember from where:
> # Tor
> net.core.rmem_max = 33554432
> net.core.wmem_max = 33554432
> net.ipv4.tcp_rmem = 4096 87380 33554432
> net.ipv4.tcp_wmem = 4096 65536 33554432
> net.core.rmem_default = 524287
> net.core.wmem_default = 524287
> net.core.optmem_max = 524287
> net.core.netdev_max_backlog = 30
> net.ipv4.tcp_mem = 33554432 33554432 33554432
> net.ipv4.tcp_max_orphans = 30
> net.ipv4.tcp_max_syn_backlog = 30
> net.ipv4.tcp_fin_timeout = 4
> vm.min_free_kbytes = 65536
> net.ipv4.tcp_keepalive_time = 60
> net.ipv4.tcp_keepalive_intvl = 10
> net.ipv4.tcp_keepalive_probes = 3
> net.ipv4.ip_local_port_range = 1025 65530
> net.core.somaxconn = 30720
> net.ipv4.tcp_max_tw_buckets = 200
> net.ipv4.tcp_timestamps = 0
> net.ipv4.tcp_challenge_ack_limit = 9
>
> None of the values seem to match the 32735 mentioned in the warning so I'm
> at a loss for what I am supposed to change.
> Anyone knowledgeable of these things that can give me some pointers?
>
>
> ___
> 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 t-shirts

[Tyler Johnson]

On Oct 20, 2017 14:38, "Vasilis"  wrote:


Has everyone eligible for a Tor t-shirt got one already?


What is the criteria for said eligibility?
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Email suggesting to send DNS requests to a specific open DNS

[Tyler Johnson]

This guy sure is persistent!

Check out this recent thread:
https://lists.torproject.org/pipermail/tor-relays/2017-September/012934.html



On Sep 12, 2017 11:17,  wrote:

> Hello,
>
> Recently, I installed a new Tor exit node. A few days later, I received an
> email on the address given in the node contact information. This email
> suggests to change the DNS server my node use, and gives me a specific IP
> address to use.
>
> Here is the mail (obfuscated with sharps) :
>
> EMAIL BEGIN
> ***
> * Sender : info AT backplanedns DOT org
> * Subject : Your TOR node
> * Body :
> **
> ** Hello,
> **
> ** I came across your TOR relay on atlas. I run a few relays myself
> ** along with a bunch of DNS resolvers which are a part of the Open
> ** Root Server network (ORSN.org) - aimed to fight internet
> ** censorship and circumvent government surveillance programs
> ** (ie. prism).
> **
> ** I hope you may be interested in using our anonymous open DNS
> ** resolvers on your relays.
> **
> ** https://BackplaneDNS.org
> **
> ** Resolver - 172.98.193.4#
> **
> ** Resolver - 162.248.241.9#
> **
> ** --
> **
> ** Hostmaster@:
> ** Mr. D# E H#
> **
> ** Phone:
> ** +1 (###) ###-
> **
> ** E-Mail:
> ** info AT backplanedns DOT org
> ** abuse DOT backplanedns DOT org
> **
> ** Linkedin:
> ** http://linkedin.com/in/d-##-#/
> ***
> EMAIL END
>
> I think it could be an attack. If this person send this email to every new
> exit node operators, there may be a small percentage of rookie operators
> who will make the change. I found this webpage about Tor exit nodes and DNS
> :
> https://nakedsecurity.sophos.com/2016/10/05/unmasking-tor-users-with-dns/
>
> What do you think about this email ?
>
>
>
>
> ___
> 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] Would you also like to have family-level atlas pages?

[Tyler Johnson]

I realize now why I don't tend to voice my opinion on these lists... I'm an
idiot :(

After seeing the below example, I think it's a great idea.

Sorry for the noise

On Sep 11, 2017 21:37, "John Ricketts"  wrote:

Roger,

The kind folks at Nos Oignons gave me the code.  I still have it if you
can't find it.

https://nos-oignons.net/Services/index.en.html is an example.

John



On Sep 11, 2017, at 20:55, Roger Dingledine  wrote:

On Mon, Sep 11, 2017 at 10:10:00PM +, nusenu wrote:

I suggested family-level pages where an operator of more than one relay

can see all the relays of his family including aggregated (stacked)

graphs for the graphs that are already available on a per-relay level.


Good idea.

The Nos Oignons folks had some scripts you can hack together to measure
and visualize your group of relays, but I spent a while hunting and I
couldn't find it now.

While we're doing feature requests, once the "per family" view exists,
I would want to use the same view on other groups of relays, like "per
country" and "per AS". I can fake some of that with Compass:
https://compass.torproject.org/
but it would be great to have it in a site that's maintained. :)

Thanks!
--Roger

___
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
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] *.old files in ./keys are too new

[Tyler Johnson]

Are you sure about that?

On Jul 19, 2017 13:47, "Toralf Förster"  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> I do wonder, why the *.old files are newer than their counterparts:
>
> - -rw--- 1 tor tor 887 Jul 15 21:51 secret_onion_key
> - -rw--- 1 tor tor  96 Jul 15 21:51 secret_onion_key_ntor
> - -rw--- 1 tor tor  96 Jun 17 21:30 secret_onion_key_ntor.old
> - -rw--- 1 tor tor 887 Jun 17 21:30 secret_onion_key.old
>
> - --
> Toralf
> PGP C4EACDDE 0076E94E
> -BEGIN PGP SIGNATURE-
>
> iI0EAREIADUWIQQaN2+ZSp0CbxPiTc/E6s3eAHbpTgUCWW+pNRccdG9yYWxmLmZv
> ZXJzdGVyQGdteC5kZQAKCRDE6s3eAHbpTsBLAP91Hst68PmoK3y6e5v3xBrKqNjD
> CW0a9Qn6vDj7O0EsFQD8DmPvK2xgIO6N4G2vsR+Beb5Py+CZoX93PtPBz/xVxNM=
> =nECn
> -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] Bandwidth Accounting troubles

[Tyler Johnson]

>
> This seems to be an internal state management issue.
> I have opened ticket #21810 to track it.
> https://trac.torproject.org/projects/tor/ticket/21810
>
> I would like to confirm tor's behaviour when this happens:
>
> Is there something listening on 185.92.223.3:8080?
> Is it this tor process, or another tor process?
> If it is this tor process, is tor still working as a relay despite the
> warnings?
>

For comparison, some stats while the relay server is running correctly...

$ netstat -an -p tcp -f inet | grep LISTEN
tcp  0  0  127.0.0.1.25   *.*LISTEN
tcp  0  0  *.22   *.*LISTEN
tcp  0  0  *.443  *.*LISTEN
tcp  0  0  185.92.223.3.8080  *.*LISTEN
tcp  0  0  *.80   *.*LISTEN

$ netstat -an -p tcp -f inet | grep ESTABLISHED | wc -l
1356

$ ps aux | grep _tor
_tor 75460 12.8 24.4 120976 187772 ??  S Sat11AM   60:50.02
/usr/local/bin/tor


If there are more prudent tests/commands that would provide more
information, please let me know!

Thanks,

Tyler
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Bandwidth Accounting troubles

[Tyler Johnson]

>
> I would like to confirm tor's behaviour when this happens:
>
> Is there something listening on 185.92.223.3:8080?

No, there doesn't seem to be:

$ netstat -an -p tcp -f inet | grep LISTEN
tcp  0  0  *.443  *.*LISTEN
tcp  0  0  127.0.0.1.25   *.*LISTEN
tcp  0  0  *.22   *.*LISTEN
tcp  0  0  *.80   *.*LISTEN

A port scan of the server shows the tor port as closed...

$ nmap -sT tcj.me

Starting Nmap 7.01 ( https://nmap.org ) at 2017-04-01 09:59 CDT
Nmap scan report for tcj.me (185.92.223.3)
Host is up (0.15s latency).
Not shown: 996 filtered ports
PORT STATE  SERVICE
22/tcp   open   ssh
80/tcp   open   http
443/tcp  open   https
8080/tcp closed http-proxy

Nmap done: 1 IP address (1 host up) scanned in 11.10 seconds


> Is it this tor process, or another tor process?

Only have the one process running still...

$ ps aux | grep tor
_tor 45694  0.0 23.1 111008 177576 ??  S Mon10AM  626:59.32
/usr/local/bin/tor


> If it is this tor process, is tor still working as a relay despite the
> warnings?

I would have to say no. Using a program called pftop, I usually see Up
States of 1000+ when the relay is going strong, right now I see 13.
There is also no traffic on the server right now. However, I do show a
single established connection on the tor port 8080, but I'm pretty
sure its completely stagnant.

$ netstat -an -p tcp -f inet | grep ESTABLISHED
tcp  0  0  185.92.223.3.8080  188.166.41.46.42469ESTABLISHED
tcp  0  0  185.92.223.3.35786 176.10.104.243.443 ESTABLISHED
tcp  0  0  185.92.223.3.43470 80.127.107.179.443 ESTABLISHED
tcp  0 36  185.92.223.3.22204.112.151.27.51843   ESTABLISHED
tcp  0  0  185.92.223.3.9593  62.210.92.11.9001  ESTABLISHED
tcp  0  0  185.92.223.3.19380 185.30.166.37.6667 ESTABLISHED


I would be willing to try any patches you may have!

Thanks,

Tyler
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Bandwidth Accounting troubles

[Tyler Johnson]

On 3/24/17, teor <teor2...@gmail.com> wrote:
>
>> On 22 Mar 2017, at 07:46, Tyler Johnson <tylrcjh...@gmail.com> wrote:
>>
>> Hello!
>>
>> I've enabled bandwidth accounting on my tor relay, but encountering
>> issues when the relay attempts to wake from hibernation
>>
>> Mar 20 23:47:25 tcj Tor[74346]: Bandwidth soft limit reached;
>> commencing hibernation. No new connections will be accepted
>> Mar 20 23:52:30 tcj Tor[74346]: Heartbeat: Tor's uptime is 10 days
>> 12:00 hours, with 150 circuits open. I've sent 90.20 GB and received
>> 90.30 GB. We are currently hibernating.
>> Mar 20 23:52:30 tcj Tor[74346]: Circuit handshake stats since last
>> time: 2745/2745 TAP, 15557/15557 NTor.
>> Mar 20 23:52:30 tcj Tor[74346]: Since startup, we have initiated 0 v1
>> connections, 0 v2 connections, 0 v3 connections, and 113565 v4
>> connections; and received 1100 v1 connections,130 v2 connections, 41
>> v3 connections, and 249967 v4 connections.
>> Mar 21 00:00:00 tcj Tor[74346]: Configured hibernation.  This interval
>> began at 2017-03-21 00:00:00; the scheduled wake-up time was
>> 2017-03-21 00:00:00; we expect to exhaust our quota for this interval
>> around 2017-03-22 00:00:00; the next interval begins at 2017-03-22
>> 00:00:00 (all times local)
>> Mar 21 00:00:00 tcj Tor[74346]: Hibernation period ended. Resuming
>> normal activity.
>> Mar 21 00:00:00 tcj Tor[74346]: Opening OR listener on 185.92.223.3:8080
>> Mar 21 00:00:00 tcj Tor[74346]: Could not bind to 185.92.223.3:8080:
>> Address already in use. Is Tor already running?
>> Mar 21 00:01:00 tcj Tor[74346]: Opening OR listener on 185.92.223.3:8080
>> Mar 21 00:01:00 tcj Tor[74346]: Could not bind to 185.92.223.3:8080:
>> Address already in use. Is Tor already running?
>> Mar 21 00:02:01 tcj Tor[74346]: Opening OR listener on 185.92.223.3:8080
>> Mar 21 00:02:01 tcj Tor[74346]: Could not bind to 185.92.223.3:8080:
>> Address already in use. Is Tor already running?
>>
>> It will continue in this manner until I manually intervene and restart
>> the relay instance.
>
> This seems to be an internal state management issue.
> I have opened ticket #21810 to track it.
> https://trac.torproject.org/projects/tor/ticket/21810
>
> I would like to confirm tor's behaviour when this happens:
>
> Is there something listening on 185.92.223.3:8080?
> Is it this tor process, or another tor process?
> If it is this tor process, is tor still working as a relay despite the
> warnings?
>

I am attempting to re-create the issue. As far as I know, only the one
tor process is running, this being the one that was started through
the appropriate rc script during boot or using rcctl (In OpenBSD at
least) to start and stop the process.

The tor process does not continue to function as a relay. I am
monitoring connections using a program called pftop, which shows 1000+
connections when the tor relay is functioning, and < 50 when the tor
relay is in this blocking state.


>> snippet from torrc:
>>
>> ## Set a maximum of 30 gigabytes each way per period.
>> AccountingMax 30 GBytes
>>
>> ## Each period starts daily at midnight (AccountingMax is per day)
>> AccountingStart day 00:00
>>
>> ## Required: what port to advertise for incoming Tor connections.
>> ORPort 185.92.223.3:8080
>>
>> ## The IP address or full DNS name for incoming connections to your
>> ## relay. Leave commented out and Tor will guess.
>> Address 185.92.223.3
>>
>> ## If you have multiple network interfaces, you can specify one for
>> ## outgoing traffic to use.
>> OutboundBindAddress 185.92.223.3
>>
>>
>> Tor version and OS:
>> $ tor --version
>> Tor version 0.2.9.10 (git-1f6c8eda0073f464).
>> $ uname -a
>> OpenBSD tcj.me 6.1 GENERIC#224 amd64
>
> We sometimes have bugs on OpenBSD because it's one of our rarer
> platforms.
>
> Do you happen to know if SO_RERUSEADDR has unusual semantics on OpenBSD?
> (Or is it disabled entirely?)
>

There is a SO_REUSEADDR option for function getsockopt. a quick blurb
from the man page [1]:

"SO_REUSEADDR indicates that the rules used in validating addresses
supplied in a bind(2) call should allow reuse of local addresses by
callers with the same user ID (or the superuser)."

[1] http://man.openbsd.org/getsockopt

>> Has anyone else experienced this issue?
>
> This code has had similar issues in the past, particularly on rarer
> platforms.
>
>> I have only one outbound
>> interface, so is setting the OutboundBindAddress unnecessary and
>> possibly causing the problem?
>
> No, OutboundBind

Re: [tor-relays] Tor Relay On Pfsense 2.3.3-RELEASE-p1 (amd64)

[Tyler Johnson]

On 3/28/17, Edwin Garzón  wrote:
> Hi all.
> Need you help,
> I have pfsense *2.3.3-RELEASE-p1* (amd64) and > pkg install tor:
> pkg: No packages available to install matching 'tor' have been found in the
> repositories
>
> I want to install a Tor relay
>
> Thank
>

A quick googling shows me that perhaps Tor isn't supported on pfsense [1].

Therefore, you may have to follow this how-to: Running the Tor client
on Linux/BSD/Unix [2]

[1] https://forum.pfsense.org/index.php?topic=10143.0

[2] https://www.torproject.org/docs/tor-doc-unix.html.en
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Bandwidth Accounting troubles

[Tyler Johnson]

Hello!

I've enabled bandwidth accounting on my tor relay, but encountering
issues when the relay attempts to wake from hibernation

Mar 20 23:47:25 tcj Tor[74346]: Bandwidth soft limit reached;
commencing hibernation. No new connections will be accepted
Mar 20 23:52:30 tcj Tor[74346]: Heartbeat: Tor's uptime is 10 days
12:00 hours, with 150 circuits open. I've sent 90.20 GB and received
90.30 GB. We are currently hibernating.
Mar 20 23:52:30 tcj Tor[74346]: Circuit handshake stats since last
time: 2745/2745 TAP, 15557/15557 NTor.
Mar 20 23:52:30 tcj Tor[74346]: Since startup, we have initiated 0 v1
connections, 0 v2 connections, 0 v3 connections, and 113565 v4
connections; and received 1100 v1 connections,130 v2 connections, 41
v3 connections, and 249967 v4 connections.
Mar 21 00:00:00 tcj Tor[74346]: Configured hibernation.  This interval
began at 2017-03-21 00:00:00; the scheduled wake-up time was
2017-03-21 00:00:00; we expect to exhaust our quota for this interval
around 2017-03-22 00:00:00; the next interval begins at 2017-03-22
00:00:00 (all times local)
Mar 21 00:00:00 tcj Tor[74346]: Hibernation period ended. Resuming
normal activity.
Mar 21 00:00:00 tcj Tor[74346]: Opening OR listener on 185.92.223.3:8080
Mar 21 00:00:00 tcj Tor[74346]: Could not bind to 185.92.223.3:8080:
Address already in use. Is Tor already running?
Mar 21 00:01:00 tcj Tor[74346]: Opening OR listener on 185.92.223.3:8080
Mar 21 00:01:00 tcj Tor[74346]: Could not bind to 185.92.223.3:8080:
Address already in use. Is Tor already running?
Mar 21 00:02:01 tcj Tor[74346]: Opening OR listener on 185.92.223.3:8080
Mar 21 00:02:01 tcj Tor[74346]: Could not bind to 185.92.223.3:8080:
Address already in use. Is Tor already running?

It will continue in this manner until I manually intervene and restart
the relay instance.

snippet from torrc:

## Set a maximum of 30 gigabytes each way per period.
AccountingMax 30 GBytes

## Each period starts daily at midnight (AccountingMax is per day)
AccountingStart day 00:00

## Required: what port to advertise for incoming Tor connections.
ORPort 185.92.223.3:8080

## The IP address or full DNS name for incoming connections to your
## relay. Leave commented out and Tor will guess.
Address 185.92.223.3

## If you have multiple network interfaces, you can specify one for
## outgoing traffic to use.
OutboundBindAddress 185.92.223.3


Tor version and OS:
$ tor --version
Tor version 0.2.9.10 (git-1f6c8eda0073f464).
$ uname -a
OpenBSD tcj.me 6.1 GENERIC#224 amd64


Has anyone else experienced this issue? I have only one outbound
interface, so is setting the OutboundBindAddress unnecessary and
possibly causing the problem?

I do apologize if this has been discussed already. Please point me to
the relevant post if so!

Thanks in advance,

Tyler
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays