Re: [tor-relays] Comcast blocks ALL traffic with tor relays

[tor admin via tor-relays]

If we could get EFF to announce a boycott of any corporation known to 
act maliciously against Tor or other privacy-friendly technology (such 
as VPNs), that would go a long way.


I will also write to EFF.  I have donated money to them, so maybe they 
will listen.  If they won't support a boycott directly, maybe at least 
they will comment on the issue publicly, and that would help launch a 
boycott.


If will also help to get an official communication from Comcast saying 
they are blocking Tor.  If they won't admit this, it makes it that much 
harder to fight.  I can't do this as I'm not a Comcast customer.  Are 
there any Comcast customers that can get a Comcast rep to admit, in 
writing, that this is happening?







On 6/12/23 10:50, s7r wrote:

xmrk2 via tor-relays wrote:
Any ideas on how to combat this? I was thinking about including some 
false positives in tor relay list. Imagine including some Google 
servers' IP addresses - Comcast customers suddenly cannot connect to 
Google, unless Comcast stops this blocking... or simply whitelists 
Google. But those false positives sound ugly and a bit malicious, not 
sure it is a good idea.




This sucks big time, if true. I am trying to ping Comcast from a 
middle relay IP address and it seams, to work, I guess you mean 
AS33651 - Comcast Cable LLC. Anyway, it could be, at latest consensus 
there is no single relay (middle or exit) hosted in AS33651.


I am not sure about the false positive solution, I see only downsides, 
including but not limited to:


- it's not ethical for Tor Project to do this, e.g. stating another 
company's infrastructure (say Google IP address space) is part of a 
network when in fact its not. I get it that the goal is privacy 
oriented and in good faith (freedom faith) but it seams rather 
inappropriate;


- there is no evidence that a blocker might use a list of relays 
provided by Tor Project's metrics portal (I am confident nobody does 
it because it's less effective) - they can just run a Tor client and 
get a copy of a consensus and extract from there IP:PORT IPv6:PORT and 
do from there whatever they please;


- if you include such false positives in the consensus you have to 
simulate dummy Tor relays on those "hot" IP addresses, like providing 
an onion key, RSA identity and ed25519 identity, thus looking like a 
relay, state some bandwidth for it, etc - in this case how will a Tor 
client know which relay is dummy and which not, in order not to try to 
establish circuits that fail, ultimately producing a terrible user 
experience for all users. Same applies for other relays, not just 
clients, that need to produce connections with the dummy relays. If we 
somehow mark them as "dummy", it will be pretty stupid and obvious and 
waste of effort as the blocker can simply understand the "dummy" 
marker and it's done, I guess it's pretty obvious.


I already wrote about this publicly, and also wrote a mail to EFF. 
Hope I am not spamming, I feel this is quite important issue and am a 
bit frustrated by the lack of attention it gets.




Not at all, this is very interesting and not spamming at all. I think 
it is unacceptable for this to happen, and I think all Comcast 
customers should quit if this is true - large internet corporations 
are trying to move on from "IP address identifications" as in only a 
beginner that discovered the internet one week ago still thinks of the 
IP address as "identification of a certain individual / entity", 
everybody is moving to advanced layers of authentication on per device 
basis, cryptographic public key, etc. Comcast if they do such a thing 
they set themselves 25 years behind the industry they operate in. And 
this can create many unwanted effects, someone should try to do 
something about this but I am not sure what we Tor volunteers *can* do 
to help with this, especially the ones that are not Comcast customers. 
EFF is the best start IMO.



___
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] Debian is not allowing tor to update despite it being listed as a trusted respritory

[tor admin via tor-relays]

Your sources.list file entry looks incorrect.  I would definitely not 
recommend using trust=yes for a repo like tor, as it bypasses apt's 
security checks.


According to the instructions you linked 
, your source for the 
tor packages should be listed in /etc/apt/sources.list.d/tor.list as 
something like:


deb [signed-by=/usr/share/keyrings/tor-archive-keyring.gpg] 
https://deb.torproject.org/torproject.org buster main
deb-src [signed-by=/usr/share/keyrings/tor-archive-keyring.gpg] 
https://deb.torproject.org/torproject.org buster main


The instructions tell you how to import the repo key as well:



# wget -qO- 
https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc 
| gpg --dearmor | tee /usr/share/keyrings/tor-archive-keyring.gpg 
>/dev/null




On 5/3/22 13:10, Keifer Bly wrote:
I am not sure how to get rid of the trusty / ubuntu packages? I simply 
followed the instructions here:


https://support.torproject.org/apt/tor-deb-repo/

Thanks.
--Keifer


On Mon, May 2, 2022 at 10:31 PM Keifer Bly  wrote:

Hi all,

So I am running a tor relay on Debian, but no matter what when
updating tor there is an “updating from such a respiritpry can’t
be done securely and is therefore disabled by default”. Here is
the log

Get:1 http://security.debian.org buster/updates InRelease [65.4 kB]

Hit:2 http://deb.debian.org/debian buster InRelease

Get:3 http://deb.debian.org/debian buster-updates InRelease [51.9 kB]

Get:4 http://deb.debian.org/debian buster-backports InRelease
[46.7 kB]

Ign:5 http://ftp.de.debian.org/debian stretch InRelease

Hit:6 http://ftpde.debian.org/debian stretch Release

Ign:7 http://deb.torproject.org/torproject.org trusty InRelease

Ign:8 http://deb.torproject.org/torproject.org trusty Release

Ign:9 http://deb.torproject.org/torproject.org trusty/main Sources

Ign:10 http://deb.torproject.org/torproject.org trusty/main all
Packages

Ign:11 http://deb.torproject.org/torproject.org trusty/main amd64
Packages

Ign:12 http://deb.torproject.org/torproject.org trusty/main
Translation-en

Ign:13 http://deb.torproject.org/torproject.org trusty/main
Translation-en_US

Ign:9 http://deb.torproject.org/torproject.org trusty/main Sources

Ign:10 http://deb.torproject.org/torproject.org trusty/main all
Packages

Ign:11 http://deb.torproject.org/torproject.org trusty/main amd64
Packages

Ign:12 http://deb.torproject.org/torproject.org trusty/main
Translation-en

Ign:13 http://deb.torproject.org/torproject.org trusty/main
Translation-en_US

Ign:14 https://deb.torproject.org/torproject.org amd64 InRelease

Ign:9 http://deb.torproject.org/torproject.org trusty/main Sources

Ign:10 http://deb.torproject.org/torproject.org trusty/main all
Packages

Ign:11 http://deb.torproject.org/torproject.org trusty/main amd64
Packages

Ign:12 http://deb.torproject.org/torproject.org trusty/main
Translation-en

Ign:13 http://deb.torproject.org/torproject.org trusty/main
Translation-en_US

Err:15 https://deb.torproject.org/torproject.org amd64 Release

  Certificate verification failed: The certificate is NOT trusted.
The certificate chain uses expired certificate.  Could not
handshake: Error in the certificate verification. [IP:
95.216.163.36 443]

Ign:9 http://deb.torproject.org/torproject.org trusty/main Sources

Ign:10 http://deb.torproject.org/torproject.org trusty/main all
Packages

Ign:11 http://deb.torproject.org/torproject.org trusty/main amd64
Packages

Ign:12 http://deb.torproject.org/torproject.org trusty/main
Translation-en

Ign:13 http://deb.torproject.org/torproject.org trusty/main
Translation-en_US

Ign:9 http://deb.torproject.org/torproject.org trusty/main Sources

Ign:10 http://deb.torproject.org/torproject.org trusty/main all
Packages

Ign:11 http://deb.torproject.org/torproject.org trusty/main amd64
Packages

Ign:12 http://deb.torproject.org/torproject.org trusty/main
Translation-en

Ign:13 http://deb.torproject.org/torproject.org trusty/main
Translation-en_US

Ign:9 http://deb.torproject.org/torproject.org trusty/main Sources

Ign:10 http://deb.torproject.org/torproject.org trusty/main all
Packages

Ign:11 http://deb.torproject.org/torproject.org trusty/main amd64
Packages

Ign:12 http://deb.torproject.org/torproject.org trusty/main
Translation-en

Ign:13 http://deb.torproject.org/torproject.org trusty/main
Translation-en_US

Err:9 http://deb.torproject.org/torproject.org trusty/main Sources

  404  Not Found [IP: 116.202.120.166 80]

Ign:10 http://deb.torproject.org/torproject.org trusty/main all
Packages

Ign:11 http://deb.torproject.org/torproject.org trusty/main amd64
Packages

Ign:12 

Re: [tor-relays] Newbie needs help

[tor admin via tor-relays]

Tor project recommends 16Mbits/s in each direction minimum 
 so you 
should be fine.


However note the concurrent connections requirement, which can 
"overwhelm consumer-level routers."   That might be something to watch.



On 3/22/22 09:11, tdu...@palmettoshopper.com wrote:

I think I figured it out. Seems DirPort was commented out.

I am getting a warning that my contact info isn't set. I uncommented that
section and put a name and email address. Also uncommented the Nickname.
Still getting the warning.

Just curious, what are the bandwidth requirements to be a bridge? I'm on a
'consumer router' and have around 400 Mbs u/l and 200 Mbs d/l

TIA

-Original Message-
From: tor-relays  On Behalf Of
tdu...@palmettoshopper.com
Sent: Monday, March 21, 2022 5:55 PM
To:tor-relays@lists.torproject.org
Subject: [tor-relays] Newbie needs help

Hi,

Thanks for adding me to the list.

I setup a Tor Relay in Docker using this image:
https://hub.docker.com/r/doudou34/tor-server

Its running, so how can I test it? When I try to access it using port 9001,
I'm unable to connect. I have opened the port on my firewall to the public.
Haven't done it on my router yet but I have Portainer running in Docker and
have no problem accessing it.

Not a lot of instructions that I can find. I can post the torrc file but
it's the same as the one on the docker page.

### /etc/torrc ###
# see /etc/torrc/torrc.default and
https://www.torproject.org/docs/tor-manual.html.en

# Server's public IP Address (usually automatic) #Address 10.10.10.10

# Port to advertise for incoming Tor connections.
# common ports are 9001, 443
ORPort 9001

# Mirror directory information for others (optional) # common ports are
9030, 80 #DirPort 9030

# Run as a relay only (not as an exit node)
ExitPolicy reject *:* # no exits allowed

# Set limits
#RelayBandwidthRate 1024 KB   # Throttle traffic to
#RelayBandwidthBurst 2048 KB  # But allow bursts up to
#MaxMemInQueues 512 MB# Limit Memory usage to

# Run Tor as obfuscated bridge
#ServerTransportPlugin obfs3 exec /usr/bin/obfsproxy managed
#ServerTransportListenAddr obfs3  0.0.0.0:5 #BridgeRelay 1

# Run Tor only as a server (no local applications) SocksPort 0

# Run Tor as a regular user (do not change this) User debian-tor
DataDirectory /var/lib/tor

# If no Nickname or ContactInfo is set, docker-entrypoint will use # the
environment variables to add Nickname/ContactInfo here
#Nickname Tor4 # only use letters and numbers
#contactinfoem...@example.org

I've only been using docker for a few days, so maybe its an issue there.

TIA

___
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] Crashed Relay

[Bleedangel Tor Admin]

   If you upgraded tor as a package on your Linux OS recently, it may have overwritten your torrc with defaults? It’s a long shot!Sent from ProtonMail for iOS On Sat, Nov 6, 2021 at 12:52, sysmanager7 via tor-relays  wrote:  I was notified by Uptime Robot that relay 1 of 3 had been shut down. Unfortunately I found this out 12 hours after the fact.guard flag is lost.journalctl -u tor@defaultNov 01 01:03:18 ubuntu-s-1vcpu-2gb-nyc1-01 Tor[328387]: I learned some more directory information, but not enough to build a circuit: We need more microdescrors: we have 6178/6618, and can only build 49% of likely paths. (We have 99% of guards bw, 50% of midpoint bw, and 98% of exit bw = 49% of path bw.) ptors: we have 6178/6618, and can only build 49% of likely paths. (We have 99% of guards bw, 50% of midpoint bw, and 98% of exit bw = 49% of path bw.)ived 4371.61 GB. I've received 7345604 connections on IPv4 and 0 on IPv6. I've made 677780 connections with IPv4 and 0 with IPv6.Nov 01 06:47:26 ubuntu-s-1vcpu-2gb-nyc1-01 Tor[328387]: Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt aga>Nov 01 06:47:26 ubuntu-s-1vcpu-2gb-nyc1-01 Tor[328387]: Delaying directory fetches: We are hibernating or shutting down.Nov 01 06:47:56 ubuntu-s-1vcpu-2gb-nyc1-01 Tor[328387]: Clean shutdown finished. Exiting.Nov 01 06:48:04 ubuntu-s-1vcpu-2gb-nyc1-01 systemd[1]: tor@default.service: Succeeded.Nov 01 06:48:04 ubuntu-s-1vcpu-2gb-nyc1-01 systemd[1]: Stopped Anonymizing overlay network for TCP.This is NOT a first time for the above on this relay, more like a 7th or 8th.CPU usage according to NYX is 90/95%. That has been the last three weeks or so.Prior to that, average CPU usage was 30% or less.Current BW/Burst is 3/4 MBs on torrc and nyx. Prior was BW/Burst 4/5*Me - retired fixed income. Average billing for 3 Digital Ocean Droplets was $40. budget is good with that. Octobers billing - $87.50 I used 10 gb instead of 6Gb. Essentially a $40 overage. It's almost as if, torrc and nyx are being ignored.Sent with ProtonMail Secure Email.




publicKey - tor@bleedangel.com - a010c89f.asc
Description: application/pgp-keys


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] Overloaded state indicator on relay-search

[Bleedangel Tor Admin]

   The problem is that it’s *not* currently overloaded, there’s nothing to see. Maybe you can check your syslogs for anything out of the ordinary system-wide? Sent from ProtonMail for iOS On Thu, Oct 14, 2021 at 10:09, Arlen Yaroslav via tor-relays  wrote:  > I am not sure where you are looking but if you take a look at what>> Onionoo[1] is saying you get>> overload_general_timestamp 163418040>> which means 10/14/2021 03:00:00 UTC, thus today.>> Georg>> [1] https://onionoo.torproject.org/details?limit=4=VinculumGateThanks, I was looking at the cached-descriptors file which I can see now is well out of date.Would anyone have any other suggestions regarding why the relay is overloaded?___tor-relays mailing listtor-relays@lists.torproject.orghttps://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays




publicKey - tor@bleedangel.com - a010c89f.asc
Description: application/pgp-keys


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] Overloaded state indicator on relay-search

[Bleedangel Tor Admin]

   Did you use a lot of ram or cpu power recently? I got flagged as overloaded when I was compiling something and used a lot of cpu.Again, the problem here is that even if you fix it, you won’t know for 3 days. Therefore if you try multiple methods to fix it you won’t know what the problem is.I wholeheartedly believe in more status indicators on the search page:Green - goodRed - offlineYellow - overloaded**Blue - was overloaded within 72 hours ago but currently is not**Sent from ProtonMail for iOS On Thu, Oct 14, 2021 at 09:25, Arlen Yaroslav via tor-relays  wrote:  Hi all,My relay (77D08850C1EE8587451F838D3F49874F75B0B1AC) is showing as overloaded on the Relay Search page:https://metrics.torproject.org/rs.html#details/77D08850C1EE8587451F838D3F49874F75B0B1ACI have enabled MetricsPort and MetricsPortPolicy in the torrc configuration file. I have retrieved the metrics into a file and inspected it but it is still not clear to me what the problem is. The only non-zero values I can see are reason="success" or action="". Nothing sticks out in the process logs either.Can anyone assist?Regards,Arlen___tor-relays mailing listtor-relays@lists.torproject.orghttps://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays




publicKey - tor@bleedangel.com - a010c89f.asc
Description: application/pgp-keys


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] Bridge showing offline

[Bleedangel Tor Admin]

   You are running 0.4.5.8, maybe updating to a newer version of tor will help?Sent from ProtonMail for iOS On Thu, Oct 14, 2021 at 03:02, Georg Koppen  wrote:  Eddie:> Looking at tor metrics, one of my bridges is showing as off-line:> B080140DC1BAB5B86D1CE5A4CA2EF64F20282440>> However, the log isn't showing any issues:>> Oct 14 00:00:28.000 [notice] Tor 0.4.5.8 opening new log file.> Oct 14 00:00:28.000 [notice] Configured hibernation.  This interval> began at 2021-10-14 00:00:00; the scheduled wake-up time was 2021-10-14> 00:00:00; we expect to exhaust our quota for this interval around> 2021-10-15 00:00:00; the next interval begins at 2021-10-15 00:00:00> (all times local)> Oct 14 01:49:40.000 [notice] Heartbeat: Tor's uptime is 124 days 6:00> hours, with 0 circuits open. I've sent 907.23 GB and received 922.28 GB.> I've received 63052 connections on IPv4 and 8375 on IPv6. I've made> 512684 connections with IPv4 and 100974 with IPv6.> Oct 14 01:49:40.000 [notice] While not bootstrapping, fetched this many> bytes: 1801791624 (server descriptor fetch); 175792 (server descriptor> upload); 221750347 (consensus network-status fetch); 10974 (authority> cert fetch); 19905655 (microdescriptor fetch)> Oct 14 01:49:40.000 [notice] Heartbeat: Accounting enabled. Sent: 140.52> MB, Received: 140.69 MB, Used: 281.21 MB / 200.00 GB, Rule: sum. The> current accounting interval ends on 2021-10-15 00:00:00, in 22:10 hours.> Oct 14 01:49:40.000 [notice] Heartbeat: In the last 6 hours, I have seen> 14 unique clients.>> Initially I thought of a previous issue I had with IPv6 connectivity,> but don't think this is the problem here as the 2nd bridge on the same> server is showing on-line.  Also an IPv6 port scan shows the ports for> both bridges as accessible.>> Ideas ??I wonder whether that is another instancehttps://gitlab.torproject.org/tpo/core/tor/-/issues/40424. Hard to tell,though. Does that issue happen regularly?Georg___tor-relays mailing listtor-relays@lists.torproject.orghttps://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays




publicKey - tor@bleedangel.com - a010c89f.asc
Description: application/pgp-keys


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] Overloaded state indicator on relay-search

[Bleedangel Tor Admin]

   Can you link to where I can edit the torproject.org documentation? I cannot find this feature.Thanks Sent from ProtonMail for iOS On Thu, Oct 7, 2021 at 06:48,   wrote:  On Wednesday, October 6, 2021 8:55:01 PM CEST potlatch via tor-relays wrote:> Tor has always been very lax at documentation--both creation and updating.> I've never seen a  thorough site map or directory published.  I think this> discourages folks who would like to start a tor relay.Mmm. I'm a stupid hobby admin with no IT background. Tor entry servers werethe first thing I set up on rented servers in the data center. TheTorRelayGuide on Torproject.org was easy for me.https://community.torproject.org/relay/Debian's sample torrc has always been well documented.And micahflee's tor-relay-bootstrap script is forked a dozen times. A relay canbe set up in just a few minutes.The biggest problem is to find a provider where you can rent cheap unmeteredservers and who allow exit's to operate. In addition, the provider shouldideally be far away from DE-CIX Frankfurt and no or few other Tor serversthere.And don't forget the Tor Project is a Community Project. Everyone can edit theTorproject.org Doku. ;-)I can always recommend these pages to beginners:https://tor-relay.co/https://www.torservers.net/wiki/guides--╰_╯ Ciao Marco!Debian GNU/LinuxIt's free software and it gives you freedom!___tor-relays mailing listtor-relays@lists.torproject.orghttps://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays




publicKey - tor@bleedangel.com - a010c89f.asc
Description: application/pgp-keys


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] Overloaded state indicator on relay-search

[Bleedangel Tor Admin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

This is much more informational. Great job!

As someone with mystery "overloaded" problems, i'd recommend / request / beg 
for the following:

1) When the relay is overloaded, a yellow indicator appears on the web page. 
This indicator remains for 72 hours after the overloaded state is remedied.
- This is not helpful in diagnosing anything, because even if the problem is 
solved, it is not evident that the relay is no longer overloaded for 72 hours.
-- once the relay is no longer overloaded, it should have a purple (or any 
other color) "recovery" indicator for 72 hours. At least the relay operator 
would know that the overloaded state has been repaired.

2) metricsport
- This is such an enigma to someone who is not familiar with prometheus, or 
torrc beyond the basics. As a matter of fact, when installing the tor-git 
package on Arch Linux, the man pages dont install automatically, so 'man torrc' 
gives a very helpful:

$ man torrc
No manual entry for torrc

The official tor website, under manuals section, -alpha: 
https://2019.www.torproject.org/docs/tor-manual-dev.html.en
does not include the documentation for metricsport.

i think the troubleshooting guide should contain directions to enable 
metricsport, and how to view the results:

...

To enable metricsport for advanced diagnosis:

In torrc set MetricsPort and MetricsPortPolicy flags as follows:

MetricsPort :
MetricsPortPolicy accept 

it is good policy to only allow connections to the metricsport port from 
localhost as follows:

MetricsPort 127.0.0.1:9035   #This will open the metricsport server 
on port 9035, listening on localhost (127.0.0.1).
MetricsPortPolicy accept 127.0.0.1   #This will allow only localhost 
(127.0.0.0) to query the metricsport server.

Once these are set and the configuration reloaded (via SIGHUP or tor restart), 
the data can be queried as follows:

wget http://127.0.0.1:9035/metrics -O metricsport.txt

This will place a file in the current directory called 'metricsport.txt' that 
can be used to troubleshoot the overloaded relay issues via the information in 
this document

...



‐‐‐ Original Message ‐‐‐

On Tuesday, October 5th, 2021 at 4:33 PM, Silvia/Hiro  
wrote:

> On 10/4/21 1:36 PM, David Goulet wrote:
>
> > On 02 Oct (01:29:56), torix via tor-relays wrote:
> >
> > > My relays (Aramis) marked overloaded don't make any sense either. Two of
> > >
> > > the ones marked with orange are the two with the lowest traffic I have 
> > > (2-5
> > >
> > > MiB/s and 4-9 MiB/s - not pushing any limits here); the third one with 
> > > that
> > >
> > > host has more traffic and is fine.
> > >
> > > So far this indicator seems to be no help to me.
> >
> > Keep in mind that the overload state might not be only about traffic 
> > capacity.
> >
> > Like this page states, there other factors including CPU and memory 
> > pressure.
> >
> > https://support.torproject.org/relay-operators/relay-bridge-overloaded/
> >
> > We are in a continuous process of making it better with feedback from the
> >
> > relay community. It is a hard problem because so many things can change or
> >
> > influence things. And different OSes also makes it challenging.
> >
> > Another thing here to remember, the overload state will be set for 72 hours
> >
> > even if a SINGLE overload event occurred.
> >
> > For more details:
> >
> > https://lists.torproject.org/pipermail/tor-relays/2021-September/019844.html
> >
> > (FYI, we are in the process of adding this information in the support page 
> > ^).
>
> We have now updated the support article at:
>
> https://support.torproject.org/relay-operators/relay-bridge-overloaded/
>
> We have tried to clarify how and why the overloaded state is triggered.
>
> I hope this can help operators understand better why their relays can be
>
> found in this state and how a normal state can be recovered.
>
> Please do let us know what you think.
>
> Cheers,
>
> -hiro
>
> > If you can't find sticking out, that is OK, you can move on and see if it
> >
> > continues to stick. If so, maybe its worth digging more and when 0.4.7 will 
> > be
> >
> > stable, you'll be able to enable the MetricsPort (man tor) to get into the
> >
> > rabbit hole a bit deeper.
> >
> > Cheers!
> >
> > David
> >
> > 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
-BEGIN PGP SIGNATURE-
Version: ProtonMail

wnUEARYKAAYFAmFcv8UAIQkQ07hp34FMyg4WIQSgEMifmnN5ohFWvfnTuGnf
gUzKDudLAP9iwogPbk+q1zBA+90BmT0dSnvq4vR0o8Jpr1H7NmWHQQEAizx8
9zAgec3xOKEM+f4cqgcGDwKUK3OT2P8sFrW0xwE=
=Dp/H
-END PGP SIGNATURE-


publickey - tor@bleedangel.com - 0xA010C89F.asc
Description: application/pgp-keys


publickey - tor@bleedangel.com - 0xA010C89F.asc.sig
Description: PGP signature

Re: [tor-relays] Overloaded state indicator on relay-search

[Bleedangel Tor Admin]

   Agreed . My relay is wellBelow all of the thresholds for “overloaded”, for gods sake 64gb ram and 12 cpus should be adequate for a tor relay? 10gb connection?I’ve asked multiple times for help trying to figure this out and have gotten zero response. It seems to be very difficult to get any help with running relays. I’d think the tor community would want exit relays running, and would be more forthcoming with information, but the docs and help sections are almost useless.The troubleshooting page for an overloaded relay mentions running metricsport, but with no instructions or even links to anywhere to explain how to do this.The relay search/status website shows 2 extra links below some relays but not others, I get no extra info on mine.My relay has a dirport of 9030 in my config and nyx confirms this. The relay status website says I have no dirport configured.There are so many little issues at play, you’d think this would be simpler to have everything running.Sent from ProtonMail for iOS On Fri, Oct 1, 2021 at 21:29, torix via tor-relays  wrote:  My relays (Aramis) marked overloaded don't make any sense either.  Two of the ones marked with orange are the two with the lowest traffic I have (2-5 MiB/s and 4-9 MiB/s - not pushing any limits here); the third one with that  host has more traffic and is fine.So far this indicator seems to be no help to me.--TorixSent with ProtonMail Secure Email.‐‐‐ Original Message ‐‐‐On Friday, October 1st, 2021 at 12:22 PM, David Goulet  wrote:> On 01 Oct (03:08:20), Andreas Kempe wrote:>> > Hello David!> >> > On Mon, Sep 27, 2021 at 08:22:08AM -0400, David Goulet wrote:> >> > > On 24 Sep (12:36:17), li...@for-privacy.net wrote:> > >> > > > On Thursday, September 23, 2021 3:39:08 PM CEST Silvia/Hiro wrote:> > > >> > > > > When a relay is in the overloaded state we show an amber dot next to the> > > > >> > > > > relay nickname.> > > > >> > > > > Nice thing. This flag has noticed me a few days ago.> > > >> > > > > If you noticed your relay is overloaded, please check the following> > > > >> > > > > support article to find out how you can recover to a "normal" state:> > > > >> > > > > https://support.torproject.org/relay-operators/relay-bridge-overloaded/> > > > >> > > >> > > > A question about Enabling Metricsport. Is definitely Prometheus necessary?> > > >> > > > Or can the Metrics Port write into a LogFile / TextFile?> > >> > > The output format is Prometheus but you don't need a prometheus server to get> > >> > > it.> > >> > > Once opened, you can simply fetch it like this:> > >> > > wget http://:/metrics -O /tmp/output.txt> > >> > > or> > >> > > curl http://:/metrics -o /tmp/output.txt> >> > I've only ever gotten an empty reply when trying to extract metrics> >> > and I still do on Tor 4.6.7. I have some vague memory of the metrics> >> > previously only being for hidden services.> >> > All the metrics mentioned in the overload guide[1] seem to be missing.> >> > Having a quick look at the Git repository, it seems that only> >> > 0.4.71-alpha and latest master contain the necessary changes for these> >> > metrics.> >> > Is my assumption correct or am I doing something wrong?>> Correct, relay metrics are only available on >= 0.4.7.1-alpha. Hopefully, we>> should have an 0.4.7 stable by end of year (or around that time).>> David>> ->> xX/GscsnOTkKMqPla5JDOc2EqZ3GG/imhQ7gx+DQhVE=>> tor-relays mailing list>> tor-relays@lists.torproject.org>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays___tor-relays mailing listtor-relays@lists.torproject.orghttps://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays




publicKey - tor@bleedangel.com - a010c89f.asc
Description: application/pgp-keys


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] Overloaded state indicator on relay-search

[Bleedangel Tor Admin]

   But I’m WELL below the 3/4 rule ..MemTotal:   65777296 kBMemFree:    63088388 kBI actually have 95.9121031670259% FREE which means I’m only using around 4% of my ram!Am I understanding the 3/4 wrong? Thanks againSent from ProtonMail for iOS On Tue, Sep 28, 2021 at 21:50, Gary C. New <garyc...@yahoo.com> wrote:  
Bleedangel,You definitely have a nice rig with 12 CPUs and 64GB of RAM. I have a bunch of 2 CPU and 256MB rigs that I loadbalance as a single relay.Following David's explanation as to how the overloaded state is metered, I believe your issue is with RAM availability being over the 3/4 rule.MemTotal:   65777296 kBMemFree:    63088388 kBYou might try freeing up RAM resources (below the 3/4 limit) and confirm whether that resolves the issue, after 72 hours.Personally, I think a better approach would be to have the upstream relay monitor and report overloaded states, but I only know so much about Tor.Hope this helps.Respectfully,Gary





On Tuesday, September 28, 2021, 10:28:42 AM PDT, Bleedangel Tor Admin  wrote:



-BEGIN PGP SIGNED MESSAGE-Hash: SHA512I am having a lot of trouble figuring out why my relay keeps showing as overloaded on the search page. I believe I have more than enough memory and cpu power to not be overloaded on hardware. My server internet connection is 10GB up/down unmetered.I cannot for the life of me figure out why the relay search page continuously tells me i am overloaded. Can someone assist me in troubleshooting this?Thank you. Pertinent hardware information is pasted below:output of /proc/meminfo:--[ BEGIN PASTE ]--MemTotal:   65777296 kBMemFree:    63088388 kBMemAvailable:   63415088 kBBuffers:  180096 kBCached:   736396 kBSwapCached:    0 kBActive:   449428 kBInactive:    1729304 kBActive(anon):  14552 kBInactive(anon):  1292048 kBActive(file): 434876 kBInactive(file):   437256 kBUnevictable:   0 kBMlocked:   0 kBSwapTotal:  33520636 kBSwapFree:   33520636 kBDirty:   236 kBWriteback: 0 kBAnonPages:   1262300 kBMapped:   273164 kBShmem: 48592 kBKReclaimable:  94828 kBSlab: 204624 kBSReclaimable:  94828 kBSUnreclaim:   109796 kBKernelStack:    5040 kBPageTables: 9308 kBNFS_Unstable:  0 kBBounce:    0 kBWritebackTmp:  0 kBCommitLimit:    66409284 kBCommitted_AS:    2374432 kBVmallocTotal:   34359738367 kBVmallocUsed:   34348 kBVmallocChunk:  0 kBPercpu:    16384 kBHardwareCorrupted: 0 kBAnonHugePages: 0 kBShmemHugePages:    0 kBShmemPmdMapped:    0 kBFileHugePages: 0 kBFilePmdMapped: 0 kBCmaTotal:  0 kBCmaFree:   0 kBHugePages_Total:   0HugePages_Free:    0HugePages_Rsvd:    0HugePages_Surp:    0Hugepagesize:   2048 kBHugetlb:   0 kBDirectMap4k:  332988 kBDirectMap2M: 7981056 kBDirectMap1G:    58720256 kB--[ END PASTE ]--output of /proc/cpuinfo:--[ BEGIN PASTE ]--processor   : 0vendor_id   : AuthenticAMDcpu family  : 23model   : 113model name  : AMD Ryzen 5 3600 6-Core Processorstepping    : 0microcode   : 0x8701021cpu MHz : 2200.000cache size  : 512 KBphysical id : 0siblings    : 12core id : 0cpu cores   : 6apicid  : 0initial apicid  : 0fpu : yesfpu_exception   : yescpuid level : 16wp  : yesflags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf rapl pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb cat_l3 cdp_l3 hw_pstate ssbd mba ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 cqm rdt_a rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local clzero irperf xsaveerptr rdpru wbnoinvd arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif v_spec_ctrl umip rdpid overflow_recov succor smca sme sev sev_esbugs    : sysret_ss_attrs spectre_v1 spectre_v2 spec_store_bypassbogomips    : 7202.22TLB size    : 3072 4K pagesclflush size    : 64cache_alignment : 64address sizes   : 43 bits physical, 48 bits virtualpower management: ts ttp tm hwpstate cpb eff_freq_ro [13] [14]processor   : 1vendor_id   : AuthenticAMDcpu family  : 23model   : 113model name  : AMD Ryzen 5 3600 

Re: [tor-relays] Overloaded state indicator on relay-search

[Bleedangel Tor Admin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I am having a lot of trouble figuring out why my relay keeps showing as 
overloaded on the search page. I believe I have more than enough memory and cpu 
power to not be overloaded on hardware. My server internet connection is 10GB 
up/down unmetered.

I cannot for the life of me figure out why the relay search page continuously 
tells me i am overloaded. 
Can someone assist me in troubleshooting this?

Thank you. Pertinent hardware information is pasted below:

output of /proc/meminfo:

--[ BEGIN PASTE ]--

MemTotal:   65777296 kB
MemFree:    63088388 kB
MemAvailable:   63415088 kB
Buffers:  180096 kB
Cached:   736396 kB
SwapCached:    0 kB
Active:   449428 kB
Inactive:    1729304 kB
Active(anon):  14552 kB
Inactive(anon):  1292048 kB
Active(file): 434876 kB
Inactive(file):   437256 kB
Unevictable:   0 kB
Mlocked:   0 kB
SwapTotal:  33520636 kB
SwapFree:   33520636 kB
Dirty:   236 kB
Writeback: 0 kB
AnonPages:   1262300 kB
Mapped:   273164 kB
Shmem: 48592 kB
KReclaimable:  94828 kB
Slab: 204624 kB
SReclaimable:  94828 kB
SUnreclaim:   109796 kB
KernelStack:    5040 kB
PageTables: 9308 kB
NFS_Unstable:  0 kB
Bounce:    0 kB
WritebackTmp:  0 kB
CommitLimit:    66409284 kB
Committed_AS:    2374432 kB
VmallocTotal:   34359738367 kB
VmallocUsed:   34348 kB
VmallocChunk:  0 kB
Percpu:    16384 kB
HardwareCorrupted: 0 kB
AnonHugePages: 0 kB
ShmemHugePages:    0 kB
ShmemPmdMapped:    0 kB
FileHugePages: 0 kB
FilePmdMapped: 0 kB
CmaTotal:  0 kB
CmaFree:   0 kB
HugePages_Total:   0
HugePages_Free:    0
HugePages_Rsvd:    0
HugePages_Surp:    0
Hugepagesize:   2048 kB
Hugetlb:   0 kB
DirectMap4k:  332988 kB
DirectMap2M: 7981056 kB
DirectMap1G:    58720256 kB
--[ END PASTE ]--

output of /proc/cpuinfo:

--[ BEGIN PASTE ]--
processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 23
model   : 113
model name  : AMD Ryzen 5 3600 6-Core Processor
stepping    : 0
microcode   : 0x8701021
cpu MHz : 2200.000
cache size  : 512 KB
physical id : 0
siblings    : 12
core id : 0
cpu cores   : 6
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 16
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb 
rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf 
rapl pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave 
avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 
3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext 
perfctr_llc mwaitx cpb cat_l3 cdp_l3 hw_pstate ssbd mba ibpb stibp vmmcall 
fsgsbase bmi1 avx2 smep bmi2 cqm rdt_a rdseed adx smap clflushopt clwb sha_ni 
xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total 
cqm_mbm_local clzero irperf xsaveerptr rdpru wbnoinvd arat npt lbrv svm_lock 
nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter 
pfthreshold avic v_vmsave_vmload vgif v_spec_ctrl umip rdpid overflow_recov 
succor smca sme sev sev_es
bugs    : sysret_ss_attrs spectre_v1 spectre_v2 spec_store_bypass
bogomips    : 7202.22
TLB size    : 3072 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 43 bits physical, 48 bits virtual
power management: ts ttp tm hwpstate cpb eff_freq_ro [13] [14]

processor   : 1
vendor_id   : AuthenticAMD
cpu family  : 23
model   : 113
model name  : AMD Ryzen 5 3600 6-Core Processor
stepping    : 0
microcode   : 0x8701021
cpu MHz : 2200.000
cache size  : 512 KB
physical id : 0
siblings    : 12
core id : 1
cpu cores   : 6
apicid  : 2
initial apicid  : 2
fpu : yes
fpu_exception   : yes
cpuid level : 16
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb 
rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf 
rapl pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave 
avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 
3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext 
perfctr_llc mwaitx cpb cat_l3 cdp_l3 hw_pstate ssbd mba ibpb stibp vmmcall 
fsgsbase bmi1 avx2 smep bmi2 cqm rdt_a rdseed adx smap clflushopt clwb sha_ni 
xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total 
cqm_mbm_local clzero irperf xsaveerptr rdpru wbnoinvd 

Re: [tor-relays] Overloaded state indicator on relay-search

[Bleedangel Tor Admin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Agreed, can the thresholds be published publicly for easy reference? Sometimes 
i get the overloaded flag but i have nothing in my logs, and my cpu/memory is 
abundant. 
It would be much easier to ascertain the cause of this if we knew what we were 
looking for!

Thank you

‐‐‐ Original Message ‐‐‐
On Monday, September 27th, 2021 at 10:23 AM, Gary C. New via tor-relays 
 wrote:

> George,
>
> The referenced support article provides recommendations as to what might be 
> causing the overloaded state, but it doesn't provide the metric(s) for how 
> Tor decides whether a relay is overloaded. I'm trying to ascertain the later.
>
> I would assume the overloaded state metric(S) is/are a maximum timeout value 
> and/or reoccurrence value, etc.
>
> By knowing what the overloaded state metric is, I can tune my Tor relay just 
> short of it.
>
> Thank you for your reply.
>
> Respectfully,
>
> Gary
>
> On Monday, September 27, 2021, 2:44:35 AM PDT, Georg Koppen 
>  wrote:
>
> Gary C. New via tor-relays:
>
> >  Hiro,
>
> > Presently, I'm seeing a similar issue. On my laptop, I'm observing an 
> > overloaded status for my relay. However, the same relay shows a green 
> > status on my phone.
>
> > Do you do any user-agent detection?
>
> > I'm still interested in those magic numbers, which determine whether a 
> > relay has reached an overloaded state.
>
> Which numbers do you mean? Is there anything missing from the support
>
> article[1] you feel should be there?
>
> Georg
>
> [1] https://support.torproject.org/relay-operators/relay-bridge-overloaded/
>
> > Thank You.
>
> > Respectfully,
>
> >
>
> > Gary
>
> >
>
> >    On Saturday, September 25, 2021, 7:11:31 AM PDT, Silvia/Hiro 
> > wrote: 
>
> > 
>
> >  Hi,
>
> > I went back in history and tried to find out whenever your node
>
> > FriendlyExit1 was overloaded. I couldn't find the exact descriptor.
>
> >
>
> > One thing I can think of is that on the 22nd when I deployed this I
>
> > noticed a few typos in the code and had to make a second release. Maybe
>
> > something was cached for a while and you what you were accessing from
>
> > mobile was the buggy page.
>
> >
>
> > If it happens again there are two buttons at the end of the page where
>
> > you can see the latest server and extra-info descriptors. If you
>
> > download the server one you would be able to verify that there is a
>
> > "overload-general" field in there. If there isn't we have a bug :).
>
> >
>
> > Please let me know if this happens again.
>
> >
>
> > Cheers,
>
> > -hiro
>
> >
>
> > On 9/24/21 2:39 PM, friendlyexitnode via tor-relays wrote:
>
> >> Hey hiro, thanks!
>
> >>
>
> >> I've also attached some screenshots too if it helps (sorry, I should have 
> >> done that before). I had first noticed this around 3:45 PM CST on 
> >> September 23.
>
> >>
>
> >> - The Friendly Exit Node Family
>
> >>
>
> >> Sent with ProtonMail Secure Email.
>
> >>
>
> >> ‐‐‐ Original Message ‐‐‐
>
> >>
>
> >> On Friday, September 24th, 2021 at 4:47 AM, Silvia/Hiro 
> >>  wrote:
>
> >>
>
> >>> On 9/23/21 10:54 PM, friendlyexitnode via tor-relays wrote:
>
> >>>
>
>  This looks like an awesome feature! I super appreciate it.
>
> 
>
>  Random question though (and I'm the first to admit I may be doing 
>  something wrong), I notice that on Mobile it says my relays are 
>  overloaded however when I view it on a normal computer I don't get the 
>  overloaded indicator. I've tried refreshing multiple times but getting 
>  the same results. Is anyone seeing the same thing?
>
> >>>
>
> >>> Hi,
>
> >>>
>
> >>> could you let me know when you accessed the page via mobile approximately?
>
> >>>
>
> >>> I'll try to check if any of your relays were overloaded in the past.
>
> >>>
>
> >>> When a node is overloaded the state is kept for 72 hours.
>
> >>>
>
> >>> Cheers,
>
> >>>
>
> >>> -hiro
>
> >>>
>
>  Family Members:
>
> 
>
>  F01E382DA524A57F2BFB3C4FF270A23D5CD3311D
>
> 
>
>  6231A1370700DD03046A85D953D35CAB5C21
>
> 
>
>  F9A28AB71D7E4E446308641A556EA53BA55FCB50
>
> 
>
>  23F74D581DE92AC59D3527DE4D448E036139D81E
>
> 
>
>  A00E900534DFF76371064C03714753EAF8B88820
>
> 
>
>  C232D8EE677E6BDF5CFFDDCAC4E2B1682DCE7AE5
>
> 
>
>  -  The Friendly Exit Node Family
>
> 
>
>  Sent with ProtonMail Secure Email.
>
> 
>
>  ‐‐‐ Original Message ‐‐‐
>
> 
>
>  On Thursday, September 23rd, 2021 at 8:39 AM, Silvia/Hiro 
>  h...@torproject.org wrote:
>
> 
>
> > Hello all,
>
> >
>
> > One of our goals with our current performance work is to reduce the
>
> >
>
> > overload of relays in the network. The implementation of proposal 328[1]
>
> >
>
> > a while back made different overload indicators available to relay
>
> >
>
> > operators and since a couple of weeks ago those can be tracked via
>
> >
>
> > Onionoo[2] as 

Re: [tor-relays] Overloaded state indicator on relay-search

[Bleedangel Tor Admin]

My relay was showing as overloaded and I couldn’t figure out why, system utilization was extremely low, only using a tiny bit of ram, network throughout was problem free, I was scratching my head until I realized it shows for 72 hours, and I had been doing a heavy distcc compile on my server one day previous.FYI all, if you show overloaded, it may not be tor, it may be that distcc compiling you did yesterday!On Thu, Sep 23, 2021 at 09:39, Silvia/Hiro  wrote:  Hello all,One of our goals with our current performance work is to reduce theoverload of relays in the network. The implementation of proposal 328[1]a while back made different overload indicators available to relayoperators and since a couple of weeks ago those can be tracked viaOnionoo[2] as well.As we know that a lot of our relay operators use relay search to checkfor the health of their relays, we have launched a new feature there,too, to help them know when their relays are overloaded.When a relay is in the overloaded state we show an amber dot next to therelay nickname.Currently we are counting between 50 and 80 overloaded relays andbetween 10 and 20 overloaded bridges.The overloaded state is reached when one or many of the possible loadmetrics have been triggered. When this happens we show it for 72 hoursafter the relay has recovered [3]. Note, though, that not all of theexposed overload metrics are triggering the overload indicator on relaysearch yet.If you noticed your relay is overloaded, please check the followingsupport article to find out how you can recover to a "normal" state:https://support.torproject.org/relay-operators/relay-bridge-overloaded/Let us known how you find this new feature.Cheers,-hiro[1]https://gitweb.torproject.org/torspec.git/tree/proposals/328-relay-overload-report.md[2]https://lists.torproject.org/pipermail/tor-project/2021-August/003168.html[3] https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n637___tor-relays mailing listtor-relays@lists.torproject.orghttps://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays




publicKey - tor@bleedangel.com - a010c89f.asc
Description: application/pgp-keys


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

[tor-relays] Need help with Dir Address and Exit Address

[Bleedangel Tor Admin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi all

I have an exit relay running, and all is working well. I am a stickler though, 
and i notice when i search my relay on the metrics page, the following two 
items are listed as 'none':

Dir Address 
Exit Address

Can anyone help me to get these reporting properly? I have a V2 Directory flag 
and my dir port is 9030. I am allowing ipv4 exits.

Metric page for reference: 
https://metrics.torproject.org/rs.html#details/5161B1C501805A0D3E9F87AFCAC9CBC075DBE8DC

Thanks for any help you can give!
-BEGIN PGP SIGNATURE-
Version: ProtonMail

wnUEARYKAAYFAmFJOgQAIQkQ07hp34FMyg4WIQSgEMifmnN5ohFWvfnTuGnf
gUzKDs8DAP4hSvlEPrlDkIY5vlLULhJHuNVbq/UT3r5mfBg/cg+p0wEAltfV
bPlU/3wfg7j0b31h6R4g+Ik+96fkoq9VTqiydQg=
=6AAW
-END PGP SIGNATURE-


publickey - tor@bleedangel.com - 0xA010C89F.asc
Description: application/pgp-keys


publickey - tor@bleedangel.com - 0xA010C89F.asc.sig
Description: PGP signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] FYI: Subpoena Received

[IPfail (Tor Admin)]

Vasilis,

It turned out to be a pretty "non-event". The jurisdiction was a relatively 
small one on the east coast of the US. The staff of the prosecutor's office 
were all very professional and pleasant to work with. Phoul coordinated the 
production of a letter from the Tor Project in record time that I was able to 
attach to my subpoena response.

In the end, the whole incident took ~4 hours to handle, and I suspect that any 
future ones would be much quicker now that I have all of the contacts in place 
and the attorneys up to speed.

In hindsight:
* Having a supportive and Tor-savvy ISP (Hurricane Electric) was a big plus.
* Having an attorney designated who is familiar with Tor /in advance/ would 
have saved time.

Your mileage may vary.

On Mon, Jul 23, 2018 at 08:42, Vasilis  wrote:

> Hi IPfail,
>
> "IPfail (Tor Admin)":
>
>> The one I received seemed very reasonable in language and scope, and came 
>> with contact information for someone with a title that implied that they 
>> work specifically on "cyber crimes". I am currently anticipating that this 
>> will be a non-event.
>>
>> Either way, I wanted to share this event with the relay community since one 
>> of the questions that I had when first starting out was how much 
>> "administrative overhead" could be expected as a result of operating relays.
>
> Thank you for reporting this to the mailing list.
>
> In case there is a resolution that you can publicly share it may be useful for
> current or upcoming relay operators/servers in US.
>
> Cheers,
> ~Vasilis
> --
> Fingerprint: 8FD5 CF5F 39FC 03EB B382 7470 5FBF 70B1 D126 0162
> Pubkey: https://pgp.mit.edu/pks/lookup?op=get=0x5FBF70B1D1260162___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] FYI: Subpoena Received

["IPfail (Tor Admin)"]

Thanks, Colin.

The one I received seemed very reasonable in language and scope, and came with 
contact information for someone with a title that implied that they work 
specifically on "cyber crimes". I am currently anticipating that this will be a 
non-event.

Either way, I wanted to share this event with the relay community since one of 
the questions that I had when first starting out was how much "administrative 
overhead" could be expected as a result of operating relays.

Sent from ProtonMail Mobile

On Fri, Jun 8, 2018 at 05:02, Colin Childs  wrote:

> Hello everyone, I just wanted to let people know that I have seen this thread 
> and am looking into what may be going on. If anyone else received these but 
> does not feel comfortable posting about them on the list, please do not 
> hesitate to reach out to me directly with anything you feel comfortable 
> sharing. I am not able to provide legal advice, but if this looks like a 
> situation where legal advice will be required, I have some contacts who may 
> be able to provide assistance. Thank you for running exit relays. > On Jun 8, 
> 2018, at 5:43 AM, Matt Traudt wrote: > > > > On 06/08/2018 01:42 AM, "IPfail 
> (Tor Admin)" wrote: >> FYI, I received a subpoena from a US based court to 
> produce information >> about individual(s) who were using one of our exit 
> nodes at a specific >> date/time. In the nearly 3 months that these exits 
> have been in >> operation, this is the first subpoena and only the second 
> complaint >> received. For purposes of documenting the approximate ratio of 
> >> "complaints / traffic processed", these nodes have handled ~515TB and >> 
> are using the recommended reduced exit policy. >> 
> https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy >> > > I 
> did too. Perhaps even from the same source...? Not sure if that can be > 
> shared so I just won't. > > My exit isn't in the US, but I am. > > Matt > 
> ___ > 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 
> @torproject.org>___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] FYI: Subpoena Received

["IPfail (Tor Admin)"]

Yes, the relays are US-based.

On Thu, Jun 7, 2018 at 23:10, I  wrote:

> Are and or the relay in USA?
>
>> FYI, I received a subpoena from a US based court to produce information 
>> about individual(s) who were using one of our exit nodes at a specific 
>> date/time.  In the nearly 3 months that these exits have been in operation, 
>> this is the first subpoena and only the second complaint received.  For 
>> purposes of documenting the approximate ratio of "complaints / traffic 
>> processed", these nodes have handled ~515TB and are using the recommended 
>> reduced exit policy.
>> https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] FYI: Subpoena Received

["IPfail (Tor Admin)"]

FYI, I received a subpoena from a US based court to produce information about 
individual(s) who were using one of our exit nodes at a specific date/time.  In 
the nearly 3 months that these exits have been in operation, this is the first 
subpoena and only the second complaint received.  For purposes of documenting 
the approximate ratio of "complaints / traffic processed", these nodes have 
handled ~515TB and are using the recommended reduced exit policy.
https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Shutdown of TorLand1

[tor-admin]

Hi all,

after 5 years of operation I will shutdown TorLand1 
(https://atlas.torproject.org/#details/E1E922A20AF608728824A620BADC6EFC8CB8C2B8)
 
on February 17 2017. 

During the time of operation it pumped almost 6 PetaByte of exit traffic. 
Compared to the amount of traffic, the number of complains were quite low. 
Around 1-2 complains per week with a reduced exit policy. Two times I was 
contacted by LE via email. 

When I started the exit relay there were around 20-30 high capacity relays 
available. Today compass shows 180 95+ MBit/s exits. TorLand1 was operated and 
paid by me without an organization like torservers, nos onions, etc. 

I hope others will step up and run high capacity exits. The Tor network needs 
your help. I will continue to run a meek bridge. 

Regards,

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

Re: [tor-relays] DoS from my tor guard VPS

[tor-admin]

On Tue, Nov 15, 2016 at 12:41:09PM -0800, Arisbe wrote:
> One of my tor guard relays is a medium size VPS operating in the Czech
> Republic.  It's been up and stable for several years.  Several weeks ago I
> was notified that my VPS was a source of UDP DoS traffic.  It was shut down.
> Logs showed no intrusions.
> 
> I installed a different instance of linux, changed my SSH port, added
> fail2ban and even installed clamav.  I did not make changes to the tor exit
> policy.  Then, this week I received the following:
> 
> "Hello,
> surveillance system detected a disproportionate outgoing DoS traffic on your
> VPS torexitcz and then our network under a DDoS attack. Your server
> torexitcz has been stopped. This is another problem with your VPS. Your
> service will be terminated.
> Thanks for understanding."
> 
> Can anyone offer an opinion as to how my relay was used for DoS? How can I
> avoid this in the future?  My goal, as always is to provide stable nodes to
> the tor network while protecting myself and my VPS supplier.

Are you running ntpd on the vps? your vps may being used for an ntp reflection 
attack

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

-- 
1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333

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

Re: [tor-relays] Research project - comparing abuse complaints on Tor exits to those of regular ISPs

[tor admin]

On Mon, Oct 24, 2016 at 02:20:06PM +0200, Volker Mink wrote:
>Mine is running for close to two years now and i got 2 regular complaints
>with specific accusation (torrent...) from known german lawyers.
>And one really common from my ISP - "we detected illegal activities.
>please perform a virus scan on your computers...".
> 
>Thats all :)

cool, I'm about to move a relay to exit node, I'm a bit scared do.
Do you run the "standard" [1] restricted exit policy? do you run an even more
reduced exit policy? could you shared it?

thanks!

[1] https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy

--
1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333

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

Re: [tor-relays] How to include files into torrc?

[tor-admin]

On Friday 09 September 2016 20:22:47 Ralph Seichter wrote:
>   # /etc/tor/torrc
>   ORPort 443
>   # Policies are kept in separate file for readability
>   Include /etc/tor/policies
> 
There is a ticket that handles this feature:

https://trac.torproject.org/projects/tor/ticket/1922

Regards,

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

Re: [tor-relays] [WARN]Failing because we have 4063 connections already. Please read doc/TUNING for guidance

[tor-admin]

On Sunday 21 February 2016 12:02:49 nusenu wrote:
> > since I upgraded the torland relay from 2.6.7 to 0.2.7.6 I get the
> > following warnings:
> > 
> > 09:20:30 [WARN] Failing because we have 4063 connections already. Please
> > read doc/TUNING for guidance. [101144347 similar message(s) suppressed in
> > last 21600 seconds]
> 
> Are you using tor packages from
> https://deb.torproject.org/torproject.org/dists/ ?
I get packages via
deb https://deb.torproject.org/torproject.org precise main

But I use a custom startup script from torservers, that is able to handle 
multiple instances. It should set ulimits -a 65535 but that seams not to work. 
After I increased it via sysctl, the warning is gone.

torland 

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

Re: [tor-relays] [WARN]Failing because we have 4063 connections already. Please read doc/TUNING for guidance

[tor-admin]

On Sunday 21 February 2016 12:57:52 Julien ROBIN wrote:
> When I had 2 tor clients running (the second launched manually by a user
> named "tor2"), I modified the "limits.conf" file, adding those 2 lines at
> the end :
> 
> #*   softcore0
> #roothardcore10
> #*   hardrss 1
> #@studenthardnproc   20
> #@facultysoftnproc   20
> #@facultyhardnproc   50
> #ftp hardnproc   0
> #ftp -   chroot  /ftp
> #@student-   maxlogins   4
> tor2 softnofile  10
> tor2 hardnofile  10
> 
> May be it needs a restart, or it doesn't apply to what have been started by
> "tor2" user before the modification When tor is launched by /etc/init.d/tor
> start may be this haven't to be done manually.
Thanks Julian for the hint. I adjusted limits.conf accordingly, so the users 
that run the tor processes get increased number of fds.

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

Re: [tor-relays] [WARN]Failing because we have 4063 connections already. Please read doc/TUNING for guidance

[tor-admin]

On Sunday 21 February 2016 11:56:37 Jonas Bergler wrote:
> https://gitweb.torproject.org/tor.git/tree/doc/TUNING

Thanks Jonas for the link. file descriptors should be set to ulimit -n 65535 in 
the tor startup script. I thought that would work. But checking 
/proc/PID/limits I saw that file descriptors were actually limited to 4096.

I increased fds via sysctl. Now the warning is gone.


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

[tor-relays] [WARN]Failing because we have 4063 connections already. Please read doc/TUNING for guidance

[tor-admin]

Hi all,

since I upgraded the torland relay from 2.6.7 to 0.2.7.6 I get the following 
warnings:

09:20:30 [WARN] Failing because we have 4063 connections already. Please read 
doc/TUNING for guidance. [101144347 similar message(s) suppressed in last 
21600 seconds]

Google only spits out https://trac.torproject.org/projects/tor/ticket/16929 
which does not help me. I don't find the mentioned branch bug16929 in git.

Can someone please advise what has to be done to avoid the warning, or point 
me where I find can the file "doc/TUNING". 

Thanks

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

Re: [tor-relays] pinning relay keys to IPs (or not)

[Tor-Admin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

teor:
 
 On 27 Jul 2015, at 01:30 , starlight.201...@binnacle.cx wrote:
 
 Perhaps a way to do it is reset the consensus for a relay if its
 IP address moves to a different Autonomous System.
 
 Is rare that dynamic IP causes relays to hop ASs (e.g. possibly
 SBC/ATT), and list of exceptions could be created for the few
 cases where it causes trouble.
 
 CYMRU has a dynamic service for looking up AS from IP.
 
 What if an entire IP block (or entire AS) moves ASs?
 
 What if the external dependency on CYMRU allows the entire Tor
 Network to be reset if CYMRU is hacked/broken/incorrect?


That will all not work, IPs are nothing which you can rely on and
reset consens if it does change. My home IP jump between to ASs every
day on reconnect. My ISP own both AS and with the IPv4 shortage that
will get even more crazy the next few years.
I'm cleary against reset consens, ban FP or what ever you guys think
would be right.
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJVtQXaAAoJEHkrhgAY5jaZjqgQAIprJTp+23DCddKlym8z/RkN
jhUK0zpWNpCYnfnlRujNtBcLoZBrKXCN5HhglOB70qsOONC6oGpKoQ1u51xiX1wL
zDH39kiRgZnhmaJm3W8J4Q2ZiLU233VLgfHsnuBWiFwGErBwRDIqMI6NDF6vbdF3
D7iXY8Adp4/6bwJaf0UDMt6qjYTUtL53vvtnjMK2eKwuwfiuXJjl8yQaDFN6qdzD
fSiohvUQdGN7oLDdqIOEmkBtX/ndK29aqvO+1mS8aXqkwDujNZHfDvoLYINJFEdG
qM5v7FLZY7Ey2FB3jaJQICq0DjUcRQM2+i2XilKQH/nQNeX5t4VjEhv4Gj+WR86b
S7v+m2vEwzLqqeZlyii31Cl9LBN8xOzUaw1JP2ErC9gxoB0BxyOz7Nv5Op49l1d6
yRxgYxyD/JIXJEC6GwvOCZOjITZBlMq4rhTX8kNLafwyiw2VucP5iPfEFZ09rXNt
9wr+68fhUU9OqUiolZJ44dIkRhBvymTaBFZNIcXqlrEh63vrIX5RSmNldxH84cau
6IpAuBREA7teqrWxoxYw/s2M6+BHqQiJVK5I4rlJyTk8KLyraDQ2W+QjGF2ZCKn9
HRiLTelLuREtH2nR4JDIrOAL+OacF6cqnh0ozRe/1h3q6zgEhp263GZxVpvroL9V
6yVR/Y6yi9mAQ/BHTgAG
=ZZCo
-END PGP SIGNATURE-


0x18E63699.asc
Description: application/pgp-keys
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Multi-core Support

[Tor-Admin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I have to agree with that, multicore support is really important and
should be on the top of the priority list.

Thomas White:
 Have there been any updated ETAs concerning the development/support
 of multi-core for the core tor workloads? If not, is there anything
 in particular that I could do to speed the process up? Scaling the 
 capabilities of the Tor process would be a huge relief and help for
 my upcoming project so I am keen to push it through should it be
 possible to bring up the priority list. t T
 
 ___ tor-relays mailing
 list tor-relays@lists.torproject.org 
 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
 
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJVbFoLAAoJEHkrhgAY5jaZsI0P/0lPBlJV+mG2qq4NJP7TSk8I
GW/NRoHYOfWRPmxHhOI8jB1tIAb3ha1ftUcVsdxTu6TiyQ4WDi7e+368LixDlkZ2
ipC2M9ibj7czzD+00au+HlGm/OPBwzOZNlOjTLIZfvVK8s+KiX31cBRIJUJkJNwI
g3/g0HPbujeDCGHfzE/XU3Q3eIMbFJ9CYvD077DkCGy/408TO2UqCIl/GVRk/ceH
qmWJ7m0rg/vIQlKraRP5qYmgDEomrJSL383DX9jVLv7yowb9DNrTD9CegVY9tF6l
MBipdy4N6JjpdMtK7WOzoI3zLwq3Ef2QHXL+zUdviBwmsWZBvycijRcyLUeoZ1Dc
0ZYVbyHQFnu1vo50a57G6UZvo1TF8h5iJGMEuEy4Kpqo68KcEC95f/H2zgIllKKA
TlKVx2MZOrzf/DtLsz6TWVNw0SuczehPHJNaxSkPDNFBMqLXZlLO2TUybBnDQdpb
EKlF72+zplW/2lnJ6y9wzEbWmdYHJOOzmGRD1jSgxkWWYfWbuXidGZc+88pT9G4u
BXLgvAxTPmsvDT4XZXDKVUBiKdFCLs5wwAMNvmdjUUbFgPLoXSCT5xH9pujVNH1z
AjyOih/NTyDuV0OzuqEMLxfDNCo+c9UrLLfj5NJjDWe6aGllwUW2W7HDgtbA4Nqq
HpYewE79EAyWG6rLykim
=PO2v
-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] how to monitor traffick through a bridge

[tor-admin]

On Monday 05 January 2015 17:40:09 mattia wrote:
 Hi, I would like to know how one can monitor traffic that goes
 through a bridge. I have set one up and would like to know whether it
 is being used or not, and how much. Thanks!

You might try arm: https://www.atagar.com/arm/

A nice ncurses based monitoring tool.

Regards,

torland

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

Re: [tor-relays] Possible DDoS

[tor-admin]

On Friday 26 December 2014 15:48:20 Christian Burkert wrote:
 Furthermore, I wondered if the attackers were attracted to my system
 because of the Tor service, or were just randomly picking targets.
 But from your previous descriptions, I rather deduce that it is more
 like the latter, rather random attacks, right?
DDOS happen from time to time. During 4 years operating  high capacity relays 
I saw no DDOS lasting longer that a couple of minutes. Probably what you 
experience is just some random attack.

Regards,

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

[tor-relays] [warn] No unused circIDs found on channel without wide circID support

[tor-admin]

Hi,

since upgrading torland to 0.2.5.8-rc I see the below warnings. Is this 
something to worry about?

Regards,

torland

--
Sep 28 16:07:24.000 [warn] No unused circIDs found on channel without wide 
circID support, with 0 inbound and 4 outbound circuits. Found 0 circuit IDs in 
use by circuits, and 64 with pending destroy cells. (0 of those were marked 
bogusly.) The ones with pending destroy cells have been marked unusable for an 
average of 7594 seconds and a maximum of 16137 seconds. This channel is 18469 
seconds old. Failing a circuit.
Sep 28 16:07:24.000 [warn]   Circuitmux on this channel has 4 circuits, of 
which 4 are active. It says it has 29535 destroy cells queued.
Sep 28 16:07:24.000 [warn] Channel 93320 (at 0x7fbff4579d90) with transport 
TLS channel (connection 3245390) is in state open (2)
Sep 28 16:07:24.000 [warn]  * Channel 93320 was created at 1411894775 (18469 
seconds ago) and last active at 1411913240 (4 seconds ago)
Sep 28 16:07:24.000 [warn]  * Channel 93320 says it is connected to an OR with 
digest 4C733BAC82CC609ACC58AD95BFBFF04D5D06188C and no known nickname
Sep 28 16:07:24.000 [warn]  * Channel 93320 says its remote address is 
[scrubbed], and gives a canonical description of [scrubbed] and an actual 
description of [scrubbed]
Sep 28 16:07:24.000 [warn]  * Channel 93320 has these marks: 
!bad_for_new_circs canonical is_canonical_is_reliable !client !local outgoing
Sep 28 16:07:24.000 [warn]  * Channel 93320 has 0 queued incoming cells and 0 
queued outgoing cells
Sep 28 16:07:24.000 [warn]  * Channel 93320 has 4 active circuits out of 4 in 
total
Sep 28 16:07:24.000 [warn]  * Channel 93320 was last used by a client at 0 
(1411913244 seconds ago)
Sep 28 16:07:24.000 [warn]  * Channel 93320 was last drained at 1411913141 
(103 seconds ago)
Sep 28 16:07:24.000 [warn]  * Channel 93320 last received a cell at 1411913240 
(4 seconds ago)
Sep 28 16:07:24.000 [warn]  * Channel 93320 last transmitted a cell at 
1411913141 (103 seconds ago)
Sep 28 16:07:24.000 [warn]  * Channel 93320 has received 234 cells and 
transmitted 2497
Sep 28 16:07:24.000 [warn]  * Channel 93320 has averaged 78.927350 seconds 
between received cells
Sep 28 16:07:24.000 [warn]  * Channel 93320 has averaged 7.396476 seconds 
between transmitted cells
Sep 28 16:07:24.000 [warn] failed to get unique circID
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Exit Nodes under DDoS attacks

[tor-admin]

Since I started operating the Torland1/Torland2 nodes in 2011 I noticed less 
than 20 DDOS attacks that lasted usually only a couple of minutes. I was never 
contacted by my provider.

regards,

torland

On Monday 04 August 2014 14:53:12 Tyler Durden wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256
 
 Hi
 
 I just wanted to know from others how often your nodes are being DDoSed?
 Because this month one of our nodes has been targeted twice.
 
 
 Because DDoS sucks and most providers aren't very happen when this
 happens often.

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

Re: [tor-relays] as well as block BitTorrent after repeated offenses...

[Tor Admin]

Hi,

I'll happily block BitTorrent it before any offenses start.  Just tell me  
how.


Regards,

=-John-=

snip snip

Spencer Neitzke spen...@neitzke.me spake thusly:


as well as block BitTorrent after repeated offenses



--
Using Opera's mail client: http://www.opera.com/mail/

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

Re: [tor-relays] Tor Relay Performance

[tor-admin]

There a couple of sysctrl parameters that Moritz described here: 
https://www.torservers.net/wiki/setup/server#sysctlconf

Without setting them my relays were not able to handle really large numbers of 
concurrent connections. 

Regards,

torland

On Monday 24 March 2014 20:02:15 Sebastian Urbach wrote:
 Hi,
 
 Everytime i speak with colleagues i wonder that the most performance
 related options for TOR relays are unknown.
 
 I just started to write down what i know and i would be happy if someone
 else could benefit from that.
 
 http://key-server.org
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] TTTT, multiple runs

[tor-admin]

Hi,

It seems to me that on http://datarepo.cs.illinois.edu/relay_scoreboard.html 
you list under Mesureing IPs the IP from where the data was uploaded via 
ssh, but that must not be the correct IP if the script was run with option -c 
'trace -S SRCADD' 

Regards,

torland

On Wednesday 19 February 2014 11:53:09 Sebastian Urbach wrote:
 Dear list members,
 
 The multiple runs question is now added to the FAQ at the Trying Trusted
 Tor Traceroutes project site.
 
 Right now we are at 95 ip's with at least 1 completed run. Hopefully we can
 add another 5 to that number and reach the 100 milestone before the next
 data review in 03/2014. Multiple run's from the same ip are very welcome as
 well.
 
 Thank you for your support !
 
 Want to help ? Project site:
 
 http://web.engr.illinois.edu/~das17/tor-traceroute_v1.html
 
 Want to see the results ?:
 
 http://datarepo.cs.illinois.edu/relay_scoreboard.html
 
 --
 Mit freundlichen Grüssen / Sincerely yours
 
 Sebastian Urbach
 
 --
 Those who would give up essential Liberty,
 to purchase a little temporary Safety, deserve
 neither Liberty nor Safety.
 --
 Benjamin Franklin (1706 - 1790),  Inventor,
 journalist, printer, diplomat and statesman
 
 
 ___
 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] using Arm to manage nodes

[tor-admin]

On Friday 07 February 2014 18:24:20 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?
For me same happens. I always press arrow up and then ESC. After that it works 
again.

Regards,

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

Re: [tor-relays] Trying Trusted Tor Traceroutes

[tor-admin]

On Friday 07 February 2014 22:05:41 Sebastian Urbach wrote:
 Dear list members,
 
 The Trying Trusted Tor Traceroutes project is coming closer to the next
 data review (03/2014).
 
 Basically every relay (except Bridges) can help to evaluate the Tor Routes.
 Please consider that one complete run takes about 4 days with the default
 settings.
 
 It's really easy to participate, just download and run the script ! We are
 currently at 82 completed runs and i think 100 is a great milestone :-)
 

How to use the traceroute script on a server with multiple IPs that are used 
for different tor instances. Is there a way to say the script to traceroute 
with a specific outgoing IP?

Regards,

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

Re: [tor-relays] Scoreboard enhancements / Trying Trusted Tor Traceroutes

[tor-admin]

On Sunday 26 January 2014 12:48:34 Sebastian Urbach wrote:
 But here the good news. The live scoreboard was modified. There is now a
 new column which shows the number of completed runs per IP and also at the
 bottom a value which displays the total sum of systems who completed at

I am wondering why only 68 out of 283 completed the traceroute. Can someone 
explain please?

regards

torland

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

Re: [tor-relays] Scoreboard enhancements / Trying Trusted Tor Traceroutes

[tor-admin]

On Sunday 26 January 2014 16:27:12 renke brausse wrote:
 The needed time (even for the default of scamper with 1000 pps) is imho
 a rather good explanation to torland's question why only 68 of nearly
 300 participating IPs finished the whole measurement at least once.
I launched the script from a high capacity tor relay host as well as from a 
VPS. I did not see a big difference in time. On both it finished within around 
4 days. 

I would assume that someone who reads the documents/FAQ about the script, 
checks it and starts it, will not kill it before it finishes. So I am 
wondering if there is another reason for the high number of unfinished script 
cycles.

Regards,

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

Re: [tor-relays] Torservers awarded $250,000 by Digital Defenders

[tor-admin]

On Saturday 14 December 2013 13:28:52 Christian wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Hej!
 
 Torservers.net has been awarded $250,000 over two years by the Digital
 Defenders Partnership to strengthen and improve the Tor network, the
 anonymity system crucial to journalists and human rights defenders using
 the Internet.

Great. Congratulation to the torservers team.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] What happens with the time on turtles 76.73.17.194?

[tor-admin]

Thanks. Sorry for the noise. Should have checked trac first.

On Saturday 21 September 2013 06:21:50 Roger Dingledine wrote:
 On Sat, Sep 21, 2013 at 12:19:42PM +0200, tor-admin wrote:
  Hi Mike,
  
  I am seeing many of these messages in the logs of torland1/torland2:
  
  Sep 21 12:09:34.000 [warn] Received NETINFO cell with skewed time from
  server at 76.73.17.194:9090.  It seems that our clock is ahead by 15969
  days, 10 hours, 9 minutes, or that theirs is behind. Tor requires an
  accurate clock to work: please check your time and date settings.
  
  Can you please check turtles.
  
  Thanks  regards,
 
 https://lists.torproject.org/pipermail/tor-relays/2013-September/002887.html
 https://trac.torproject.org/projects/tor/ticket/9798
 
 False alarm, they'll go away once Mike upgrades.
 
 --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

Re: [tor-relays] Upgrade your relay to 0.2.4.17-rc?

[tor-admin]

Updated torland family. Hope that the new version helps. One of the last 
messages before update to 0.2.4.17-rc:

Sep 05 21:06:29.000 [warn] Your computer is too slow to handle this many 
circuit creation requests! Please consider using the 
MaxAdvertisedBandwidth config option or choosing a more restricted exit 
policy. [434930 similar message(s) suppressed in last 60 seconds] 

Because of this the number of exit connections dropped significantly to 
300-400. Before this DDOS the exit numbers were around 7000-1.

Regards,

Torland

On Thursday 05 September 2013 06:54:57 Roger Dingledine wrote:
 Hi folks,
 
 I just released 0.2.4.17-rc. Hopefully there will be debs of it soon.
 
 It comes with a new feature:
 - Relays now process the new NTor circuit-level handshake 
requests
   with higher priority than the old TAP circuit-level handshake
   requests. We still process some TAP requests to not totally 
starve
   0.2.3 clients when NTor becomes popular. A new consensus 
parameter
   NumNTorsPerTAP lets us tune the balance later if we need to.
   Implements ticket 9574.
 
 So the more relays that upgrade to 0.2.4.17-rc, the more stable and 
fast
 Tor will be for 0.2.4 users, despite the huge circuit overload that the
 network is seeing.
 
 Please consider upgrading. If you do, though, please also keep an eye
 on it -- it's possible we introduced some new bugs and the network will
 start dissolving once more relays move to the new version.
 
 In my spare time I'm also working on a blog post to explain what's 
going
 on and what measures we're taking to keep things afloat.
 
 Aren't distributed systems fun,
 --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

Re: [tor-relays] Upgrade your relay to 0.2.4.17-rc?

[tor-admin]

On Thursday 05 September 2013 22:27:53 tor-admin wrote:
 Updated torland family. Hope that the new version helps. One of the last
 messages before update to 0.2.4.17-rc:
 
 Sep 05 21:06:29.000 [warn] Your computer is too slow to handle this many
 circuit creation requests! Please consider using the
 MaxAdvertisedBandwidth config option or choosing a more restricted exit
 policy. [434930 similar message(s) suppressed in last 60 seconds]
 
 Because of this the number of exit connections dropped significantly to
 300-400. Before this DDOS the exit numbers were around 7000-1.

Just noticed that during bootstrap there are new warnings I never noticed 
before. Is this a known issue or should I file a ticket?

Sep 05 21:56:12.000 [notice] Tor 0.2.4.17-rc (git-36eb3e0da4c3a821) opening 
log file.
Sep 05 21:56:12.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip.
Sep 05 21:56:12.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
Sep 05 21:56:12.000 [notice] Configured to measure statistics. Look for the *-
stats files that will first be written to the data directory in 24 hours from 
now.
Sep 05 21:56:12.000 [notice] Your Tor server's identity key fingerprint is 
'TorLand2 332895D092C2524A3CDE8F6E1498FFE665EBFC34'
Sep 05 21:56:14.000 [notice] We now have enough directory information to build 
circuits.
Sep 05 21:56:14.000 [notice] Bootstrapped 80%: Connecting to the Tor network.
Sep 05 21:56:14.000 [notice] Self-testing indicates your ORPort is reachable 
from the outside. Excellent. Publishing server descriptor.
Sep 05 21:56:14.000 [notice] Bootstrapped 85%: Finishing handshake with first 
hop.
Sep 05 21:56:15.000 [notice] Circuit handshake stats since last time: 599/782 
TAP, 3/3 NTor.
Sep 05 21:56:15.000 [warn] Problem bootstrapping. Stuck at 85%: Finishing 
handshake with first hop. (Connection refused; CONNECTREFUSED; count 10; 
recommendation warn)
Sep 05 21:56:15.000 [warn] 9 connections have failed:
Sep 05 21:56:15.000 [warn]  9 connections died in state connect()ing with SSL 
state (No SSL object)
Sep 05 21:56:16.000 [warn] Problem bootstrapping. Stuck at 85%: Finishing 
handshake with first hop. (Connection refused; CONNECTREFUSED; count 11; 
recommendation warn)
Sep 05 21:56:16.000 [warn] 10 connections have failed:
Sep 05 21:56:16.000 [warn]  10 connections died in state connect()ing with SSL 
state (No SSL object)
Sep 05 21:56:16.000 [warn] Problem bootstrapping. Stuck at 85%: Finishing 
handshake with first hop. (Connection refused; CONNECTREFUSED; count 12; 
recommendation warn)
Sep 05 21:56:16.000 [warn] 11 connections have failed:
Sep 05 21:56:16.000 [warn]  11 connections died in state connect()ing with SSL 
state (No SSL object)
Sep 05 21:56:16.000 [warn] Problem bootstrapping. Stuck at 85%: Finishing 
handshake with first hop. (No route to host; NOROUTE; count 13; recommendation 
warn)
Sep 05 21:56:16.000 [warn] 12 connections have failed:
Sep 05 21:56:16.000 [warn]  12 connections died in state connect()ing with SSL 
state (No SSL object)
Sep 05 21:56:16.000 [warn] Problem bootstrapping. Stuck at 85%: Finishing 
handshake with first hop. (Connection refused; CONNECTREFUSED; count 14; 
recommendation warn)
Sep 05 21:56:16.000 [warn] 13 connections have failed:

[..]

Sep 05 21:56:21.000 [warn] Problem bootstrapping. Stuck at 90%: Establishing a 
Tor circuit. (Connection timed out; TIMEOUT; count 54; recommendation warn)
Sep 05 21:56:21.000 [warn] 52 connections have failed:
Sep 05 21:56:21.000 [warn]  51 connections died in state connect()ing with SSL 
state (No SSL object)
Sep 05 21:56:21.000 [warn]  1 connections died in state handshaking (Tor, v3 
handshake) with SSL state SSL negotiation finished successfully in OPEN
Sep 05 21:56:21.000 [warn] Problem bootstrapping. Stuck at 90%: Establishing a 
Tor circuit. (Connection timed out; TIMEOUT; count 55; recommendation warn)
Sep 05 21:56:21.000 [warn] 53 connections have failed:
Sep 05 21:56:21.000 [warn]  52 connections died in state connect()ing with SSL 
state (No SSL object)
Sep 05 21:56:21.000 [warn]  1 connections died in state handshaking (Tor, v3 
handshake) with SSL state SSL negotiation finished successfully in OPEN
Sep 05 21:56:21.000 [warn] Problem bootstrapping. Stuck at 90%: Establishing a 
Tor circuit. (Connection timed out; TIMEOUT; count 56; recommendation warn)
Sep 05 21:56:21.000 [warn] 54 connections have failed:
Sep 05 21:56:21.000 [warn]  53 connections died in state connect()ing with SSL 
state (No SSL object)
Sep 05 21:56:21.000 [warn]  1 connections died in state handshaking (Tor, v3 
handshake) with SSL state SSL negotiation finished successfully in OPEN
Sep 05 21:56:21.000 [warn] Problem bootstrapping. Stuck at 90%: Establishing a 
Tor circuit. (Connection timed out; TIMEOUT; count 57; recommendation warn)
Sep 05 21:56:21.000 [warn] 55 connections have failed:
Sep 05 21:56:21.000 [warn]  54 connections died in state connect()ing with SSL 
state (No SSL object)
Sep 05 21:56:21.000 [warn]  1

Re: [tor-relays] A bit more evidence on circuit creation storms

[tor-admin]

You could modify the tor init script to limit the memory usable by 
/usr/sbin/tor as described here:

http://jlebar.com/2011/6/15/Limiting_the_amount_of_RAM_a_program_can_use.html

But I don’t know if this works on RaspPi platform and what happens when 
the tor process hits the memory limit.

Regards,

Torland

On Saturday 31 August 2013 11:14:04 Gordon Morehouse wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512
 
 krishna e bera:
  On 13-08-29 10:35 PM, Gordon Morehouse wrote:
  What on earth is causing so many circuit creation requests in
  such a short timespan?
  
  One possibility, if i recall correctly, is that the Tor that comes
  with the PirateBrowser bundle is configured to build single hop
  circuits.
 
  Make sure that these defaults are still set in your relay:
 The DDOS - because that's what it obviously is - managed to kill my
 Pi-based node last night, so I've finally restarted with all these
 except RefuseUnknownExits 1, just because of your caveat.
 
 I had some of the statistics already enabled, so it's continuing to
 collect those.
 
 Is there a way to give Tor a hard memory cap, so it won't chew up all
 available RAM on the system?
 
  AllowSingleHopExits 0 AllowSingleHopCircuits 0
  
  You can also try RefuseUnknownExits 1but maybe auto is better
  
  And these may help sketch the circuit storms: EntryStatistics 1
  ExitPortStatistics 1 ConnDirectionStatistics 1
 
 Best,
 Gordon M.
 
 -BEGIN PGP SIGNATURE-
 
 iQEcBAEBCgAGBQJSIjJoAAoJED/jpRoe7/ujuicH/Au5NXr/q5MTYH54mPPuE/OJ
 9jOkT/M34O0+U9gqYH8ja2gzTFf3CdxESraS6A7A+r2DWUX9R6l+zia5YX/SYCUu
 dWWNB843vXhcjNqhw01h05c70QgKStKrm6sLCjliVxhcovfMnkmMxLxk3EmQ3OzW
 nOdHQT2QGV+xCXqYz7FS9OtCnRmjTjI3bb8PJ1xcL76IjPGlCKr5vt7cDO3Y7x80
 o0hnPJxMhYs0MhS5sNXfHIifDNT6LlCuZvIT0GLe3w9Gg15BUYKgn5bi1iNEtoSV
 J/2DbxvmT23Tv6E2WnpxEoOu/yupbHAiDcYbwIT1ig4mePA/xCgjdm7mEdqrXpE=
 =AiLg
 -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] DigitalOcean, cheap VPS that's ok with middle relays

[tor-admin]

On Tuesday 08 January 2013 20:51:52 Moritz Bartl wrote:
 Thanks for the hint. In general, I don't see why VPS providers would not
 allow internal Tor relaying, and I would not even bother to ask first.
 Interesting values to know about VPS providers are bandwidth allowance
 (unlimited is quite obviously a marketing term; often, limits can only
 be discovered by some months of experience) and [socket/numfile]
 limitations. Support is often reluctant to provide such values before
 ordering. A good way to characterize VPS offers is to post the output of
 cat /proc/user_beancounters.

Before using dedicated server to run Tor I tested several VPS provider like 
Host Europe, Server4you and other smaller VPS hoster. For all VPS the maximal 
number of concurrent TCP connection was so small, that it made no sense to run 
Tor on it. So VPS provider guarantee unlimited Bandwidth but other limitations 
make these offers useless.

Regards,

Torland


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

Re: [tor-relays] Registration of a Tor node at the German Bundesnetzagentur

[tor-admin]

On Wednesday 02 January 2013 14:56:59 Moritz Bartl wrote:
 There is a fundamental legal difference between operating Internet
 Access Providers and Internet Service Providers. As a Tor exit, you
 should and want to be judged as a service provider. The key difference
 is that Access Providers give you Internet access, whereas Service
 Providers (Telemediendienste, tele media services) give you services
 which require (existing) network access.
 
 Access Providers are bound to the Telekommunikationsgesetz:
 http://www.gesetze-im-internet.de/tkg_2004/
Reading the law it is still unclear to me if a Tor node operator is a 
Diensteanbieter (service provider) as defined by the 
Telekommunikationsgesetz. If yes the law is pretty clear in § 6 that such a 
service has to be registered at the Bundesnetzagentur if it is done 
commercially. 
 
 Whereas service providers are bound to the Telemediengesetz:
 http://www.gesetze-im-internet.de/tmg/
 
 Most interesting for exit operators within German borders are:
 §8 - no liability for forwarded content (compare §512a DMCA USA)
 §15 - you are not allowed to collect or store user identifying data
 unless required for billing purposes

These paragraphs surely help Tor operators. 

Thanks for your comments.

Torland

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

Re: [tor-relays] Registration of a Tor node at the German Bundesnetzagentur

[tor-admin]

On Wednesday 02 January 2013 13:34:27 Fabian Keil wrote:
 While I was living in Overath I registered my relays with the
 Police in Rösrath (who always acted very professionally and respectful).
Good point. I never thought about pro actively informing the local police 
about my nodes. Will check this with my lawyer.
 
 Several years later Internet crime experts coming from the police
 in Bergisch Gladbach (pretty close to Rösrath) made first contact by
 executing a Durchsuchungsbeschluss (search warrant) that didn't mention
 Tor in any way ...
 
 Fabian

I hope these days German police is better educated about Tor exit nodes.

Thanks

Torland



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

Re: [tor-relays] Registration of a Tor node at the German Bundesnetzagentur

[tor-admin]

On Sunday 06 January 2013 20:35:25 Markus Drenger wrote:
 the guys from opentracker told us at 24c3 that they have made good
 experiences with informing their upstream provider about their
 activities. that way their provider forwarded all abuse-mails directly
 to them.
 
 events.ccc.de/congress/2007/Fahrplan/events/2355.en.html
 
 this might help with tor-nodes, too.

I informed my hosting provider about the Tor exit nodes. With each incoming 
abuse message they forward to me, I inform the employee that handles the 
message again about the purpose of the server. So for them it should be clear 
what and why this is happening.

Regards,

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

[tor-relays] Traffic pattern on Tor relay

[tor-admin]

Hi,

I am monitoring the network interface of my tor server with nload. From time 
to time nload shows strange traffic patterns: http://i.imgur.com/0Wr9h.png

The graph is updated every second so one hash mark corresponds to one second. 
The most recent traffic value is on the right side. The graph shows that the 
traffic oscillates with a period of about 14 seconds and the traffic doubles 
in the peaks.

Does anyone has an explanation of this pattern?

Regards,

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

Re: [tor-relays] Suggestions for Tor Relay Operators after a Police interaction

[tor-admin]

On Friday, 30. November 2012, 09:14:34 Andrew Lewman wrote:
 2. Find legal representation. A list of possible legal advisers can be
 found here,
 https://blog.torproject.org/blog/start-tor-legal-support-directory. If
 none of these people are in your country, or close to you, ask either
 the EFF or Tor Project. We can likely help you find someone in your
 jurisdiction.
For people in the German jurisdiction the CCC maintains a list of lawyers who 
are familiar with Tor. This list can be requested at torwarte AT ccc.de.

Regards,

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

Re: [tor-relays] How to get client locale statistics without arm?

[tor-admin]

On Wednesday, 28. November 2012, 14:47:05 Damian Johnson wrote:
 Have you tried tweaking the query rate options in your armrc?
 
 https://gitweb.torproject.org/arm.git/blob/HEAD:/armrc.sample

No I have not yet tried this.  

 
  Switching to the connection panel lets arm often freeze. Is there
  another way to get country statistics from a node? Maybe something build
  in
  Tor?
 
 You can query the locale for an address from tor via...
 
 https://gitweb.torproject.org/torspec.git/blob/HEAD:/control-spec.txt#l671
 
 To simulate what arm does you could write a script that makes
 netstat/lsof/procstat queries, parse the results, then feed those
 addresses to the 'GETINFO ip-to-country/*' command. Actually, I could
 probably write a script for you that does this via stem
 (https://stem.readthedocs.org/en/latest/index.html)...

Doing netstat queries means that I get 8+ ip addresses on my server. Each 
of these addresses I would have to check against the list of relays to sort 
out connections to other relays and only do GETINFO ip-to-country to the 
remaining IPs. This sounds complicated and error-prone. Can't the ORCONN event 
be used to get a notification if a client connects?

Thanks for your help

Torland

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

[tor-relays] How to get client locale statistics without arm?

[tor-admin]

Hi,

I would like to know from which countries my nodes are mostly used. I tried to 
use arm for this but on high capacity relays arm eats the same cpu resources 
as the tor process it monitors, if the connection panel is activated. 
Switching to the connection panel lets arm often freeze. Is there another way 
to get country statistics from a node? Maybe something build in Tor?

Thanks,

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

[tor-relays] Need help: High capacity exit relay does not get traffic

[tor-admin]

Hi,

I am operating two 1 GBit/s servers which host 7 exit nodes. One server is 
located in GB with

torland1
https://atlas.torproject.org/#details/4E377F91D326552AAE818D5A17BC3EF79639C2CD

torland2
https://atlas.torproject.org/#details/332895D092C2524A3CDE8F6E1498FFE665EBFC34

torland1 is configured to run at maximum bandwidth, torland2 runs trottled to 
ensure not to exceed the 100TB contractual traffic limit. The nodes on this 
server get traffic as expected and are at the top of the Blutmagie Tor Status 
http://torstatus.blutmagie.de/index.php?SR=BandwidthSO=Desc.

The second server is located in RO and hosts

torland3
https://atlas.torproject.org/#details/E5DB403858511BB166405E4C43776D933A7B86D6

torland4
https://atlas.torproject.org/#details/E0D2F8B2A18516A5C935477B06048D7BD2E7EC57

torland5
https://atlas.torproject.org/#details/D2F1745C11843BC5AF09CB9D4027AD2BE5F1B20A

torland6
https://atlas.torproject.org/#details/43F9022028F8AB0F7420F702CB079DF0CA0C80E3


The configuration for the GB and RO nodes is:

Nickname TorLandX
ORPort 443
DirPort 80
Address a.b.c.d
ORListenAddress  a.b.c.d
DirListenAddress a.b.c.d
OutboundBindAddress a.b.c.d

RelayBandwidthRate  30 MBytes  # max 30 

   
RelayBandwidthBurst 100 MBytes  # max 100   

   

MaxOnionsPending 250

NumCPUs 4

On both servers AES-NI is used by openssl.

Although the server in RO has the same configuration, same operating system 
and a similar hardware, it does not get traffic as the server in GB. At the 
moment Atlas shows for torland3-6 only an advertised bandwidth rate of less 
the 3 MB/s. The GB node torland1 shows more than 30 MB/s.

In order to test if there are any traffic limits I did several speed tests by 
doing up and downloads of a large 4GB iso image.

Downloading simultaneously with 10 curl instances from different debian 
mirrors I measured around 1 GBit/s. To measure upload I stored the debian 4GB 
iso image on the webserver of the RO server and used curl on the GB server to 
download it from RO. The maximal measured upstream speed on the RO server was 
around 750 Mbit/s. Therefore I looks for me as there are no traffic limits 
inplace by my ISP or their upstream. 

One of the servers operated by Torservers.net is located in the same data 
center and runs wau, gorz and sofia at high speed.

I am wondering why the directory authorities only measure such a small 
fraction of the available bandwidth for the RO nodes. Because I am paying 
personally for the server I would like to get most out of the server. Can 
someone who runs a tor authority please help me to understand what is the 
reason for the low observed bandwidth. 

Thanks,

Torland

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

[tor-relays] Massive ongoing google groups spamming

[tor-admin]

Hi all,

there is a massive spamming of google groups ongoing. I received several 
complains as below. From the domain list it seems that all major Tor exit 
nodes are affected.

Running an Exit without custom WHOIS, all abuse message are received by my 
ISP and forwarded. So I have to temporarily ban google groups. How do other 
operators deal with this?

Regards,
Torland

This is some voluminous, off-topic flooding and harassment on the
ba.broadcast Usenet newsgroup.  It is being reported to abuse reporting
mailboxes based on the contents of the NNTP-Posting-Host: and
X-Complaints-To: headers, and lookup of the originating IP address via
WHOIS and the Network Abuse Clearinghouse.  They are sometimes also
crossposted to unrelated newsgroups such as rec.arts.tv,
soc.culture.new-zealand, and several other newsgroups in the nz.*
hierarchy.  It is disruptive, and completely off-topic, as well as
causing disruptive, cascaded flame wars among those unrelated
newsgroups.

This user has also been posting from other sources, including 100tb.com,
51.net, 62.net, all.de, bahnhof.se, bayern.de, boingboing.net,
broadviewnet.net, ccc.de, formlessnetworking.net, hessmo.com,
noisetor.net, oceanic.net, plebia.org, privacyrepublic.org, riseup.net,
ru.is, sbcglobal.net, servers.com, snydernet.net, solidonetworks.com,
stanford.edu, stargrave.org, torland.me, torservers.net, dmzglobal.com,
telstraclear.net, xtra.co.nz, clear.net.nz, orcon.net.nz,
netgate.net.nz, freeparking.co.nz, powerusenet.com, giganews.com,
thundernews.com, altopia.com, comcast.net, groups.google.com, and
tigerusenet.com.  It appears that you are merely the latest of his
victims.

The charter of ba.broadcast is as follows:

This group is here for discussions, comments and program reminders
about broadcast media in the San Francisco Bay Area, both radio and
television.  It also includes cable systems and TVRO/BCRO in the SF Bay
Area.  It does not include scanner, ham radio or other action here in
the SF Bay Area; these may be addressed in another newsgroup at another
time.  Issues of national interest should be posted to one of the groups
in rec.arts.tv or rec.radio.

(see: 
http://groups.google.com/group/ba.broadcast/browse_thread/thread/ddfbd8175e26286e/d8f642f8a1fc5f42)

The charter does not include sexual innuendo and libel, abusive threats,
bigotry and minority bashing, or any off-topic discussion of subjects
not reasonably related to broadcasting in the Bay Area, which now
consitute the overwhelming majority of current message traffic on
ba.broadcast, to the detriment and exclusion of on-topic participation
by others.

Please take appropriate action to put a stop this this misbehavior
originating from your site that is disrupting ba.broadcast.

[... Offending article removed ...]
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Help the Tor Project by running a fast unpublished bridge

[tor-admin]

On Monday, August 13. 2012, 00:55:45 Roger Dingledine wrote:
 This discussion really goes back to a simple question: is it better to
 use our funding for more design and development, or for strengthening
 the network? For exit relays, I think choosing strengthen the network
 is a great and worthwhile experiment. But for bridges, since the current
 Tor transport and current bridge distribution strategies are not great,
 I think it's better to use funding for better designs and better code.
 I should note that I actually encouraged VoA to want unpublished bridges:
 if we set up fast bridges and published them via bridges.torproject.org
 today, they'd get blocked quickly in China.
 
My understanding of bridge detection was, that Chinas GFW is able to detect 
the Tor SSL handshake and does active bridge probing after a successful 
connection to a (for the GFW) unknown bridge IP. So they should be able to 
block any bridge publish or unpublished very quickly, if someone from behind 
the GFW connects to a bridge. Am I missing something?

Regards,

torland

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

Re: [tor-relays] ARM 1.4.5 has a very high cpu consumption

[tor-admin]

On, 9. Juni 2012, 12:32:21 Damian Johnson wrote:
 Hi Klaus. Nope, this isn't a known issue and it kinda surprises me
 since 1.4.5 was mostly just a bunch of bugfixes (there aren't any new
 features that should account for this). Would you mind running with
 the '--debug' flag? This will output a debug log to '~/.arm/log' (you
 might want to scrub anything in it that you think is private).
Thanks for your fast response. I sent you the log via pm.

Regards,

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

[tor-relays] ARM 1.4.5 has a very high cpu consumption

[tor-admin]

Hi,

today I updated arm from 1.4.4.1 to 1.4.5. After this update I noticed that 
the arm display is very unresponsive. The arm cpu jumps ever couple of 
seconds up to 90-100 %. If this happens arm does not update its display. 
This can be observed on all pages. I monitor two high capacity nodes with 
each about around 10K concurrent connections. 

With 1.4.4.1 the arm cpu was normally below 5 %. The tor server runs debian 
squeeze with python 2.6.6.

Is this a known issue? Any options other that downgrading back to 1.4.4.1?

Regards,

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

Re: [tor-relays] too many abuse reports

[tor-admin]

mick m...@rlogin.net wrote on 22.05.2012:
 I assume you mean IP address rather than port here. 
 
 Despite offering, I wasn't given the opportunity to do that.
 
 Interesting that you also seem to have been used in targetting the
 brazilian government. 
 
I can confirm abuse messages for same target, same attack.


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

Re: [tor-relays] Configuring a Tor relay to *not* accept torrent traffic

[tor-admin]

Red Rover redrover2...@gmail.com wrote on 17.05.2012:
 Hi there, :-)
 
 I am running a Tor relay on a VPS.
 
 How do I configure it to NOT accept torrent traffic?
 
 I have just received an abuse report from my hosting company.
 
 All the best,
 
 Redrover
 

Hi,

using a small python script I retrieved the TOP-100 trackers from 
www.torrentking.org and added them to torrc. I never got any DCMA report.

Regards,

torland

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