Re: [tor-relays] Tor Relay Operator Meetup - Saturday, April 13, 2024 at 19 UTC

[gus]

Hi,

Here are the meetup notes from April 2024. Sorry for sharing it only now.

The next meetup will happen this Saturday, May 11, 2024 at 19 UTC.
Feel free to add your topics here:
https://pad.riseup.net/p/tor-relay-may24-meetup-keep

cheers,
Gus

## Notes - Tor Relay Operator Meetup - April 13rd, 2024 @ 19 UTC

- Announcements:
 - New Network Health Team lead
   Read more about the network health team, and its goals and
priorities, at https://gitlab.torproject.org/tpo/network-health/team

 - 0.4.7 EOL removal
   Dir auths upgraded to 0.4.8.11 and relays running 0.4.7 were removed.
Dir auth Serge will upgrade to 0.4.8.11 sometime in May as getting new
bridges is harder than getting new relays.  If you don't upgrade your
logs will tell you that you need to upgrade.

 - Relay operator census: 

   Please fill out their survey! It takes some time to answer the
questions, but it is helpful to us for understanding our community. Even
if you used to run a relay and don't now, it's still useful. We will
publish the results of the survey in an anonymous way. It is funded by
OTF to fund fellowships for the people working on it. 80 responses so
far, which is good since it's only been publicized on the mailing list.
Next step is to mail the ContactInfo addresses for relay operators to
let them know about it.

English: https://survey.torproject.org/index.php/751125?lang=en
Spanish: https://survey.torproject.org/index.php/751125?lang=es

 - Tor-Weather 2.0 Release: 

   Tor weather is a service to notify you when your relay or bridge goes down.

 - New directory authority, tor26, and upcoming return of directory authority, 
Faravahar.
   Not because of any compromise or anything -- it's because tor26
moved to new hardware and a new internet location, so he decided it was
a good time to rotate to fresh keys.

 - Updates on the (D)dos situation Some relay operators are still seeing
   an ongoing overload, and some users were seeing speed issues. It
sounds like some guards are overloaded and some are less.  It sounds
like exit relay operators are less impacted by this recent issue.  What
in particular is overloaded? Memory, sockets, bandwidth? We don't know
-- the "overloaded" flag on relay-search doesn't tell us more specifics.

- Elections 2024: previous (March) / next round (April) Russia: before
  the elections, they blocked ntc.party, which is a major resource for
internet censorship discussion/advice. After the elections, they blocked
one further Tor website mirror. It looks like some of our other mirrors,
e.g. tor.eff.org, had been blocked already there.  Downloads via
official site (dist.torproject.org, not www.torproject.org) still work
though.  Upcoming elections in India, Panama, Dominican Republic, South
Africa For India, check out https://internetshutdowns.in/ run by SFLC in
India. As you've seen from the transparency reports there, the number of
internet shutdowns is in the past five years is unprecedented.

- New policy: guidelines for sustainability and incentivization proposals for 
the Tor network.
  - If you want to get some background on past tor incentive designs, check out 
https://blog.torproject.org/tor-incentives-research-roundup-goldstar-par-braids-lira-tears-and-torcoin/
 (now 10 years old!)
  - The new meta-proposal for how to structure your sustainability / incentives 
ideas will go public after some more interaction between Tor stakeholders 
before opening to the community.
  - Another ideas raised: small grants proposal, to do trainings for relay 
operators in areas or situations or countries where we need more participation.
  - Other ideas: it would be great for somebody to explore a badge-based 
gamification idea. Some of the work involved: what exactly do we want to 
incentivize?
  - Link: 
https://community.torproject.org/policies/relays/001-community-relay-operator-process/

# Questions & Answers

* Q: zimmer family hitting max descriptor size
https://gitlab.torproject.org/tpo/core/tor/-/issues/40837
Any news on a possible solution to this ongoing issue?
This is due to zimmer's family being really big. The eventual plan is to
move to a new design, e.g.
https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/321-happy-families.md
But the network team doesn't want to spend time working on C-Tor, and
Arti relays are more than a year off, so we're in an awkward holding
pattern.

* Q: the tor-relays@ list needs a moderator now that geko is taking a
break. There are several queued messages from last week.
A: Hiro needs to get the credentials for moderating tor-relays@.

* Q: Is the conflux design actually helping with performance? What stats
do we have there? (Question comes from the recent tor-relays@ thread
about Conflux, crash bugs, and performance.)

A: This is a good question and we would like to see some data that
supports 

Re: [tor-relays] Tor Relay Operator Meetup - Saturday, April 13, 2024 at 19 UTC

[gus]

Hi!

Just a friendly reminder that we're meeting today (Saturday, April 13) at 19 
UTC.

 - Please feel free to add other topics here:
 https://pad.riseup.net/p/tor-relay-april-meetup-keep
 
# Meetup details
 
 - Room link: https://tor.meet.coop/gus-og0-x74-dzn
 - When: April 13, 2024 - 19.00 UTC
 - Duration: 60 to 90 minutes

Gus

On Tue, Apr 09, 2024 at 04:57:41PM -0300, gus wrote:
> Hello,
> 
> The Tor Relay Operator will happen this Saturday, April 13 at 19UTC!
> 
> ## Agenda
> 
> - Announcements:
> - New Network Health Team lead
> - 0.4.7 EOL removal
> - Relay Operator census
> - Elections 2024: previous (March) / next round (April)
> - Q
> - Please feel free to add other topics here:
> https://pad.riseup.net/p/tor-relay-april-meetup-keep
> 
> ## Meetup details
> 
> - Room link: https://tor.meet.coop/gus-og0-x74-dzn
> - When: April 13, 2024 - 19.00 UTC
> - Duration: 60 to 90 minutes
> - Tor Code of Conduct:
>  https://community.torproject.org/policies/code_of_conduct/
> - Registration: No need for a registration or anything else, just use the
> room-linkabove. We will open the room 10 minutes before.
> 
> cheers,
> Gus
> -- 
> The Tor Project
> Community Team Lead



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


-- 
The Tor Project
Community Team Lead


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

[tor-relays] Tor Relay Operator Meetup - Saturday, April 13, 2024 at 19 UTC

[gus]

Hello,

The Tor Relay Operator will happen this Saturday, April 13 at 19UTC!

## Agenda

- Announcements:
- New Network Health Team lead
- 0.4.7 EOL removal
- Relay Operator census
- Elections 2024: previous (March) / next round (April)
- Q
- Please feel free to add other topics here:
https://pad.riseup.net/p/tor-relay-april-meetup-keep

## Meetup details

- Room link: https://tor.meet.coop/gus-og0-x74-dzn
- When: April 13, 2024 - 19.00 UTC
- Duration: 60 to 90 minutes
- Tor Code of Conduct:
 https://community.torproject.org/policies/code_of_conduct/
- Registration: No need for a registration or anything else, just use the
room-linkabove. We will open the room 10 minutes before.

cheers,
Gus
-- 
The Tor Project
Community Team Lead


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

[tor-relays] Tor relay operator research

[Ana Custura]

Dear operators,

We're conducting a study to understand relay operator motivations and needs, 
funded by OTF. We've already interviewed several of you and got feedback 
relating to community matters. Based on that feedback, we've put together a 
comprehensive survey:

English: https://survey.torproject.org/index.php/751125?lang=en

Spanish: https://survey.torproject.org/index.php/751125?lang=es

If you have about 30 minutes to spare and fill this in, it would be much 
appreciated! Your responses are valuable and will be used by the Tor project to 
understand the needs of the community, and how you feel about some 
controversial Tor-related issues. 

The survey is anonymous.

Cheers
Ana

PS: to find out more about the project, see 
https://www.opentech.fund/projects-we-support/supported-projects/the-tor-project-relay-operator-community-health/
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor Relay Automatic PMTU Testing

[boldsuck]

On Donnerstag, 22. Februar 2024 08:03:54 CET pasture_clubbed242--- via 
tor-relays wrote:

> I believe there is a larger sized guard relay that has been having MTU
> issues for about a week.

You are welcome to post the fingerprint or IP of the relay with MTU issues.
Or write to him directly if he has a contact address in Tor Metrics.

If a relay operator has an error in the config, he would like to correct it.
It is quite possible that someone has a typo in ip-/nftables because of the
DDOS countermeasures.


-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor Relay Automatic PMTU Testing

[pasture_clubbed242--- via tor-relays]

Usually lower MTUs are not a problem for properly configured networks, as even 
lower MTU systems should begin fragmenting traffic. The issue comes where there 
is a mismatch, and suddenly, larger than expected packets are dropped.

So I think the tor protocol does not need to support identifying relay MTUs, 
but I'm also unsure if it tests the largest cell size against relays either. 
Testing a very large cell size should identify if a relay is properly 
configured.

 Original Message 
On Feb 22, 2024, 5:47 AM, s7r - s7r at sky-ip.org wrote:

> pasture_clubbed242--- via tor-relays wrote: > Greetings, > > I believe there 
> is a larger sized guard relay that has been having MTU > issues for about a 
> week. All connections with packets above a certain > size are dropped. This 
> results in partially loaded or broken webpages, > broken file downloads, etc. 
> Do Tor directory authorities test MTU > (implicitly by speed test?) when 
> testing relays? > > Wondering if anyone else noticed this or if it would be 
> handled > automatically by dir authorities. > > Thanks all > This is indeed 
> very interesting. I never experienced this problem but now that you mention 
> it I will setup a test environment with some non standard MTU values. I doubt 
> the directory authorities test also the MTU, but it's an interesting 
> question, let's hope someone hosting a bandwidth authority will reply to 
> this. Also, I'm not sure and I'm very curios what the bandwidth authorities 
> should do about this? What if a relay has super good speed but very low MTU? 
> Should it be excluded and marked as not running? Because it will be very hard 
> for Tor to also include MTU in the router descriptors and be aware about it. 
> ___ tor-relays mailing list 
> tor-relays@lists.torproject.org 
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor Relay Automatic PMTU Testing

[s7r]

pasture_clubbed242--- via tor-relays wrote:

Greetings,

I believe there is a larger sized guard relay that has been having MTU 
issues for about a week. All connections with packets above a certain 
size are dropped. This results in partially loaded or broken webpages, 
broken file downloads, etc. Do Tor directory authorities test MTU 
(implicitly by speed test?) when testing relays?


Wondering if anyone else noticed this or if it would be handled 
automatically by dir authorities.


Thanks all



This is indeed very interesting. I never experienced this problem but 
now that you mention it I will setup a test environment with some non 
standard MTU values. I doubt the directory authorities test also the 
MTU, but it's an interesting question, let's hope someone hosting a 
bandwidth authority will reply to this.


Also, I'm not sure and I'm very curios what the bandwidth authorities 
should do about this? What if a relay has super good speed but very low 
MTU? Should it be excluded and marked as not running? Because it will be 
very hard for Tor to also include MTU in the router descriptors and be 
aware about it.




OpenPGP_signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Tor Relay Automatic PMTU Testing

[pasture_clubbed242--- via tor-relays]

Greetings,

I believe there is a larger sized guard relay that has been having MTU issues 
for about a week. All connections with packets above a certain size are 
dropped. This results in partially loaded or broken webpages, broken file 
downloads, etc. Do Tor directory authorities test MTU (implicitly by speed 
test?) when testing relays?

Wondering if anyone else noticed this or if it would be handled automatically 
by dir authorities.

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

[tor-relays] Tor relay operator research

[Ana Custura]

Dear operators,

I'm conducting a study to understand relay operator motivations and needs, 
funded by OTF.

If you had about 30-45 minutes to talk (completely anonymously if you wish) 
about your experience as a relay operator, it will really help this research, 
especially if you're running a relay in non-western country.

If interested please reach out to me either on ac...@torproject.org or 
a...@sr2.uk.

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

[tor-relays] Tor Relay Operators Meetup @ 37C3

[Stefan Leibfarth]

Hello everyone,

there will be a Tor Relay Operators Meetup @ 37C3:
https://events.ccc.de/congress/2023/hub/de/event/tor-relay-operators-meetup/

As always, TROMs are open for everyone (if you have a 37C3 ticket of course) 
who is running a relay, wants to run a relay or just thinks about it. :-)

At this point we don't have a agenda, but everyone is free to bring up 
questions or topics at the
meeting itself.

Please share with your friends, social media and other mailing lists!

See you there
Leibi



OpenPGP_0xE5CEBB2AC1354426.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor relay operator meetups

[fossdd via tor-relays]

Hey telekobold,

> will there be a Tor relay operators meetup @37C3 [*]?

There seems to be a Tor meetup as SoS (Self-organized session) by Q
Misell:

https://events.ccc.de/congress/2023/hub/en/event/tor-meetup

fossdd


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

[tor-relays] Tor relay operator meetups

[telekobold]

Hi,

will there be a Tor relay operators meetup @37C3 [*]?

Also, there were apparently no meetups in November and December this year?

Kind regards
telekobold

[*] https://events.ccc.de/congress/2023/infos/startpage.html
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor Relay in Kubernetes cluster

[Felix]

> Daniel Nikoloski
Hi Daniel

Not sure if that already has been answered. I don't use Kubernetes cluster but 
I find this one interesting:

> > Address 38.242.233.101
> > ORPort 9001 NoAdvertise IPv4Only
> > ORPort 32150 NoListen IPv4Only

I believe the Tor server service will publish port 32150 but it listens
to port 9001. It will not listen to where foreign Tor clients speak.
Simply "ORPort 9001" could be enough if you bind Tor to the published
address 38.242.233.101.

Unrelated:

If you will bind the Tor server service to an internal address
(10.x.x.x) ie for use in a container, NoAdvertise and NoListen can
be used to explain it to Tor:

Address 38.242.233.101
ORPort 10.x.x.x:9001 NoAdvertise IPv4Only
ORPort 38.242.233.101:32150 NoListen IPv4Only

The firewall needs to forward the traffic from the external to
the internal addresses. In pf world:
rdr on $IFEXT inet proto tcp from any to 38.242.233.101 port 32150
-> 10.x.x.x port 9001

Finally (in my setup) the outbound traffic needs nat. In pf world:
nat on $IFEXT inet from 10.x.x.x to any -> 38.242.233.101



pgpiJnautVozd.pgp
Description: Digitale Signatur von OpenPGP
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor Relay Operator meetup @ CCCamp 2023 - Friday 18th @ 16:00

[gus]

Hi,

We're rescheduling the Tor Relay Operator Meetup - CCCamp to Friday,
August 18th at 16:00 @ Bornhack village. Everyone is welcome to join us!

After the meetup, at 18:00, our friends from OONI will do their hack session at
Bornhack too: https://mastodon.social/@ooni/110894692073586929

And tonight, Thursday @ 20:00, we have a Tor talk at Milliways: 

A Guided Tour through Tor Network Health and Performance
https://events.ccc.de/camp/2023/hub/camp23/en/event/a-guided-tour-through-tor-network-health-and-performance/

See you there!
Gus

On Tue, Aug 15, 2023 at 02:50:53PM -0300, gus wrote:
> Hello,
> 
> The Tor Relay Operator Meetup - Chaos Communication Camp-2023[1] will
> happen at Bornhack (Cold North Village)[2] on Saturday, August 19th at 7pm
> (local time).
> 
> After the meetup, we invite everyone to stay and have beer and drinks at 
> Bornhack.
> Please spread the message.
> 
> We have Tor stickers for you! :)
> 
> Gus
> 
> [1] https://events.ccc.de/camp/2023/infos/
> [2] Coordinates: 53.0314175, 13.3065457
> https://map.events.ccc.de/camp/2023/map/#20/53.03143/13.3066
> -- 
> The Tor Project
> Community Team Lead



-- 
The Tor Project
Community Team Lead


signature.asc
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] Tor Relay Operator meetup @ CCCamp 2023 - Saturday 19th @ 7pm

[tor--- via tor-relays]

Yeah, some operators said the same thing to me.

Friday at 4pm local time (16 - 17:30) would be better for you?


yes, anything before Saturday is better, thanks!
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor Relay Operator meetup @ CCCamp 2023 - Saturday 19th @ 7pm

[gus]

Hi!

On Wed, Aug 16, 2023 at 12:25:32AM +0200, t...@appliedprivacy.net wrote:
> Hi Gus!
> 
> > Saturday, August 19th at 7pm
> 
> Isn't that a bit late?
> Last day at 7PM some will have left already, no?

Yeah, some operators said the same thing to me.

Friday at 4pm local time (16 - 17:30) would be better for you?

Gus
-- 
The Tor Project
Community Team Lead


signature.asc
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] Tor Relay Operator meetup @ CCCamp 2023 - Saturday 19th @ 7pm

[tor--- via tor-relays]

Hi Gus!


Saturday, August 19th at 7pm


Isn't that a bit late?
Last day at 7PM some will have left already, no?
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Tor Relay Operator meetup @ CCCamp 2023 - Saturday 19th @ 7pm

[gus]

Hello,

The Tor Relay Operator Meetup - Chaos Communication Camp-2023[1] will
happen at Bornhack (Cold North Village)[2] on Saturday, August 19th at 7pm
(local time).

After the meetup, we invite everyone to stay and have beer and drinks at 
Bornhack.
Please spread the message.

We have Tor stickers for you! :)

Gus

[1] https://events.ccc.de/camp/2023/infos/
[2] Coordinates: 53.0314175, 13.3065457
https://map.events.ccc.de/camp/2023/map/#20/53.03143/13.3066
-- 
The Tor Project
Community Team Lead


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

[tor-relays] Tor Relay in Kubernetes cluster

[Daniel Nikoloski via tor-relays]

Hi all,

Is anyone running Tor relay in k8s cluster? I am trying for a few days but It 
does not come alive. My servers are not behind a firewall, should be and are 
accessible, I run two bare-metal servers in Contabo. 1 master 1 node.

Docker image and helm chart that use; https://gitlab.com/nikoloskid/tor-server
The logs I get;

> Aug 05 21:04:55.000 [notice] Now checking whether IPv4 ORPort 
> 38.242.233.101:32150 is reachable... (this may take up to 20 minutes -- look 
> for log messages indicating success)
> Aug 05 21:24:45.000 [warn] Your server has not managed to confirm 
> reachability for its ORPort(s) at 38.242.233.101:32150. Relays do not publish 
> descriptors until their ORPort and DirPort are reachable. Please check your 
> firewalls, ports
>
> , address, /etc/hosts file, etc.

When i try telnet it is open to the internet

> telnet 38.242.233.101 32150
> Trying 38.242.233.101...
> Connected to 38.242.233.101.
> Escape character is '^]'.

You can see the service here; 
https://gitlab.com/nikoloskid/tor-server/-/raw/helm-chart-tor-relay/tor-server-helm/templates/04_service.yaml?ref_type=heads

/etc/tor/torrc;

> Nickname icebergk8s
> Address 38.242.233.101
> ContactInfo nikolos...@pm.me
> RelayBandwidthRate 3.5MB
> RelayBandwidthBurst 5MB
> MaxAdvertisedBandwidth 5MB
> ORPort 9001 NoAdvertise IPv4Only
> ORPort 32150 NoListen IPv4Only
> SocksPort 0
> ExitPolicy reject *:*
> User debian-tor
> DataDirectory /var/lib/tor

Lep pozdrav / Best Regards,

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

Re: [tor-relays] Tor Relay Operator Meetup - April 15th, 2023 at 19 UTC

[gus]

Hello,

Thanks everyone who joined us in the last meetup, in April. 
Here are the meetup notes, sorry for taking a long time to send it to
the list.

We're still figuring out the next meetup date -- probably June 24 --
and we will announce officialy soon here in the list. :)

In the next weeks Tor staff will be at SIF[1] and Rightscon[2].
If you're joining these events, come to say hi!

cheers,
Gus
[1] https://stockholminternetforum.se/
[2] https://www.rightscon.org/


# Tor Relay Operator meetup - 2023-04-15 . 19.00 - 20 UTC

## Agenda

### Announcements

- Update on Censorship in Turkmenistan:
- obfs4 bridges on residential connections + obfs4 port 80, 443, 8080
- Paper: https://arxiv.org/abs/2304.04835
- TMC dashboard: https://tmc.np-tokumei.net/
- Article:
  
https://globalvoices.org/2023/04/12/new-study-finds-internet-censorship-in-turkmenistan-reaches-over-122000-domains/
- Tor relays running EOL
- Tor Weather - https://weather.torproject.org 
- `HTTP/1.1 503 Service Unavailable` womp womp.
- Right, I'll enable the service on Monday again and, hopefully, it
  will stay available longer than the last time(s). Pretty bumpy launch :) 
--GeKo
- Google Summer of Code
  - We might have two network health related projects; the application
deadline is over and we are sorting through proposals. Those are for
the relay-to-relay connectitity checking tool and the network status API
projects on: https://gitlab.torproject.org/tpo/team/-/wikis/GSoC. If we
are lucky, we get mentees for both of them, we'll see... --GeKo
- DoS update
  "Load decreased by ~80% for our servers consistently. It's quite
manageable now. Servers are mostly idling now even without all the
attacks"

- Upcoming EFF university Tor relay advocacy campaign, still taking
  shape but now with a more detailed roadmap:
https://gitlab.torproject.org/tpo/community/relays/-/issues/67
- The Tor network has a status page! https://status.torproject.org/ --
  on this page we try to summarize critical issues about which pieces of
our infrastructure are having issues.

### (Discussion) Proposals towards a more trusted relay operator
community
https://gitlab.torproject.org/tpo/community/relays/-/issues/55

- Timeline of this process

October 2022 - January 2024

 - We called for proposals from the community (March 3 2023)
 - Work on proposals (TPO) (like meta proposal about the process and
   governance and different stake holders) (March/April)
 - Proposal evaluation (May/July)
 - Events and offline discussions with community (August/September)
 - Approving proposals after feedback from the community and figuring
   out the details of enforcement/adhering to them (September-December)
 - Proposals go live (January 2024)

### Status update on the "Bumping the 4 relays per ip to 8 relays per
ip"?
https://gitlab.torproject.org/tpo/core/tor/-/issues/40744#note_2896285:
We want to do the analysis for the bump to 4 relays per IP which won't
happen in April anymore but I try to sneak this into my May ToDo list.
Afterwards we can consider bumping the limit further in case the
analysis looks fine as expected. --GeKo
^^ I made a change to moria1 so it publishes its

AuthDirMaxServersPerAddr value in its v3 vote:
https://consensus-health.torproject.org/#consensusparams so we can know
if the dir auths are even allowing the new 4 number yet. Alas, it
appears that I am still the only dir auth using this patch.
https://gitlab.torproject.org/tpo/core/tor/-/issues/40753 seems to think
it will be in an upcoming Tor version. --Roger

### Q

Q: Is there a way for me to tell if my bridge is reachable from
Turkmenistan?
A: Alas we don't have an automated vantage point inside .tm. But we can
pass your bridge address to users in-country and ask them to test your
bridge. Email gus@ if you want to learn the answer! Only residential
connections are working there, so 'cloud' (data center) obfs4 bridges
probably do not work.

Q: Is it still unwise to run both a snowflake and also an obfs4 bridge
at home?
A: Correct, you should run either one or the other. The reason is that
if one of them gets your IP address blocked by a censor somewhere, then
the other one will end up blocked too.

Q: What if my IP address changes every few hours?
A: It doesn't make sense to run an obfs4 bridge in this situation,
because clients will learn about your address too late to use it. *But*,
this is a perfect situation for running a Snowflake proxy!

Q: When will we start bumping out Tor relays running 0.4.5?
A: Starting beginning of May. And bridges we will treat differently,
because they are more scarce. We might make an exception for 0.4.5
bridges that are popular.
Update:
https://forum.torproject.net/t/tor-relays-psa-tor-0-4-5-reaches-end-of-life-eol-on-2023-02-15/6338/9

Q: Re: the EFF University Relay campaign, University libraries will be
helpful here; did anything much result from the Library Freedom
Project's Tor Exit Relay Project?

Re: [tor-relays] Tor Relay Operator Poll (closes on 2023-05-30)

[krishna e bera]

Thanks for this initiative.

I am working on adding my AROI but ran into a minor snag.

The torrc man page (which btw i could not find on the torproject 
website) says the ContactInfo line can only contain an email address, 
though by example we have known for years it also can have a GPG key 
fingerprint.  Now the guide for setting up AROI says add these things:


|url:example.com proof:uri-rsa ciissversion:2 |

Maybe the whole line is arbitrary text.  Anyway is there an updated 
torrc spec somewhere?





On 2023-05-11 15:57, nusenu wrote:

Hi,

want to help shape the future of the Tor network?

Here is a poll for you:

https://cryptpad.fr/form/#/2/form/view/VE-b3bd-IS1P17Povh0ryIHYhqGqEiA7sJMRE8E0PB4/ 



It is open until 2023-05-30.

Only operators that did run relays/bridges before 2023-04-01
(and are still running) may participate.
An AROI or a relay fingerprint (or hashed bridge fingerprint)
is required to participate.

This poll happens in the context
of working on a network health proposal.

The goal of this poll is

* to gather input from non-malicious relay operators
* to help make pragmatical design decisions for an upcoming network 
health proposal

* to ensure it remains practical to implement for relay operators
* to get a feeling on whether it has a chance to see actual real world 
adoption
* to get a feeling on whether relay operators would participate in a 
web of trust
* to get a feeling on what type of rules relay operators would find 
acceptable


In the light of malicious entities this
poll has been send to large relay operators a few days ago
so they can claim their submission first.

Their feedback was also used to improve and extend the poll,
if you submitted it already once you can submit it again
but ensure to submit the same random string at the end as you
did the first time so they can be linked.

kind regards,
nusenu



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

[tor-relays] Tor Relay Operator Poll (closes on 2023-05-30)

[nusenu]

Hi,

want to help shape the future of the Tor network?

Here is a poll for you:

https://cryptpad.fr/form/#/2/form/view/VE-b3bd-IS1P17Povh0ryIHYhqGqEiA7sJMRE8E0PB4/

It is open until 2023-05-30.

Only operators that did run relays/bridges before 2023-04-01
(and are still running) may participate.
An AROI or a relay fingerprint (or hashed bridge fingerprint)
is required to participate.

This poll happens in the context
of working on a network health proposal.

The goal of this poll is

* to gather input from non-malicious relay operators
* to help make pragmatical design decisions for an upcoming network health 
proposal
* to ensure it remains practical to implement for relay operators
* to get a feeling on whether it has a chance to see actual real world adoption
* to get a feeling on whether relay operators would participate in a web of 
trust
* to get a feeling on what type of rules relay operators would find acceptable

In the light of malicious entities this
poll has been send to large relay operators a few days ago
so they can claim their submission first.

Their feedback was also used to improve and extend the poll,
if you submitted it already once you can submit it again
but ensure to submit the same random string at the end as you
did the first time so they can be linked.

kind regards,
nusenu
--
https://nusenu.github.io
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor Relay Operator Meetup - April 15th, 2023 at 19 UTC

[Roger Dingledine]

On Thu, Mar 30, 2023 at 11:04:25AM -0300, gus wrote:
> The next Tor Relay Operator Meetup will happen on April 15th, 2023, at 19 UTC.
> 
> We're still working on the agenda, feel free to add your topics and/or
> questions on the pad:
> https://pad.riseup.net/p/tor-relay-op-meetup-april-keep
> onionsite:
> http://kfahv6wfkbezjyg4r6mlhpmieydbebr5vkok5r34ya464gqz6c44bnyd.onion/p/tor-relay-op-meetup-april-keep
> 
> WHERE
> Room link: https://tor.meet.coop/gus-og0-x74-dzn
> 
> Registration
>  
> No need for a registration or anything else, just use the room-link
> above. We will open the room 10 minutes before so you can test your mic setup.
>  
> Please share with your friends, social media and other mailing lists!

Reminder! This event is in 21.5 hours, which depending on your
time zone might count as "tomorrow". :)

Looking forward to seeing you there,
--Roger

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

[tor-relays] Tor Relay Operator Meetup - April 15th, 2023 at 19 UTC

[gus]

Hello,

The next Tor Relay Operator Meetup will happen on April 15th, 2023, at 19 UTC.

We're still working on the agenda, feel free to add your topics and/or
questions on the pad:
https://pad.riseup.net/p/tor-relay-op-meetup-april-keep
onionsite:
http://kfahv6wfkbezjyg4r6mlhpmieydbebr5vkok5r34ya464gqz6c44bnyd.onion/p/tor-relay-op-meetup-april-keep

WHERE
Room link: https://tor.meet.coop/gus-og0-x74-dzn

Registration
 
No need for a registration or anything else, just use the room-link
above. We will open the room 10 minutes before so you can test your mic setup.
 
Please share with your friends, social media and other mailing lists!

Gus
-- 
The Tor Project
Community Team Lead


signature.asc
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] tor relay shows offline @ tor relay search while running

[Anonforpeace via tor-relays]

My bridge was showing the same thing. Then I learned that there is a bug in the 
relay search page and you should only trust \var\log\syslog

Sent from Proton Mail mobile

 Original Message 
On Feb 2, 2023, 4:40 PM, theyarewatching--- via tor-relays wrote:

> Good day,
> My relay shows offline on the Relay Search page but according to NYX the 
> relay is always running. I am running two relays on on Proxmox through my 
> home network. Please inform me of what info/logs you may need to help 
> diagnose this.
> Thank you for your time and help.
>
> TAW___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] tor relay shows offline @ tor relay search while running

[theyarewatching--- via tor-relays]

Good day,
My relay shows offline on the Relay Search page but according to NYX the relay 
is always running. I am running two relays on on Proxmox through my home 
network. Please inform me of what info/logs you may need to help diagnose this.
Thank you for your time and help.

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

[tor-relays] Tor Relay Operators Meetup Jan 28

[George]

Tomorrow is the next Tor relay operator meetup will happen on January 28
at 19:00 UTC!

We're drafting the agenda here:
 - pad: https://pad.riseup.net/p/tor-relay-op-meetup-j28-keep
 - onionsite:
http://kfahv6wfkbezjyg4r6mlhpmieydbebr5vkok5r34ya464gqz6c44bnyd.onion/p/tor-relay-op-meetup-j28-keep

Feel free to add topics and/or questions.

Room Link - https://tor.meet.coop/gus-og0-x74-dzn

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

Re: [tor-relays] Tor Relay on Gandi.net

[jvoisin via tor-relays]

https://metrics.torproject.org/rs.html#details/9BA84E8C90083676F86C7427C8D105925F13716C
is from Nos-Oignons, and they have a close partnership with Gandi.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor Relay on Gandi.net

[GANDI24325_TOR via tor-relays]

Hi,

I ran a tor exit on them and it got shut down on the 4th abuse claim, i have no 
idea how those 2 exits relays are still going,

I would recommend against them personally, and raised in the spring good-bad 
isps needs to be updated alot of ones on their are out of date

Best advice is do your own research and talk to the companies and don't sign up 
for long contracts


--- Original Message ---
On Friday, November 4th, 2022 at 17:12, protectmyonion via tor-relays 
 wrote:


> I was wondering if anyone had experience running a Tor relay on Gandi. 
> According to good-bad-isps, Gandi supports all relays.
> 

> However, I contacted support asking them their policy on Tor and if their 
> policy was the same for all Tor relays. Their response was basically 'You can 
> install any software you want, but its use is subject to French law and our 
> terms of service. If a complaint is received, the Abuse department will take 
> appropriate action and notify you.'.
> 

> This was pretty vague and kind of seemed like they didn't know what Tor was. 
> I responded and tried to explain what Tor was using most of what was in the 
> Common Boilerplate template. I explained that there were things that I could 
> do to reduce potential abuse, like limiting the exit policy, but that there 
> was always still potential for abuse.
> 

> The next response came from the Abuse department and basically said 'Any 
> illegal activity on your IP will result in your server being shutdown.'.
> 

> Based on this, it seems like Gandi is not a good ISP for Tor exits, but 
> likely fine for all other relays.
> 

> What's a little confusing is that according to Tor metrics, Gandi currently 
> has Tor exits. It is only 2, but nevertheless, they exist. France location 
> has 2 exits, but Luxembourg has none.
> 

> I'm not sure if good-bad-isps should be updated, given there's conflicting 
> information, but I figured I'd ask if anyone had personal experience with 
> Gandi.
> 

> Thanks.

publickey - GANDI24325_TOR@protonmail.com - 0xEDE0F88F.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] Tor Relay on Gandi.net

[protectmyonion via tor-relays]

mailto:tor-relays@lists.torproject.org
I was wondering if anyone had experience running a Tor relay on Gandi. 
According to 
[good-bad-isps](https://community.torproject.org/relay/community-resources/good-bad-isps/),
 Gandi supports all relays.

However, I contacted support asking them their policy on Tor and if their 
policy was the same for all Tor relays. Their response was basically 'You can 
install any software you want, but its use is subject to French law and our 
terms of service. If a complaint is received, the Abuse department will take 
appropriate action and notify you.'.

This was pretty vague and kind of seemed like they didn't know what Tor was. I 
responded and tried to explain what Tor was using most of what was in the 
Common Boilerplate template. I explained that there were things that I could do 
to reduce potential abuse, like limiting the exit policy, but that there was 
always still potential for abuse.

The next response came from the Abuse department and basically said 'Any 
illegal activity on your IP will result in your server being shutdown.'.

Based on this, it seems like Gandi is not a good ISP for Tor exits, but likely 
fine for all other relays.

What's a little confusing is that according to Tor metrics, Gandi currently has 
Tor exits. It is only 2, but nevertheless, they exist. 
[France](https://metrics.torproject.org/rs.html#search/as:AS203476) location 
has 2 exits, but 
[Luxembourg](https://metrics.torproject.org/rs.html#search/as:AS29169) has none.

I'm not sure if 
[good-bad-isps](https://community.torproject.org/relay/community-resources/good-bad-isps/)
 should be updated, given there's conflicting information, but I figured I'd 
ask if anyone had personal experience with Gandi.
Thanks.___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] tor relay over wifi

[andrew reid]

hi i am running a tor relay on an old phone over wifi. is this a bad idea ?
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Tor Relay showing as down

[Alexandre Corradi Guerreiro]

I have been running a ToR Relay for almost a year.
https://metrics.torproject.org/rs.html#details/6C6C87A774A211F53DE5116A7A8A9C447103A08B
and suddenly it stopped working.
I don't see any errors on the logs but the relay is always showing in the
relay search page as down. I even tried to upgrade the Tor client to a new
version 0.4.6.10 to see if something changes, but no success.
The process is running all the time, I see some circuit connections forming
and after a while no more traffic going.
Based on the syslog I see that everything looks fine, see next example.
Apr 18 20:32:17 ubu01 Tor[1093]: Bootstrapped 10% (conn_done): Connected to
a relay
Apr 18 20:32:17 ubu01 Tor[1093]: Bootstrapped 14% (handshake): Handshaking
with a relay
Apr 18 20:32:18 ubu01 Tor[1093]: Bootstrapped 15% (handshake_done):
Handshake with a relay done
Apr 18 20:32:18 ubu01 Tor[1093]: Bootstrapped 75% (enough_dirinfo): Loaded
enough directory info to build circuits
Apr 18 20:32:18 ubu01 Tor[1093]: Bootstrapped 90% (ap_handshake_done):
Handshake finished with a relay to build circuits
Apr 18 20:32:18 ubu01 Tor[1093]: Bootstrapped 95% (circuit_create):
Establishing a Tor circuit
Apr 18 20:32:19 ubu01 Tor[1093]: Bootstrapped 100% (done): Done
Apr 18 20:32:54 ubu01 Tor[1093]: New control connection opened.
Apr 18 20:37:51 ubu01 Tor[1093]: External address seen and suggested by a
directory authority: 187.74.71.95
Apr 18 20:38:17 ubu01 Tor[1093]: Now checking whether IPv4 ORPort
187.74.71.95:9001 is reachable... (this may take up to 20 minutes -- look
for log messages indicating success)
Apr 18 20:39:20 ubu01 Tor[1093]: Self-testing indicates your ORPort
187.74.71.95:9001 is reachable from the outside. Excellent. Publishing
server descriptor.
Apr 18 20:40:27 ubu01 Tor[1093]: New control connection opened.
Apr 18 20:42:20 ubu01 Tor[1093]: Performing bandwidth self-test...done.

I tried to test my income connection from another computer to validate that
there was no block on the ISP side, I could connect successfully to port
9001 as indicated on the logs.
How can I troubleshoot  this problem?
--
Alexandre C Guerreiro
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor Relay Operator Meetup (Saturday, March 5th @ 2000 UTC)

[Christian Pietsch]

Thanks, Marco and Frank!

We have added this mirror to our multilingual instructions now.
At least in Germany, downloads are much faster from NetCologne.

Cheers,
Christian

On Sat, Apr 02, 2022 at 06:17:19PM +0200, li...@for-privacy.net wrote:
> On Monday, March 14, 2022 8:46:23 PM CEST Christian Pietsch wrote:
> > I almost put the netcologne mirror into a blog post I co-wrote
> >  – but then I noticed
> > that the download links do not work.
> 
> The nice admin from NetCologne fixed the links. There is now the subdomain: 
> https://torproject.netcologne.de/
> 
> Download archive is also available directly:
> https://torproject.netcologne.de/dist/


signature.asc
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] Tor Relay Operator Meetup (Saturday, March 5th @ 2000 UTC)

[lists]

On Monday, March 14, 2022 8:46:23 PM CEST Christian Pietsch wrote:
> I almost put the netcologne mirror into a blog post I co-wrote
>  – but then I noticed
> that the download links do not work.

The nice admin from NetCologne fixed the links. There is now the subdomain: 
https://torproject.netcologne.de/

Download archive is also available directly:
https://torproject.netcologne.de/dist/


-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor Relay Operator Meetup (Saturday, March 5th @ 2000 UTC)

[lists]

On Tuesday, March 15, 2022 12:02:45 AM CET li...@for-privacy.net wrote:

> Shame on me, I didn't test the downloads. Only the Android binaries can be
> downloaded. I will write to the admins and ask them to offer the files for
> download.

Maybe someone has hints for NetCologne mirror admin here:
https://lists.torproject.org/pipermail/tor-mirrors/2022-March/001246.html

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor Relay Operator Meetup (Saturday, March 5th @ 2000 UTC)

[lists]

On Monday, March 14, 2022 8:46:23 PM CET Christian Pietsch wrote:
> I almost put the netcologne mirror into a blog post I co-wrote
>  – but then I noticed
> that the download links do not work. For example,
> https://mirror.netcologne.de/dist/torbrowser/11.0.7/tor-browser-linux64-11.0
> .7_en-US.tar.xz → Error 404

Shame on me, I didn't test the downloads. Only the Android binaries can be 
downloaded. I will write to the admins and ask them to offer the files for 
download.

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor Relay Operator Meetup (Saturday, March 5th @ 2000 UTC)

[Christian Pietsch]

I almost put the netcologne mirror into a blog post I co-wrote
 – but then I noticed
that the download links do not work. For example,
https://mirror.netcologne.de/dist/torbrowser/11.0.7/tor-browser-linux64-11.0.7_en-US.tar.xz
→ Error 404

Cheers,
Christian


On Mon, Mar 14, 2022 at 08:37:42PM +0100, li...@for-privacy.net wrote:
> My ISP mirrors the Tor website and Tor Browser can be downloaded from there:
> https://debian.netcologne.de/torproject.org/
> https://mirror.netcologne.de/torproject.org/
> 
> > We have a Telegram bot, which returns some bridges. The anti-censorship 
> > team is testing these bridges from a vantage point in Russia, and if 
> > they're blocked we rotate the bridge to a new address. We have 25k 
> > people connected over the Telegram bot bridges.
> Maybe the link can be spread in the bot with the bridges.


signature.asc
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] Tor Relay Operator Meetup (Saturday, March 5th @ 2000 UTC)

[lists]

On Monday, March 14, 2022 9:19:41 AM CET Georg Koppen wrote:

> > Pad notes will be posted after the meeting.
> 
> 
> Here they come.
Thanx a lot!

> * Censorship situation in Russia:
> 
> Since Dec 2021, the censorship department in Russia started to block 
> parts of the Tor network. It's not uniform -- in some places Tor works 
> fine, in some places the website is reachable, in others it doesn't.
My ISP mirrors the Tor website and Tor Browser can be downloaded from there:
https://debian.netcologne.de/torproject.org/
https://mirror.netcologne.de/torproject.org/

> We have a Telegram bot, which returns some bridges. The anti-censorship 
> team is testing these bridges from a vantage point in Russia, and if 
> they're blocked we rotate the bridge to a new address. We have 25k 
> people connected over the Telegram bot bridges.
Maybe the link can be spread in the bot with the bridges.

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor Relay Operator Meetup (Saturday, March 5th @ 2000 UTC)

[Toralf Förster]

On 3/14/22 09:19, Georg Koppen wrote:
But, there is a lag between when a new bridge appears and when Russia 
starts blocking it. That lag is often a week or more these days.


So, after a week the affected bridges can be stopped ?
--
Toralf


OpenPGP_signature
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor Relay Operator Meetup (Saturday, March 5th @ 2000 UTC)

[Leon D]

Just wanting to put this out there, I was wondering whether during the
current situation in Russia is it best to run a Bridge or a Relay?

I want to make sure that Tor can be easily accessed anywhere in the world,
as such they are both good choices.

My bandwidth is 1Gbps and I have the hardware necessary for either.



On Mon, 14 Mar 2022 at 16:37, Vasilis  wrote:

> Hi,
>
> Georg Koppen:
> > ## Meetup notes March 5
>
> Thank you for sending the meetup notes Georg.
>
> > With Russia blocking most western media outlets and Facebook etc. I was
> > expecting an uptick in traffic but I saw nothing... Is Tor not well
> enough known
> > maybe?
> >
> > Sanctions against Russia, EU council regulation 2022/350
> > (
> https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32022R0350)
> >
> >   - Article 2f: It shall be prohibited for operators to broadcast or to
> enable,
> > facilitate or otherwise contribute to broadcast ... certain media
> >
> >   - Article 12: It shall be prohibited to participate, knowingly and
> > intentionally, in activities the object or effect of which is to
> circumvent
> > prohibitions
>
> How such a blocking order could be potentially implemented?
>
> Are VPNs also block these websites to EU citizens?
>
>
> -Vasilis
> --
> PGP Fingerprint: 8FD5 CF5F 39FC 03EB B382 7470 5FBF 70B1 D126 0162
> PGP Public Key:
>
> https://keys.openpgp.org/vks/v1/by-fingerprint/8FD5CF5F39FC03EBB38274705FBF70B1D1260162
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor Relay Operator Meetup (Saturday, March 5th @ 2000 UTC)

[Vasilis]

Hi,

Georg Koppen:

## Meetup notes March 5


Thank you for sending the meetup notes Georg.

With Russia blocking most western media outlets and Facebook etc. I was 
expecting an uptick in traffic but I saw nothing... Is Tor not well enough known 
maybe?


Sanctions against Russia, EU council regulation 2022/350 
(https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32022R0350)


  - Article 2f: It shall be prohibited for operators to broadcast or to enable, 
facilitate or otherwise contribute to broadcast ... certain media


  - Article 12: It shall be prohibited to participate, knowingly and 
intentionally, in activities the object or effect of which is to circumvent 
prohibitions


How such a blocking order could be potentially implemented?

Are VPNs also block these websites to EU citizens?


-Vasilis
--
PGP Fingerprint: 8FD5 CF5F 39FC 03EB B382 7470 5FBF 70B1 D126 0162
PGP Public Key: 
https://keys.openpgp.org/vks/v1/by-fingerprint/8FD5CF5F39FC03EBB38274705FBF70B1D1260162

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

Re: [tor-relays] Tor Relay Operator Meetup (Saturday, March 5th @ 2000 UTC)

[Georg Koppen]

George:

On 3/5/22 13:40, flux via tor-relays wrote:

Hi,

will there be a recording? Unfortunately I won't be able to attend.


Unfortunately not flux.

We will catch you next time.

Pad notes will be posted after the meeting.


Here they come.

On March 5, a group of 40-50 operators joined the Tor Relay Operator meetup.

Thank you all for joining the event!

Our next online meetup will happen on *April 2nd, 2100 UTC* according to 
the pad. However, I think we made a mistake here with daylight savings 
time given that we wanted to have the meeting at the same time for the 
folks not having shifted back then in March 5. I'll check back with Gus 
for that.


Georg

## Meetup notes March 5

* Should we record this session? Some people don't have audio / can't 
make it:


Conclusion is no, do not record. We want people to be free to say things 
and not worry that they will show up in a youtube video later.


* Tor EOL removal (0.3.5):

The old Tor long-term-support (0.3.5.x) is no longer maintained by the 
network team, since Feb 1 2022. We collected all the relay descriptors 
that had a usable contactinfo, and contacted them. We also did it for 
bridge operators (another reason it's important to have usable contact 
info). If you are a new relay operator, check if you're running one of 
these old versions!


* Torservers update:

RIP frënn vun der ënn (https://enn.lu) 
(https://twitter.com/FrennVunDerEnn/status/1496129197064007692) Mainly 
they decided it was too much work, and they didn't have capacity to do 
it with high quality, so they decided to close.


If you have a lot of capacity, and can run a bunch of bridges, please 
get in touch with Gus and Tor! We'd been using enn.lu's bridges to give 
private bridges to people in China.


* Censorship situation in Russia:

Since Dec 2021, the censorship department in Russia started to block 
parts of the Tor network. It's not uniform -- in some places Tor works 
fine, in some places the website is reachable, in others it doesn't. Not 
just the public relays, but also they were blocking the default obfs4 
bridges and some other obfs4 Tor bridges.


We have three different distribution methods of Tor bridges.

 - Moat: install Tor Browser on your desktop/phone, click "get some 
bridges" inside Tor Browser, and bridgedb automatically populates your 
bridge configuration. 6 requests per day from users to get a bridge 
by Moat. Up from 10k/day earlier.


 - Request by email: mail us at bridges @ torproject.org and we'll 
answer some.


 - Go to our website, bridges.torproject.org, and solve a captcha and 
get one.


All three of these mechanisms are under attack in Russia. That is, all 
three of them are problematic. But, there is a lag between when a new 
bridge appears and when Russia starts blocking it. That lag is often a 
week or more these days.


We have a Telegram bot, which returns some bridges. The anti-censorship 
team is testing these bridges from a vantage point in Russia, and if 
they're blocked we rotate the bridge to a new address. We have 25k 
people connected over the Telegram bot bridges.


The Snowflake pluggable transport (see: Snowflake surge below) also got 
blocked in December, using a DPI rule. We changed the Snowflake code, 
and the DPI rule no longer works to block it. At the moment Snowflake is 
working in Russia. Note that the metrics of Snowflake users are 
currently inaccurate, because we've been working on scaling the 
Snowflake bridge, and we haven't kept up with keeping the metrics 
accurate. (Gitlab ticket: 
https://gitlab.torproject.org/tpo/network-health/metrics/onionoo/-/issues/40022)


Is rt.com and sputnik blocked from Europe? Does that mean it's blocked 
from many Tor exits? Or was that just a proposed law or threat? 
(https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32022R0350)


 - Mostly seems to be blocked by their DDoS mitigation

 - in France it's blocked by DNS if you use your ISP's, otherwise it's 
fine (well, DDoS mitigation)


 - Not blocked with Deutsche Telekom AG on Germany, but I'm not using 
their recursive DNS. Checked their DNS get correct answer for rt.com but 
forged NXDOMAIN for www.rt.com.


 - How come rt.com doesn't have an onion address by now? :)

Tool from a person in the meeting, for running many bridges in a 
scalable way: https://github.com/gergelykalman/torspray


I should also mention this tool: https://tor-relay.co/ and irl's 
automated dynamic bridge project, and FreedomBox project


We should put together a single unified page which points to all of the 
Tor community's contributions here, so we have them more organized.


* Snowflake surge

Some folks want to help run a bridge but it's complicated, or they worry 
that it will draw attention to them. Many of these people are happily 
running Snowflake proxies.


Snowflake, is a web-browser (FireFox, Chrome) Tor-Bridge Extension, 
Snowflake uses WebRTC to act as a Bridge/Guard relay, and it runs when 
your browser is 

Re: [tor-relays] Tor Relay Operator Meetup (Saturday, March 5th @ 2000 UTC)

[George]

On 3/5/22 13:40, flux via tor-relays wrote:

Hi,

will there be a recording? Unfortunately I won't be able to attend.


Unfortunately not flux.

We will catch you next time.

Pad notes will be posted after the meeting.

g



Best,

flux


On 3/4/22 18:16, gus wrote:

Hello everyone,

This Saturday, March 5th @ 2000 UTC, we have a Tor Relay Operator
Meetup!

We'll share some updates about Tor Network Health, Tor Bridges and the
ongoing situation in Russia/Ukraine (Snowflake surge, bridges blocked,
BBC and DW onionsites). Everyone is free to bring up additional questions
or topics at the meeting itself.

Date & Time: March 5, 2022 - 2000 UTC
Where: BigBlueButton room - https://tor.meet.coop/gus-og0-x74-dzn

No need for a registration or anything else, just use the room-link
above.

Please share with your friends, social media and other mailing lists!

cheers,
Gus

___
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] Tor Relay Operator Meetup (Saturday, March 5th @ 2000 UTC)

[flux via tor-relays]

Hi,

will there be a recording? Unfortunately I won't be able to attend.

Best,

flux


On 3/4/22 18:16, gus wrote:

Hello everyone,

This Saturday, March 5th @ 2000 UTC, we have a Tor Relay Operator
Meetup!

We'll share some updates about Tor Network Health, Tor Bridges and the
ongoing situation in Russia/Ukraine (Snowflake surge, bridges blocked,
BBC and DW onionsites). Everyone is free to bring up additional questions
or topics at the meeting itself.

Date & Time: March 5, 2022 - 2000 UTC
Where: BigBlueButton room - https://tor.meet.coop/gus-og0-x74-dzn

No need for a registration or anything else, just use the room-link
above.

Please share with your friends, social media and other mailing lists!

cheers,
Gus

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

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

Re: [tor-relays] Tor Relay Meetup #Fosdem Notes

[Stefan Leibfarth]

Hello everyone,


On February 7, 2022 9:55:16 PM GMT+01:00, gus  wrote:

>Our next online meetup will happen on March 5th, 2000 UTC.

Friendly reminder, that's tomorrow. :-)
Details will follow, most likely by Gus. 
I'm really busy with private stuff atm... 

All the best
Leibi___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Tor Relay Operator Meetup (Saturday, March 5th @ 2000 UTC)

[gus]

Hello everyone,

This Saturday, March 5th @ 2000 UTC, we have a Tor Relay Operator
Meetup!

We'll share some updates about Tor Network Health, Tor Bridges and the
ongoing situation in Russia/Ukraine (Snowflake surge, bridges blocked,
BBC and DW onionsites). Everyone is free to bring up additional questions
or topics at the meeting itself.

Date & Time: March 5, 2022 - 2000 UTC
Where: BigBlueButton room - https://tor.meet.coop/gus-og0-x74-dzn

No need for a registration or anything else, just use the room-link
above.

Please share with your friends, social media and other mailing lists!

cheers,
Gus
-- 
The Tor Project
Community Team Lead


signature.asc
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] Tor Relay Meetup #Fosdem Notes

[lists]

On Wednesday, February 16, 2022 1:50:19 AM CET li...@for-privacy.net wrote:

> After the next location database update, there should be 
DONE, thanks to Peter Mueller from the IPfire Project and Torproject GeoIP DB 
gods. (-hiro?)
That was damn fast.

> >   * Is it bad to have too many exit relays in one country? And how many is
> > 
> > too many?
> > 
> > * Norway and the US and DE seems to be quite saturated already with
> > exit
> > 
> > relays:
> > NO - 37, 481 MiB/s Tor metrics numbers
> > US - 536, 4898 MiB/s
> 
>  about 200 fewer relays in the US and be 200 more in Luxembourg.
US - 374, 3190.21 MiB/s
LU - 166, 1864.33 MiB/s

https://metrics.torproject.org/rs.html#search/flag:exit%20country:us
https://metrics.torproject.org/rs.html#search/flag:exit%20country:lu

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor Relay Meetup #Fosdem Notes

[lists]

On Monday, February 7, 2022 9:55:16 PM CET gus wrote:

>   * Are there instructions for how people can report bugs to IPFire?
> 
> Yes, look at
> https://forum.torproject.net/t/tor-relay-search-showing-location-of-some-re
> lays-incorrectly/1331 We had an example where a relay operator requested a
> change from IPFire, and it seems to have gone surprisingly smoothly and
> easily.
> 
Yes, thanks for the hint. The Frantech/BuyVM¹ Tor relays in Luxembourg should 
be corrected soon (TM). I submitted a bug report:
https://bugzilla.ipfire.org/show_bug.cgi?id=12774

After the next location database update, there should be 
>   * Is it bad to have too many exit relays in one country? And how many is
> too many?
> 
> * Norway and the US and DE seems to be quite saturated already with exit
> relays:
> 
> NO - 37, 481 MiB/s Tor metrics numbers
> US - 536, 4898 MiB/s
 about 200 fewer relays in the US and be 200 more in Luxembourg.
> DE - 329, 8206 MiB/s
> 

¹Phew, a heck of a lot of relays on PONYNET
https://metrics.torproject.org/rs.html#search/as:AS53667

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Tor Relay Meetup #Fosdem Notes

[gus]

Hello,

Last Saturday, a group of 30 - 40 operators joined the Tor Relay
Operator meetup.

Thank you all for joining the event!

Our next online meetup will happen on March 5th, 2000 UTC.

Gus

## Fosdem Meetup Notes

* Bridges campaign update:

"When we started the campaign on November 17, 2021, the Tor network had
approximately 1,200 running bridges. The Tor network now has 2470
running bridges, i.e., the number of Tor bridges has almost doubled!"
https://blog.torproject.org/wrapping-up-bridges-campaign/

* Gamification project update:
  - Survey Insights for Tor Relay Operators:
https://gitlab.torproject.org/tpo/community/relays/-/issues/31

* EOL 0.3.5 removal:

"Tor 0.3.5.x is unsupported beginning tomorrow, 02/01/2022. We should
contact the relay operators still on it where possible to get them
upgraded and then after a couple of weeks (4 maybe) remove the remaining
relays from the network (see: #56 (closed) for previous work in that
area)."

https://gitlab.torproject.org/tpo/network-health/team/-/issues/171

* New texas relay operator group? are there others? CCCS?

"We are just a small provider trying to help out the community. We
believe that privacy is a fundamental right for everyone. We hope to
make the internet a better place by deploying privacy based tools for
everyone to use.Checkout stormycloud.org for additional information."

* torservers.net reanimation continues. New website (feedback welcome)
is online: https://torservers.net/
Thanks Leibi, qbi and others for the work!

### Q session

  * Who runs Tor relays today? Do we need more transparency? (no mic)
 * Yes, we need more transparency. Gus describes a proposed "community 
mapping" exercise where we learn who has links / connections to other relays.

  * Best providers for exit nodes?
  * For exits, I can recommend terrahost.no They are based in Norway, have 
unmetered offers and allow exits with a reduced policy in their Terms of Service
  * See: 
https://community.torproject.org/relay/community-resources/good-bad-isps/
  * Would recommend avoiding hetzner, ovh, frantech, buyvm, there are too 
many relays there already.

  * Are there any plans for AS-aware tor circuit creation? (Kristian - 
lokodlare)

Not currently -- the AS-aware Tor designs (like Raptor and following)
are cool but have a bunch of big open questions and unresolved potential
vulnerabilities too. So, a great research area, but comes with too many
security tradeoffs currently. For a cool recent attack paper in the
area, check out: https://www.freehaven.net/anonbib/#tempest-pets2018

  * Are there plans on improving tor prometheus metrics? (more metrics: uptime, 
bandwidth, ...)

It turns out the DNS metrics we had were buggy and not so useful. So
there is some work to improve the accuracy / usefulness of the current
metrics.
https://gitlab.torproject.org/tpo/network-health/team/-/issues/175

  * is C tor dead in terms of new features like this? (all dev capacity goes 
into rust only?)

C tor is going to be deprecated over time, but the Arti roadmap involves
not getting to relays for years, so there will be an interim period
where we're wishing we could deprecate the C-Tor relay side yet there is
no Arti relay side replacement yet.

  * will arti implement the control spec (compatibility with stem)

no, at least not as it currently is. arti wants to be a library you can link in

  * Is the GeoIP location implementation for relays based on ASNs or
actual country-based IP blocks. One relay operator's server is located
in Japan but the AS seems to be American so the location is listed as
the US.

We switched from Maxmind GeoIP to IPFire in the past year.

  * Are there instructions for how people can report bugs to IPFire?

Yes, look at 
https://forum.torproject.net/t/tor-relay-search-showing-location-of-some-relays-incorrectly/1331
We had an example where a relay operator requested a change from IPFire, and it 
seems to have gone surprisingly smoothly and easily.

  * MCH:
There will be a real in-person hacker con this summer, MCH
https://mch2022.org/, with at least one Tor relay operator known
attending and at least one Tor developer known attending.

  * Is running a Snowflake proxy as useful as a (obfs4) bridge?

If you have a static IP address, maybe the obfs4 bridge is smarter?
Since the Snowflake model involves having many transient proxies.

  * Are there timelines for IPv6 only Tor or Bridge families?

tor 0.4.8.x will get MyFamily support for bridges according to Nick (C tor)
https://gitweb.torproject.org/torspec.git/tree/proposals/321-happy-families.md

  * Would it be a good idea to run a web-server on the same computer as a tor 
bridge?

Because it would introduce collateral damage? Maybe yes in theory, but
in practice these days no. Russia and China block bridges by IP address
in a quite automated way and they don't seem to care what else is on
that computer. Mostly these censors find bridges not by looking at
network traffic, but by 

Re: [tor-relays] Tor relay struggling with circuit creation (CPU Limit)

[lists]

On Thursday, January 6, 2022 10:24:27 AM CET GANDI24325_TOR via tor-relays 
wrote:

> Do I need to change my torrc to fix this error
yes hints for this in the log

> Warning messages:
> 09:10:10 [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.

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Tor relay struggling with circuit creation (CPU Limit)

[GANDI24325_TOR via tor-relays]

Hi Tor relay community,

I have recently made a new tor relay, and all is going well however I use NYX 
to mointor it and over the last day it has been giving the warning message seen 
below in the nyx mointor, the relay had been running fine for it's first 4 days 
of life but now shows this message for nealry 30 hours now (scrolling through 
logs)

Also the nyx mointor shows a CPU usage of 80-90% so I know this is the limiting 
factor and have no issue with it as this server is just free VPS that I am 
donating so ideally would like it to pump out as much data in/out as possible, 
but my question is,

Do I need to change my torrc to fix this error or will the tor network realize 
overtime how much traffic is best for this node?

Useful information:
https://metrics.torproject.org/rs.html#details/448E2528A4AC58A7531EC950AAF0F4A083C7E627:
 GANDI24325second the relay in quesiton, with this website showing everything 
as fine

Family:
https://metrics.torproject.org/rs.html#search/family:BC77562EF192F0A580F54D1A5182EC6EC4B3899F:
 the other two relays are working fine

Contact info:
GANDI24325_TOR [at] protonmail (dot) com

Addtional info:
If I haven't provided enough infomation/if you want the torrc I can help
Thanks in advance for any help

Warning messages:
09:10:10 [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.
│ [2012 similar message(s) suppressed in last 120 seconds]
│ 09:09:09 [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.
│ [1467 similar message(s) suppressed in last 60 seconds]
│ 09:08:08 [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.
│ [628 similar message(s) suppressed in last 60 seconds]
│ 09:07:08 [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.
│ [518 similar message(s) suppressed in last 120 seconds]
│ 09:05:57 [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.
│ [10092 similar message(s) suppressed in last 2820 seconds]
│ 08:19:05 [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.
│ [13039 similar message(s) suppressed in last 120 seconds]
│ 08:18:04 [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.
│ [11034 similar message(s) suppressed in last 60 seconds]
│ 08:17:04 [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.
─┘ [7335 similar message(s) suppressed in last 60 seconds]___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Tor Relay Operators Survey - Gamification Project - Miko

[Sukeshani Tayade]

*Hello Tor Relay Operators!*

My name is Miko and I am an intern via Outreachy.org. I am working on a
project to understand Tor Relay Operators and incentivise your relay
running experience.

You can read more about this project here:
https://gitlab.torproject.org/tpo/community/relays/-/issues/26

https://gitlab.torproject.org/tpo/community/relays/-/issues/27

We appreciate your contribution to the Tor Network and want to make your
relay running experience better. We would like to hear from you directly.

*Please answer the survey below* and be as detailed as you'd like. We're
looking forward to your responses! They will be instrumental in directing
our mission to serve you better.

*SURVEY:*

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

Re: [tor-relays] tor relay + sslh

[tor-relay]

Hi, if you run sslh on small vps you should use sslh-select which has
less overhead when many connections are handled.

see https://www.rutschle.net/tech/sslh/README.html

Am 12.06.21 um 10:26 schrieb Casper:
> Hello,
> 
> I recently discovered an SSL multiplexer called "sslh":
> 
> """
> sslh accepts connections on specified ports, and forwards them further
> based on tests performed on the first data packet sent by the remote
> client.
> 
> Probes for HTTP, SSL, SSH, OpenVPN, tinc, XMPP are implemented, and
> any other protocol that can be tested using a regular expression, can
> be recognized. A typical use case is to allow serving several services
> on port 443 (e.g. to connect to ssh from inside a corporate firewall,
> which almost never block port 443) while still serving HTTPS on that port.
> 
> Hence sslh acts as a protocol multiplexer, or a switchboard. Its name
> comes from its original function to serve SSH and HTTPS on the same port.
> """
> 
> Since many of my network services claims to listen on 433 (to bypass
> mobile network limitations), I'm thinking to configure and deploy
> sslh on large scale.
> 
> If tor handshake can be handled by sslh, could the process (of the tor
> relay) be listening on 127.0.0.1:12345 and publish good relay
> descriptor as well ?
> 
> Currently, in my relay config, I have the following:
> 
> """
> ORPort 26719
> ORPort [{{ ansible_default_ipv6.address }}]:26719
> DirPort 26720
> 
> and
> 
> Address 
> """
> 
> Tor will accept to be listening on the localhost interface only?
> 
> """
> ORPort 127.0.0.1:26719
> Address 
> """
> 
> Best regards,
> 
> 
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] tor relay + sslh

[Peter Gerber]

Casper> sslh accepts connections on specified ports, and forwards them
further
> based on tests performed on the first data packet sent by the remote
> client.

Interesting, never heard of sslh but I've heard of people using Nginx
for this [1].

> If tor handshake can be handled by sslh, could the process (of the tor
> relay) be listening on 127.0.0.1:12345 and publish good relay
> descriptor as well ?


Have a look at the NoAdvertise and NoListen flags of ORPort [2]:

ORPort 127.0.0.1:12345 NoAdvertise
ORPort 1.1.1.1:443 NoListen

[1]:
https://www.nginx.com/blog/running-non-ssl-protocols-over-ssl-port-nginx-1-15-2/
[2]: https://2019.www.torproject.org/docs/tor-manual.html.en#ORPort
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] tor relay + sslh

[Casper]

Hello,

I recently discovered an SSL multiplexer called "sslh":

"""
sslh accepts connections on specified ports, and forwards them further
based on tests performed on the first data packet sent by the remote
client.

Probes for HTTP, SSL, SSH, OpenVPN, tinc, XMPP are implemented, and
any other protocol that can be tested using a regular expression, can
be recognized. A typical use case is to allow serving several services
on port 443 (e.g. to connect to ssh from inside a corporate firewall,
which almost never block port 443) while still serving HTTPS on that port.

Hence sslh acts as a protocol multiplexer, or a switchboard. Its name
comes from its original function to serve SSH and HTTPS on the same port.
"""

Since many of my network services claims to listen on 433 (to bypass
mobile network limitations), I'm thinking to configure and deploy
sslh on large scale.

If tor handshake can be handled by sslh, could the process (of the tor
relay) be listening on 127.0.0.1:12345 and publish good relay
descriptor as well ?

Currently, in my relay config, I have the following:

"""
ORPort 26719
ORPort [{{ ansible_default_ipv6.address }}]:26719
DirPort 26720

and

Address 
"""

Tor will accept to be listening on the localhost interface only?

"""
ORPort 127.0.0.1:26719
Address 
"""

Best regards,
-- 
GnuPG: AE157E0B29F0BEF2 at keys.openpgp.org
CA Cert: https://dl.casperlefantom.net/pub/ssl/root.der


signature.asc
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] tor relay issue on windows 10

[Matt Traudt]

On 4/8/21 17:36, Keifer Bly wrote:
> Is there a tor
> command to generate the geoip files? Thanks very much. 
> 

No.

Assuming you are using the Windows Expert Bundle[0], the GeoIP files are
Data/Tor/geoip and Data/Tor/geoip6 in the .zip.

Even if you're not using the expert bundle, that's a way to get the files.

Matt

[0]: https://www.torproject.org/download/tor/
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] tor relay issue on windows 10

[Keifer Bly]

Thanks will try. I know the tor process is not running as it never writes
anything to the log file well over 30 minutes later. I tried checking if
the tor process is running via cmd it is not. Is there a tor command to
generate the geoip files? Thanks very much.

On Thu, Apr 8, 2021, 5:17 AM Matt Traudt  wrote:

> On 4/7/21 23:15, Keifer Bly wrote:
> > Hi all,
> >
> > So I am attempting to start a new relay on Windows Server 2019. The
> > issue is though for an unspecified reason, the tor process just quits
> > when starting the relay:
> >
> > Here is the log file:
> >
> > image.png
> >
> > And then once  it gets to "now checking if qr port is reachable from the
> > outside" the tor process suddenly quits. Im running it as administrator
> > I am wondering why the process would suddenly stop for no apparent
> > reason on reaching this? Here is the torrc, though it seems to read that
> > no issue:
> >
> > SocksPort 0
> > ORPort 4555
> > Nickname testrelay
> > ContactInfo k...@gmail.com 
> > Log notice file c:\notices.log
> > ControlPort 9051
> > ExitPolicy reject *:*
> >
> > Though it seems to read the torrc file without any issue. Thanks.
> > --Keifer
> >
>
> Hi
>
> I'm not a windows user, and especially not a
> run-things-as-a-service-on-windows user.
>
> My first thought was you somehow unknowingly had RunAsDaemon set to 1.
> But after reading the man page[0] and checking your command line in the
> picture, I don't think this is it.
>
> But in the same spirit of the above: are you *sure* tor isn't
> successfully running in the background? You could check by seeing if
> anything is listening on its ORPort, by checking if the log file is
> getting newer lines than the console, and by the process explorer or
> whatever. (Aside: consider adding a "Log notice stdout" for debugging)
>
> What's the DataDirectory that Tor is trying to use? Maybe it's unable to
> create it and failing silently? I think silent failure would be
> considered a bug. Maybe set DataDirectory in the torrc.
>
> Finally, the last thing that stood out to me is the GeoIP lines in the
> log output. I've never seen "" and I'm guessing
> C:\Users\Administrator\ doesn't exist. Perhaps there's a bad
> bug where Tor crashes (silently?) if the GeoIP files don't exist. It
> would be crazy if that existed, IMO, but maybe less crazy if it's a bug
> on Windows systems only. Running little-t tor manually--as a client or
> even as a relay--is much less common on Windows. The thing to try here
> is to specify GeoIPFile and GeoIPv6File in the torrc with the paths to
> the GeoIP files tor ships with (don't try getting a random database off
> the Internet: tor has its own format).
>
> Hope something here was helpful.
>
> Matt
>
> [0]:
>
>RunAsDaemon 0|1
>If 1, Tor forks and daemonizes to the
>background. This option has no effect on
>Windows; instead you should use the
>--service command-line option. Can not
>be changed while tor is running.
>(Default: 0)
>
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] tor relay issue on windows 10

[Matt Traudt]

On 4/7/21 23:15, Keifer Bly wrote:
> Hi all,
> 
> So I am attempting to start a new relay on Windows Server 2019. The
> issue is though for an unspecified reason, the tor process just quits
> when starting the relay:
> 
> Here is the log file:
> 
> image.png
> 
> And then once  it gets to "now checking if qr port is reachable from the
> outside" the tor process suddenly quits. Im running it as administrator
> I am wondering why the process would suddenly stop for no apparent
> reason on reaching this? Here is the torrc, though it seems to read that
> no issue:
> 
> SocksPort 0
> ORPort 4555
> Nickname testrelay
> ContactInfo k...@gmail.com 
> Log notice file c:\notices.log
> ControlPort 9051
> ExitPolicy reject *:*
> 
> Though it seems to read the torrc file without any issue. Thanks.
> --Keifer
> 

Hi

I'm not a windows user, and especially not a
run-things-as-a-service-on-windows user.

My first thought was you somehow unknowingly had RunAsDaemon set to 1.
But after reading the man page[0] and checking your command line in the
picture, I don't think this is it.

But in the same spirit of the above: are you *sure* tor isn't
successfully running in the background? You could check by seeing if
anything is listening on its ORPort, by checking if the log file is
getting newer lines than the console, and by the process explorer or
whatever. (Aside: consider adding a "Log notice stdout" for debugging)

What's the DataDirectory that Tor is trying to use? Maybe it's unable to
create it and failing silently? I think silent failure would be
considered a bug. Maybe set DataDirectory in the torrc.

Finally, the last thing that stood out to me is the GeoIP lines in the
log output. I've never seen "" and I'm guessing
C:\Users\Administrator\ doesn't exist. Perhaps there's a bad
bug where Tor crashes (silently?) if the GeoIP files don't exist. It
would be crazy if that existed, IMO, but maybe less crazy if it's a bug
on Windows systems only. Running little-t tor manually--as a client or
even as a relay--is much less common on Windows. The thing to try here
is to specify GeoIPFile and GeoIPv6File in the torrc with the paths to
the GeoIP files tor ships with (don't try getting a random database off
the Internet: tor has its own format).

Hope something here was helpful.

Matt

[0]:

   RunAsDaemon 0|1
   If 1, Tor forks and daemonizes to the
   background. This option has no effect on
   Windows; instead you should use the
   --service command-line option. Can not
   be changed while tor is running.
   (Default: 0)

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

Re: [tor-relays] Tor relay failed to start after upgrade (0.4.4.6 --> 0.4.5.5) [solved]

[David Goulet]

On 09 Feb (11:55:12), tscha...@posteo.de wrote:
> Tonight my Tor relay on Raspberry Pi (buster) was upgraded from
> 0.4.4.6-1~bpo10+1 to 0.4.5.5-rc-1~bpo10+1 automaticly, but failed to start:
> 
> ---
> [notice] Opening OR listener on 0.0.0.0:587
> [notice] Opened OR listener connection (ready) on 0.0.0.0:587
> [notice] Opening OR listener on [::]:587
> [warn] Socket creation failed: Address family not supported by protocol
> [notice] Opening Directory listener on 0.0.0.0:995
> [notice] Closing partially-constructed OR listener connection (ready) on
> 0.0.0.0:587
> [notice] Closing partially-constructed Directory listener connection (ready)
> on 0.0.0.0:995
> ---
> 
> Until then there was no change in my torrc:
> 
>   ORPort 587
>   DIRPORT 995

Oh wow, interesting, so your Pi doesn't support IPv6 for some reasons and it
failed to start with this config.

I have opened: https://gitlab.torproject.org/tpo/core/tor/-/issues/40283

In 0.4.5.x tor, things have changed where tor will try to auto discover an
IPv6 and automatically bind to it if only "ORPort " is used.

In other words, it now binds to 0.0.0.0 and [::] by default. It then publish
any discovered _usable_ and _reachable_ IPv4/IPv6. If it doesn't find any
IPv6, it will still listen but won't publish any IPv6.

> 
> It seems the value [address:] is no longer optional if you're not IPv6 ready
> [1]:
> 
>   ORPort [address:]PORT|auto [flags]
>   DirPort [address:]PORT|auto [flags]
> 
> So I have to change my torrc to:
> 
>   ORPort 0.0.0.0:587
>   DIRPORT 0.0.0.0:995

Another option would have been to add the "IPv4Only" flag to the ORPort line
and should have done it for you.

Cheers!
David

-- 
YrY9JHvSOJpDfyKS5AyL8h/BjZ/SQEkh00q9ek+1BXk=


signature.asc
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] Tor relay marked "false positive" from NCSC-FI

[Peter Gerber]

Hi

tscha...@posteo.de:
> today my ISP received an abuse report from
> ncsc-fi-autorepor...@traficom.fi [1]:
> ---
> The information below is presented in the following format:
> ASN | IP | TIMESTAMP (UTC) | PTR/DNAME | CC | TYPE | CASE | INFO
> 
> 24940|95.217.16.212|2020-09-01 07:27:48
> +|95.217.16.212|DE|malweb|1130659|Datasource: b, Url:
> hxxp://95.217.16.212/tor/server/fp/23ad6b165137d957c09aa0f7a3ee7b05cec4a8f2,
> Http Request: GET, Additional Information: This host is most likely
> serving a malware URL., Artifact Hash: 69b9e2721018f0ebaebf901d98d8c9b9
> ---
> The ip belongs to my non-exit relay. [2] There is no action required for
> me, but I wonder why they mark traffic on the dirport as 'malware'?

I've received a similar mail not too long ago. Looking into it, I
couldn't but conclude that it was some sort of phishing scam. When
following the link one was asked to provide a lot of information. The
webpage seems to be outdated, incomplete and nowhere was explained why
they'd scan the internet for anything. All in all, the page looked as
"phishy" as it gets.

For reference, below is the abuse mail I received.

Regards

Peter

 Forwarded Message 
Subject: Fwd: Abuse Message [AbuseID:730BD4:2C]: AbuseCleanMXInfo:
[clean-mx-viruses-172313691](95.216.14.206)-->(ab...@hetzner.de) viruses
sites (1 so far) within your network, please close them! status: As of
2020-08-09 16:47:16 CEST
Date: Sun, 09 Aug 2020 16:48:21 +0200
From: ab...@hetzner.com
Reply-To: ab...@hetzner.com
To: 

Dear Mr Peter Gerber,

For your information we are forwarding you the email of the ticket
[AbuseID:730BD4:2C]. The source email with details about the issue is
attached to this email.

Important note:
When replying to us, please leave the abuse ID [AbuseID:730BD4:2C]
unchanged in the subject line.

Kind regards

Abuse department

Hetzner Online GmbH
Industriestr. 25
91710 Gunzenhausen / Germany
Tel: +49 9831 505-0
Fax: +49 9831 505-3
ab...@hetzner.com
www.hetzner.com

Register Court: Registergericht Ansbach, HRB 6089
CEO: Martin Hetzner, Stephan Konvickova, Günther Müller

For the purposes of this communication, we may save some
of your personal data. For information on our data privacy
policy, please see: www.hetzner.com/datenschutzhinweis

On 09 Aug 16:47, ab...@clean-mx.de wrote:
> Dear abuse team,
>
> please have a look on these perhaps offending viruses sites(1) so far.
>
> Notice: We do NOT urge you to shutdown your customer, but to inform
him about a possible infection/misbehavior !
>
> status: As of 2020-08-09 16:47:16 CEST
>
> Please preserve on any reply our Subject:
[clean-mx-viruses-172313691](95.216.14.206)-->(ab...@hetzner.de) viruses
sites (1  so far) within your network, please close them!  status: As of
2020-08-09 16:47:16 CEST
>
>
>
http://support.clean-mx.de/clean-mx/viruses.php?email=ab...@hetzner.de=alive
>
> (for full uri, please scroll to the right end ...
>
> This information has been generated out of our comprehensive real time
database, tracking worldwide viruses URI's
>
> If your review this list of offending site(s), please do this
carefully, pay attention for redirects also!
> Also, please consider this particular machines may have a root kit
installed !
> So simply deleting some files or dirs or disabling cgi may not really
solve the issue !
>
> Advice: The appearance of a Virus Site on a server means that
> someone intruded into the system. The server's owner should
> disconnect and not return the system into service until an
> audit is performed to ensure no data was lost, that all OS and
> internet software is up to date with the latest security fixes,
> and that any backdoors and other exploits left by the intruders
> are closed. Logs should be preserved and analyzed and, perhaps,
> the appropriate law enforcement agencies notified.
>
> DO NOT JUST DELETE THE FILES. IF YOU DO NOT FIX THE SECURITY
> PROBLEM, THEY WILL BE BACK!
>
> You may forward my information to law enforcement, CERTs,
> other responsible admins, or similar agencies.
>
>
+---
>
> |date |id |virusname  |ip |domain 
> |Url|
>
+---
> |2020-08-09 16:05:31 CEST |172313691  
> |PUA.Win.Trojan.Generic-6629274-0
|95.216.14.206  |95.216.14.206
|http://95.216.14.206/tor/status-vote/current/consensus-microdesc/0232af+14c131+23d15d+27102b+49015f+d586d1+e8a9c4+ed03bb+efcbe7.z
>
+---
>
>
> Your email address has been pulled out of whois concerning this
offending network block(s).
> If you are not concerned with anti-fraud measurements, please forward
this mail to the next responsible desk available...
>
>
> If you just close(d) these incident(s) please give us a feedback, our
automatic walker 

Re: [tor-relays] tor relay - vps maintenance - what to do ?

[William Kane]

Depends on your disk encryption software - VeraCrypt on Windows
supports encrypting sensitive data (including keys) in RAM.

2020-07-13 11:10 GMT, fl4co :
>
>
>> Il giorno 13 lug 2020, alle ore 08:44, Roman Mamedov  ha
>> scritto:
>>
>> On Sun, 12 Jul 2020 21:12:31 +
>> dluga...@protonmail.com wrote:
>>
>> The only way to protect from that, is to set up Full-disk encryption (FDE)
>> on
>> the VPS beforehand. But even then, it is challenging to make sure the
>> decryption key is not leaked to the provider (e.g. when entering it via
>> their
>> "VNC Console", which can be keylogged).
>>
>> If you do not set up FDE, you should assume all your data on any VPS is
>> accessible to the provider. Even RAM of a VPS can be copied without
>> stopping
>> it, so running Tor in a RAM disk (tmpfs) is not an answer either.
>
> I think that even with full-disk encryption, the decryption key can be
> obtained from RAM. Is that correct?
>
> A VPS is probably not a good choice if privacy is mission critical.
>
> —
> fl4co
>
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] tor relay - vps maintenance - what to do ?

[fl4co]

> Il giorno 13 lug 2020, alle ore 08:44, Roman Mamedov  ha 
> scritto:
> 
> On Sun, 12 Jul 2020 21:12:31 +
> dluga...@protonmail.com wrote:
> 
> The only way to protect from that, is to set up Full-disk encryption (FDE) on
> the VPS beforehand. But even then, it is challenging to make sure the
> decryption key is not leaked to the provider (e.g. when entering it via their
> "VNC Console", which can be keylogged).
> 
> If you do not set up FDE, you should assume all your data on any VPS is
> accessible to the provider. Even RAM of a VPS can be copied without stopping
> it, so running Tor in a RAM disk (tmpfs) is not an answer either.

I think that even with full-disk encryption, the decryption key can be obtained 
from RAM. Is that correct?

A VPS is probably not a good choice if privacy is mission critical.

—
fl4co

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

Re: [tor-relays] tor relay - vps maintenance - what to do ?

[Toralf Förster]

On 7/12/20 11:12 PM, dluga...@protonmail.com wrote:
> What should I do ?

Consider to use offline keys - it is a good idea always.


-- 
Toralf



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] tor relay - vps maintenance - what to do ?

[Roman Mamedov]

On Sun, 12 Jul 2020 21:12:31 +
dluga...@protonmail.com wrote:

> in the next three days, my VPS provider planning to shutdown 
> ("maintenanance") for 6 hours my VPS where tor relay is running (with some 
> services).
> 
> I suspect that my VPS will be copied and reviewed (by not authorized persons) 
> afterwards.

The provider can copy and examine disks of a running VPS even without shutting
it down. They might get a few filesystem errors, but most likely nothing major
and 99% of data will be there.

The only way to protect from that, is to set up Full-disk encryption (FDE) on
the VPS beforehand. But even then, it is challenging to make sure the
decryption key is not leaked to the provider (e.g. when entering it via their
"VNC Console", which can be keylogged).

If you do not set up FDE, you should assume all your data on any VPS is
accessible to the provider. Even RAM of a VPS can be copied without stopping
it, so running Tor in a RAM disk (tmpfs) is not an answer either.

For more privacy get a dedicated server rather than a VPS. At least a server
actually must be shut down to mess with its disks, and RAM is basically out of
reach. (I believe wiretapping SATA, let alone DDR, can be ruled out as
purely theoretical, in most cases :)

Make sure that backdoors such as Intel AMT are not active though, or get a
non-Intel server.

> What should I do ?

Do not get overly paranoid, most likely it's just a maintenance and has
nothing to do with your VPS or with Tor running on it. As said above, if they
wanted your VPS' contents, they can freely get it at any time without
attracting attention.

If it was a dedicated server, then yes, a cause for concern, as it's a plenty
of time to detach your disk and copy it. For a VPS, none of that downtime is
even needed for that in the first place.

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

Re: [tor-relays] tor relay - vps maintenance - what to do ?

[Roger Dingledine]

On Sun, Jul 12, 2020 at 09:12:31PM +, dluga...@protonmail.com wrote:
> in the next three days, my VPS provider planning to shutdown 
> ("maintenanance") for 6 hours my VPS where tor relay is running (with some 
> services). What should I do ?
> 
> I suspect that my VPS will be copied and reviewed (by not authorized persons) 
> afterwards. How do You react in such a situations ?
> 
> I appreciate any advice.

The conservative choice would be to remove all the key material (that is,
delete the files in your DataDirectory/keys/ directory) before it shuts
down, and then start a fresh relay (with fresh keys) when it comes back.

It really comes down to how much you think they will mess with it (or
maybe even, why you think they've picked your VPS for maintenance at all).

Leaving it alone and not stressing about it, or rotating to fresh keys,
are both valid approaches. It depends how you want to approach it.

Hope that helps,
--Roger

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

[tor-relays] tor relay - vps maintenance - what to do ?

[dlugasny]

Hi,

in the next three days, my VPS provider planning to shutdown ("maintenanance") 
for 6 hours my VPS where tor relay is running (with some services). What should 
I do ?

I suspect that my VPS will be copied and reviewed (by not authorized persons) 
afterwards. How do You react in such a situations ?

I appreciate any advice.

Cheers
Dlugasny

Sent with [ProtonMail](https://protonmail.com) Secure Email.___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor Relay Web Ports

[William Kane]

German laws are different from Austrian laws.

I quickly skimmed the German article and the defendant had made
less-than-optimal statements in court, like "I don't care if my nodes
are being used to distribute child-pornography." and "I actually
recommend the Tor Network in chats for hosting of child pornography".

No wonder he got sentenced, he also _did not_ have a lawyer.

If you are not a, sorry for the foul language but it's true, dumb-ass
like him, and have a competent lawyer familiar with the Tor network
and the laws protecting network operators, your chances of being
sentenced are slim to none, depending on the country you operate your
relays in, and your personal jurisdiction.

2020-05-23 17:15 GMT, Sebastian Elisa Pfeifer :
> You know that, I know that, the police probably also knows that. And I
> never said it was not legal.
>
> But also, it could be that that won't help you and you still get
> convicted like the guy from Graz in the link..
>
> Sebastian
>
> On 22/05/2020 23:28, William Kane wrote:
>> They can raid my home(s), it won't make it any less legal to operate
>> an exit node, for it's traffic I am still not responsible.
>>
>> I've had run-ins with the law regarding exit nodes in the past, and
>> all the cases against me got dropped due to not being liable for the
>> traffic I have not initiated. Any good lawyer will know this.
>>
>> I also recommend the EFF pages on the topic.
>>
>> 2020-05-21 21:49 GMT, Sebastian Elisa Pfeifer
>> :
>>> On 20/05/2020 23:07, William Kane wrote:
 After that is all done, you can safely ignore most abuse reports
 unless they actually have a case against you, which, in most countries
 is not possible due to network providers being protected from
 liability by the law.
>>> But everyone should be aware that that might not stop the law
>>> enforcement from raiding your home. Or even worse:
>>> https://www.heise.de/newsticker/meldung/Oesterreich-Tor-Serverbetreiber-wegen-Beihilfe-zur-Kinderporno-Verbreitung-verurteilt-2249228.html
>>> (Sorry, German)
>>>
>>> And, keep in mind, in countries without a
>>> "Beweismittelverwertungsverbot" (like Austria and I think Germany also)
>>> it doesn't matter if the search was illegal - they can still use
>>> everything they found against you.
>>>
>>> Don't get me wrong, it's great you want to run an exit and I also did so
>>> in the past, but be careful.
>>>
>>> Sebastian
>>> ___
>>> tor-relays mailing list
>>> tor-relays@lists.torproject.org
>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>>
>> ___
>> tor-relays mailing list
>> tor-relays@lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor Relay Web Ports

[Sebastian Elisa Pfeifer]

You know that, I know that, the police probably also knows that. And I
never said it was not legal.

But also, it could be that that won't help you and you still get
convicted like the guy from Graz in the link..

Sebastian

On 22/05/2020 23:28, William Kane wrote:
> They can raid my home(s), it won't make it any less legal to operate
> an exit node, for it's traffic I am still not responsible.
> 
> I've had run-ins with the law regarding exit nodes in the past, and
> all the cases against me got dropped due to not being liable for the
> traffic I have not initiated. Any good lawyer will know this.
> 
> I also recommend the EFF pages on the topic.
> 
> 2020-05-21 21:49 GMT, Sebastian Elisa Pfeifer :
>> On 20/05/2020 23:07, William Kane wrote:
>>> After that is all done, you can safely ignore most abuse reports
>>> unless they actually have a case against you, which, in most countries
>>> is not possible due to network providers being protected from
>>> liability by the law.
>> But everyone should be aware that that might not stop the law
>> enforcement from raiding your home. Or even worse:
>> https://www.heise.de/newsticker/meldung/Oesterreich-Tor-Serverbetreiber-wegen-Beihilfe-zur-Kinderporno-Verbreitung-verurteilt-2249228.html
>> (Sorry, German)
>>
>> And, keep in mind, in countries without a
>> "Beweismittelverwertungsverbot" (like Austria and I think Germany also)
>> it doesn't matter if the search was illegal - they can still use
>> everything they found against you.
>>
>> Don't get me wrong, it's great you want to run an exit and I also did so
>> in the past, but be careful.
>>
>> Sebastian
>> ___
>> 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] Tor Relay Web Ports

[William Kane]

They can raid my home(s), it won't make it any less legal to operate
an exit node, for it's traffic I am still not responsible.

I've had run-ins with the law regarding exit nodes in the past, and
all the cases against me got dropped due to not being liable for the
traffic I have not initiated. Any good lawyer will know this.

I also recommend the EFF pages on the topic.

2020-05-21 21:49 GMT, Sebastian Elisa Pfeifer :
> On 20/05/2020 23:07, William Kane wrote:
>> After that is all done, you can safely ignore most abuse reports
>> unless they actually have a case against you, which, in most countries
>> is not possible due to network providers being protected from
>> liability by the law.
> But everyone should be aware that that might not stop the law
> enforcement from raiding your home. Or even worse:
> https://www.heise.de/newsticker/meldung/Oesterreich-Tor-Serverbetreiber-wegen-Beihilfe-zur-Kinderporno-Verbreitung-verurteilt-2249228.html
> (Sorry, German)
>
> And, keep in mind, in countries without a
> "Beweismittelverwertungsverbot" (like Austria and I think Germany also)
> it doesn't matter if the search was illegal - they can still use
> everything they found against you.
>
> Don't get me wrong, it's great you want to run an exit and I also did so
> in the past, but be careful.
>
> Sebastian
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor Relay Web Ports

[mnlph74]

Thanks for the links and reply, I appreciate it, that answers my question on 
web ports. How about Bitcoin ports 8333 to help other BTC nodes sync? Is this 
port also risky to open? Thanks again...



Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Thursday, May 21, 2020 5:21 AM, William Kane  wrote:

> P.S: If you were not asking about relays on OVH, my bad - had their
> company name stuck in my head due to your previous posts to the
> mailing list.
> 

> 2020-05-20 21:07 GMT, William Kane ttall...@googlemail.com:
> 

> > Port 53 over TCP (DNS) seems useless, it won't be used at all or only
> > very rarely - your exit already resolves domain names for your
> > clients, this is why it's recommended to have a local recursive
> > resolver installed instead of passing on DNS requests to remote
> > services such as Google or Cloudflare DNS, due to the possibility of
> > correlation and anonymity compromising attacks:
> > https://medium.com/@nusenu/who-controls-tors-dns-traffic-a74a7632e8ca
> > https://medium.com/@nusenu/what-fraction-of-tors-dns-traffic-goes-to-google-and-cloudflare-492229ccfd42
> > If you open up 80 and 443, expect to receive a lot of abuse mails
> > related to brute-forcing or exploit attempts, and having to deal with
> > the occasional douche-bag downloading child porn from a clear-net
> > hoster and confused law enforcement agencies.
> > If that doesn't bother you or your hoster (in the case of OVH, it
> > will, I can guarantee you that), then go ahead.
> > OVH is a bad provider though, over-congested network due to all the
> > seed boxes, bad peering, many Tor nodes already hosted there, etc.
> > All that means please don't host another node there, instead go for a
> > small provider, ideally also in a country which does not host a lot of
> > Tor nodes already, see if they host only a handful of Tor nodes,
> > ideally colocate, get your own IP range and ask them to modify the
> > abuse address for the range to an address you control.
> > After that is all done, you can safely ignore most abuse reports
> > unless they actually have a case against you, which, in most countries
> > is not possible due to network providers being protected from
> > liability by the law.
> > Hope this helps.
> > 2020-05-20 7:24 GMT, mnlph74 mnlp...@protonmail.com:
> > 

> > > Hi, I'm running a non-exit relay for quite some time now and I would like
> > > to
> > > open ports 53, 80, 443 (web ports) to be more useful.
> > > How do you handle fraudulent complaints? What is the best approach to
> > > this
> > > situation? Thank you for your help.
> > > Sent with ProtonMail Secure Email.
> 

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



publickey - mnlph74@protonmail.com - 0xA7D18794.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] Tor Relay Web Ports

[Sebastian Elisa Pfeifer]

On 20/05/2020 23:07, William Kane wrote:
> After that is all done, you can safely ignore most abuse reports
> unless they actually have a case against you, which, in most countries
> is not possible due to network providers being protected from
> liability by the law.
But everyone should be aware that that might not stop the law
enforcement from raiding your home. Or even worse:
https://www.heise.de/newsticker/meldung/Oesterreich-Tor-Serverbetreiber-wegen-Beihilfe-zur-Kinderporno-Verbreitung-verurteilt-2249228.html
(Sorry, German)

And, keep in mind, in countries without a
"Beweismittelverwertungsverbot" (like Austria and I think Germany also)
it doesn't matter if the search was illegal - they can still use
everything they found against you.

Don't get me wrong, it's great you want to run an exit and I also did so
in the past, but be careful.

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

Re: [tor-relays] Tor Relay Web Ports

[William Kane]

Port 53 over TCP (DNS) seems useless, it won't be used at all or only
very rarely - your exit already resolves domain names for your
clients, this is why it's recommended to have a local recursive
resolver installed instead of passing on DNS requests to remote
services such as Google or Cloudflare DNS, due to the possibility of
correlation and anonymity compromising attacks:

https://medium.com/@nusenu/who-controls-tors-dns-traffic-a74a7632e8ca
https://medium.com/@nusenu/what-fraction-of-tors-dns-traffic-goes-to-google-and-cloudflare-492229ccfd42

If you open up 80 and 443, expect to receive a lot of abuse mails
related to brute-forcing or exploit attempts, and having to deal with
the occasional douche-bag downloading child porn from a clear-net
hoster and confused law enforcement agencies.

If that doesn't bother you or your hoster (in the case of OVH, it
will, I can guarantee you that), then go ahead.

OVH is a bad provider though, over-congested network due to all the
seed boxes, bad peering, many Tor nodes already hosted there, etc.

All that means please don't host another node there, instead go for a
small provider, ideally also in a country which does not host a lot of
Tor nodes already, see if they host only a handful of Tor nodes,
ideally colocate, get your own IP range and ask them to modify the
abuse address for the range to an address you control.

After that is all done, you can safely ignore most abuse reports
unless they actually have a case against you, which, in most countries
is not possible due to network providers being protected from
liability by the law.

Hope this helps.


2020-05-20 7:24 GMT, mnlph74 :
> Hi, I'm running a non-exit relay for quite some time now and I would like to
> open ports 53, 80, 443 (web ports) to be more useful.
> How do you handle fraudulent complaints? What is the best approach to this
> situation? Thank you for your help.
>
> Sent with ProtonMail Secure Email.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor Relay Web Ports

[William Kane]

P.S: If you were not asking about relays on OVH, my bad - had their
company name stuck in my head due to your previous posts to the
mailing list.

2020-05-20 21:07 GMT, William Kane :
> Port 53 over TCP (DNS) seems useless, it won't be used at all or only
> very rarely - your exit already resolves domain names for your
> clients, this is why it's recommended to have a local recursive
> resolver installed instead of passing on DNS requests to remote
> services such as Google or Cloudflare DNS, due to the possibility of
> correlation and anonymity compromising attacks:
>
> https://medium.com/@nusenu/who-controls-tors-dns-traffic-a74a7632e8ca
> https://medium.com/@nusenu/what-fraction-of-tors-dns-traffic-goes-to-google-and-cloudflare-492229ccfd42
>
> If you open up 80 and 443, expect to receive a lot of abuse mails
> related to brute-forcing or exploit attempts, and having to deal with
> the occasional douche-bag downloading child porn from a clear-net
> hoster and confused law enforcement agencies.
>
> If that doesn't bother you or your hoster (in the case of OVH, it
> will, I can guarantee you that), then go ahead.
>
> OVH is a bad provider though, over-congested network due to all the
> seed boxes, bad peering, many Tor nodes already hosted there, etc.
>
> All that means please don't host another node there, instead go for a
> small provider, ideally also in a country which does not host a lot of
> Tor nodes already, see if they host only a handful of Tor nodes,
> ideally colocate, get your own IP range and ask them to modify the
> abuse address for the range to an address you control.
>
> After that is all done, you can safely ignore most abuse reports
> unless they actually have a case against you, which, in most countries
> is not possible due to network providers being protected from
> liability by the law.
>
> Hope this helps.
>
>
> 2020-05-20 7:24 GMT, mnlph74 :
>> Hi, I'm running a non-exit relay for quite some time now and I would like
>> to
>> open ports 53, 80, 443 (web ports) to be more useful.
>> How do you handle fraudulent complaints? What is the best approach to
>> this
>> situation? Thank you for your help.
>>
>> Sent with ProtonMail Secure Email.
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor relay occasionally maxing out CPU usage

[William Kane]

Hi Alexander,

I am a customer of Wedos Internet, and originally ordered this virtual
machine back in 2014, as far as I know no hardware updates to the
hypervisor were ever performed, so it's likely some older Intel Xeon
(clocked at 2133.408MHz), guess with that information you can find the
exact CPU model.

Here's the output from 'lscpu':

Architecture:x86_64
CPU op-mode(s):  32-bit, 64-bit
Byte Order:  Little Endian
Address sizes:   40 bits physical, 48 bits virtual
CPU(s):  1
On-line CPU(s) list: 0
Thread(s) per core:  1
Core(s) per socket:  1
Socket(s):   1
NUMA node(s):1
Vendor ID:   GenuineIntel
CPU family:  6
Model:   13
Model name:  QEMU Virtual CPU version (cpu64-rhel6)
Stepping:3
CPU MHz: 2133.408
BogoMIPS:4268.60
Hypervisor vendor:   KVM
Virtualization type: full
L1d cache:   32 KiB
L1i cache:   32 KiB
L2 cache:4 MiB
NUMA node0 CPU(s):   0
Vulnerability Itlb multihit: KVM: Vulnerable
Vulnerability L1tf:  Mitigation; PTE Inversion
Vulnerability Mds:   Vulnerable; SMT Host state unknown
Vulnerability Meltdown:  Vulnerable
Vulnerability Spec store bypass: Vulnerable
Vulnerability Spectre v1:Vulnerable: __user pointer
sanitization and usercopy barriers only; no swapgs barriers
Vulnerability Spectre v2:Vulnerable, STIBP: disabled
Vulnerability Tsx async abort:   Not affected
Flags:   fpu de pse tsc msr pae mce cx8 apic
sep mtrr pge mca cmov pse36 clflush mmx fxsr sse sse2 syscall nx lm
nopl cpuid tsc_known_freq pni cx16 hypervisor lahf_lm

Notice the lack of AES instructions, despite them being supported by
the host cpu - I previously asked them reconfigure their KVM
configuration to set the emulated CPU model to 'host' so I can benefit
from hardware AES-NI acceleration but they refused even though this
would help to reduce CPU load, improve throughput and make headroom
for non-crypto operations (such as the diffing / compression of
consensus documents which hogs my CPU for multiple minutes).

Further specs of the VM:

1024MB of RAM
256MB Swap

Memory wise, no problems at all, the tor process doesn't utilize more
than 600 MB's even under maximum load, and the base system only
utilizes ~60MB so it's not a ram bottleneck.

I thought about re-writing the code responsible for compression to
make it use the least CPU intensive compression level.

If anyone is familiar with the code responsible for it, let me know if
my attempts are going to be futile (I have 10+ years of experience
with C/C++, just not with the Tor code base except for very small
parts of it.)

William

2020-05-20 13:06 GMT, Alexander Færøy :
> On 2020/05/19 15:59, William Kane wrote:
>> Right after, diffs were compressed with zstd and lzma, causing the CPU
>> usage to spike.
>
> Thank you for debugging this William.
>
> Tor behaves in the way it is designed to here. Tor uses a number of
> worker threads to handle compression (and a couple of other tasks), but
> what worries me is how big an impact it has on the traffic processing of
> your relay during the time where your relay is also compressing.
>
> I'm a bit curious what the specs are of your relays here -- especially
> CPU and memory specs?
>
>> Disabling DirCache still gives me the following warning on Tor 0.4.3.5:
>>
>> May 19 17:56:42.909 [warn] DirCache is disabled and we are configured
>> as a relay. We will not become a Guard.
>>
>> So, unless I sacrifice the Guard flag, there doesn't seem to be a way
>> to fix this problem in an easy way.
>
> This is correct for now. Tor have the `NumCPUs` configuration entry,
> which defines how many workers we can spawn, but the default value is
> sensible for most systems and I doubt it makes sense to tune this for
> you.
>
>> Please correct me if I'm wrong.
>
> You're right.
>
> All the best,
> Alex.
>
> --
> Alexander Færøy
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor relay occasionally maxing out CPU usage

[William Kane]

It sure is a problem for those on virtualized machines with only a single core.

As far as offloading to a different worker thread goes, it should be
very easy to implement code wise, Tor already does off-load some
crypto stuff to a different thread when NumCPU's is set / detected
appropriately.

2020-05-20 12:24 GMT, Matt Traudt :
> To me it sounds like there isn't actually a problem. This is the way Tor
> works now (now == since consensus diffs were added). It's unfortunate
> that Tor isn't more multithreaded, so much happens in the same main
> loop, and client throughput is momentarily impacted, but that's the way
> it is and there isn't a problem here to be solved. At least not for you
> the relay operator.
>
> Getting more into tor-dev@ territory here, but doesn't compressing
> consensus documents sound like something that could easily be shoved
> over into a worker thread? I'm unfamiliar with the subsystem and I'm
> sure many of my implicit assumptions are wrong.
>
> Matt
>
> On 5/19/20 11:59, William Kane wrote:
>> Okay, so your suspicion was just confirmed:
>>
>> consdiffmgr_rescan_flavor_(): The most recent ns consensus is
>> valid-after 2020-05-19T15:00:00. We have diffs to this consensus for
>> 0/25 older ns consensuses. Generating diffs for the other 25.
>>
>> Right after, diffs were compressed with zstd and lzma, causing the CPU
>> usage to spike.
>>
>> Disabling DirCache still gives me the following warning on Tor 0.4.3.5:
>>
>> May 19 17:56:42.909 [warn] DirCache is disabled and we are configured
>> as a relay. We will not become a Guard.
>>
>> So, unless I sacrifice the Guard flag, there doesn't seem to be a way
>> to fix this problem in an easy way.
>>
>> Please correct me if I'm wrong.
>>
>>
>> 2020-05-19 15:07 GMT, William Kane :
>>> Another thing, from the change-log:
>>>
>>> - Update the message logged on relays when DirCache is disabled.
>>>   Since 0.3.3.5-rc, authorities require DirCache (V2Dir) for the
>>>   Guard flag. Fixes bug 24312; bugfix on 0.3.3.5-rc.
>>>
>>> If I understand this correctly, my relay would no longer be a Guard if
>>> I choose to disable DirCache in order to prevent Tor from hogging my
>>> CPU?
>>>
>>> From the code that I have seen, simply not setting the directory port
>>> does not stop the relay from caching / compressing diffs.
>>>
>>> Or has this been changed more recently?
>>>
>>> Not being a guard would honestly suck, and being a guard but with
>>> limited bandwidth due to Tor hogging the CPU also sucks.
>>>
>>> Any ideas on what to do?
>>>
>>> 2020-05-19 13:43 GMT, William Kane :
 Dear Alexander,

 I have added 'Log [dirserv]info notice stdout' to my configuration and
 will be monitoring the system closely.

 Tor was also upgraded to version 0.4.3.5, and the linux kernel was
 upgraded to version 5.6.13 but I do not think this will change
 anything.

 Expect a follow-up within the next 12 hours.

 William

 2020-05-18 1:40 GMT, Alexander Færøy :
> Hello,
>
> On 2020/05/17 18:20, William Kane wrote:
>> Occasionally, the CPU usage hit's 100%, and the maximum throughput
>> drops down to around 16 Mbps from it's usual 80 Mbps. This happens
>> randomly and not a fixed intervals which makes it pretty hard to
>> profile.
>
> One of the subsystem's that I can think of that could potentially lead
> to the problem that you are describing is our "consensus diff"
> subsystem. The consensus diff subsystem is responsible for turning
> consensus documents into these patch(1)-like diffs that clients can
> fetch without the need to transfer the whole consensus for each minor
> change.
>
> The subsystem also takes care of compression, which includes LZMA,
> which
> is a beast when it comes to burning CPU cycles.
>
>> No abnormal entries in the log files.
>
> I suspect you're logging at `notice` log-level, which is the reasonable
> thing to do. We need to log at slightly higher granularity to discover
> the problem here.
>
> Could I get you to add `Log [dirserv]info notice syslog` to your
> `torrc`? This line makes Tor log everything at notice log-level (the
> default), to the system logger, except for the directory server
> subsystem, which will be logged at `info` log-level instead. The code
> responsible for generating consensus diffs uses the `dirserv` for
> logging purposes.
>
> If the CPU spike happens right after a log message that says something
> in the line of "The most recent XXX consensus is valid-after XXX. We
> have diffs to this consensus for XXX/XXX older XXX consensuses.
> Generating diffs for the other XXX." then I think we have our winner.
>
> Please remember to remove the `info` log-level when the experiment is
> over :-)
>
> I'm curious what you figure out here. Let me know if you need any help.
>
> All the best,
> Alex.

Re: [tor-relays] Tor Relay Web Ports

[Sebastian Elisa Pfeifer]

Are you running that from home? Then don't. Are you running it from a
datecenter? Ask the ISP if they allow Tor Exits. Then we will see!

On 20/05/2020 09:24, mnlph74 wrote:
> Hi, I'm running a non-exit relay for quite some time now and I would
> like to open ports 53, 80, 443 (web ports) to be more useful.
> How do you handle fraudulent complaints? What is the best approach to
> this situation? Thank you for your help.
>
>
> Sent with ProtonMail  Secure Email.
>
>
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Tor Relay Web Ports

[mnlph74]

Hi, I'm running a non-exit relay for quite some time now and I would like to 
open ports 53, 80, 443 (web ports) to be more useful.
How do you handle fraudulent complaints? What is the best approach to this 
situation? Thank you for your help.

Sent with ProtonMail Secure Email.

publickey - mnlph74@protonmail.com - 0xA7D18794.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] Tor relay occasionally maxing out CPU usage

[Alexander Færøy]

On 2020/05/19 15:59, William Kane wrote:
> Right after, diffs were compressed with zstd and lzma, causing the CPU
> usage to spike.

Thank you for debugging this William.

Tor behaves in the way it is designed to here. Tor uses a number of
worker threads to handle compression (and a couple of other tasks), but
what worries me is how big an impact it has on the traffic processing of
your relay during the time where your relay is also compressing.

I'm a bit curious what the specs are of your relays here -- especially
CPU and memory specs?

> Disabling DirCache still gives me the following warning on Tor 0.4.3.5:
> 
> May 19 17:56:42.909 [warn] DirCache is disabled and we are configured
> as a relay. We will not become a Guard.
> 
> So, unless I sacrifice the Guard flag, there doesn't seem to be a way
> to fix this problem in an easy way.

This is correct for now. Tor have the `NumCPUs` configuration entry,
which defines how many workers we can spawn, but the default value is
sensible for most systems and I doubt it makes sense to tune this for
you.

> Please correct me if I'm wrong.

You're right.

All the best,
Alex.

-- 
Alexander Færøy
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor relay occasionally maxing out CPU usage

[Matt Traudt]

To me it sounds like there isn't actually a problem. This is the way Tor
works now (now == since consensus diffs were added). It's unfortunate
that Tor isn't more multithreaded, so much happens in the same main
loop, and client throughput is momentarily impacted, but that's the way
it is and there isn't a problem here to be solved. At least not for you
the relay operator.

Getting more into tor-dev@ territory here, but doesn't compressing
consensus documents sound like something that could easily be shoved
over into a worker thread? I'm unfamiliar with the subsystem and I'm
sure many of my implicit assumptions are wrong.

Matt

On 5/19/20 11:59, William Kane wrote:
> Okay, so your suspicion was just confirmed:
> 
> consdiffmgr_rescan_flavor_(): The most recent ns consensus is
> valid-after 2020-05-19T15:00:00. We have diffs to this consensus for
> 0/25 older ns consensuses. Generating diffs for the other 25.
> 
> Right after, diffs were compressed with zstd and lzma, causing the CPU
> usage to spike.
> 
> Disabling DirCache still gives me the following warning on Tor 0.4.3.5:
> 
> May 19 17:56:42.909 [warn] DirCache is disabled and we are configured
> as a relay. We will not become a Guard.
> 
> So, unless I sacrifice the Guard flag, there doesn't seem to be a way
> to fix this problem in an easy way.
> 
> Please correct me if I'm wrong.
> 
> 
> 2020-05-19 15:07 GMT, William Kane :
>> Another thing, from the change-log:
>>
>> - Update the message logged on relays when DirCache is disabled.
>>   Since 0.3.3.5-rc, authorities require DirCache (V2Dir) for the
>>   Guard flag. Fixes bug 24312; bugfix on 0.3.3.5-rc.
>>
>> If I understand this correctly, my relay would no longer be a Guard if
>> I choose to disable DirCache in order to prevent Tor from hogging my
>> CPU?
>>
>> From the code that I have seen, simply not setting the directory port
>> does not stop the relay from caching / compressing diffs.
>>
>> Or has this been changed more recently?
>>
>> Not being a guard would honestly suck, and being a guard but with
>> limited bandwidth due to Tor hogging the CPU also sucks.
>>
>> Any ideas on what to do?
>>
>> 2020-05-19 13:43 GMT, William Kane :
>>> Dear Alexander,
>>>
>>> I have added 'Log [dirserv]info notice stdout' to my configuration and
>>> will be monitoring the system closely.
>>>
>>> Tor was also upgraded to version 0.4.3.5, and the linux kernel was
>>> upgraded to version 5.6.13 but I do not think this will change
>>> anything.
>>>
>>> Expect a follow-up within the next 12 hours.
>>>
>>> William
>>>
>>> 2020-05-18 1:40 GMT, Alexander Færøy :
 Hello,

 On 2020/05/17 18:20, William Kane wrote:
> Occasionally, the CPU usage hit's 100%, and the maximum throughput
> drops down to around 16 Mbps from it's usual 80 Mbps. This happens
> randomly and not a fixed intervals which makes it pretty hard to
> profile.

 One of the subsystem's that I can think of that could potentially lead
 to the problem that you are describing is our "consensus diff"
 subsystem. The consensus diff subsystem is responsible for turning
 consensus documents into these patch(1)-like diffs that clients can
 fetch without the need to transfer the whole consensus for each minor
 change.

 The subsystem also takes care of compression, which includes LZMA, which
 is a beast when it comes to burning CPU cycles.

> No abnormal entries in the log files.

 I suspect you're logging at `notice` log-level, which is the reasonable
 thing to do. We need to log at slightly higher granularity to discover
 the problem here.

 Could I get you to add `Log [dirserv]info notice syslog` to your
 `torrc`? This line makes Tor log everything at notice log-level (the
 default), to the system logger, except for the directory server
 subsystem, which will be logged at `info` log-level instead. The code
 responsible for generating consensus diffs uses the `dirserv` for
 logging purposes.

 If the CPU spike happens right after a log message that says something
 in the line of "The most recent XXX consensus is valid-after XXX. We
 have diffs to this consensus for XXX/XXX older XXX consensuses.
 Generating diffs for the other XXX." then I think we have our winner.

 Please remember to remove the `info` log-level when the experiment is
 over :-)

 I'm curious what you figure out here. Let me know if you need any help.

 All the best,
 Alex.

 --
 Alexander Færøy
 ___
 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] Tor relay - hardware upgrade and "Observed bandwidth" not changed

[lilyus]

Hello,

I recently upgraded the hardware of my Tor relay and the "Advertised Bandwith" 
did not change.

https://metrics.torproject.org/rs.html#search/pelote

:9001
> Bandwidth rate: 1024 MiB/s
> Bandwidth burst: 1024 MiB/s
> Observed bandwidth: 5.46 MiB/s

:9101
> Bandwidth rate: 1024 MiB/s
> Bandwidth burst: 1024 MiB/s
> Observed bandwidth: 4.62 MiB/s

My Internet provider allow:
- 1 Gbit/s download
- 600 Mbit/s upload

The relay new hardware is "NUC8i5BEK"
- Intel(R) Core(TM) i5-8259U CPU @ 2.30GHz
- 8GB DDR4 SDRAM PC4-19200
- Samsung SSD 950 PRO 256GB nvme

System:

- OpenBSD 6.7
- tor-0.4.2.7

Relay configuration is done with https://github.com/nusenu/ansible-relayor

No IPv6 (yet).


Do I have to wait for something like "The lifecycle of a new relay" ? 
https://blog.torproject.org/lifecycle-new-relay

Regards,

Lilyus

publickey - lilyus@pm.me - 0xE4C91EA6.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] Tor relay occasionally maxing out CPU usage

[William Kane]

Another thing, from the change-log:

- Update the message logged on relays when DirCache is disabled.
  Since 0.3.3.5-rc, authorities require DirCache (V2Dir) for the
  Guard flag. Fixes bug 24312; bugfix on 0.3.3.5-rc.

If I understand this correctly, my relay would no longer be a Guard if
I choose to disable DirCache in order to prevent Tor from hogging my
CPU?

From the code that I have seen, simply not setting the directory port
does not stop the relay from caching / compressing diffs.

Or has this been changed more recently?

Not being a guard would honestly suck, and being a guard but with
limited bandwidth due to Tor hogging the CPU also sucks.

Any ideas on what to do?

2020-05-19 13:43 GMT, William Kane :
> Dear Alexander,
>
> I have added 'Log [dirserv]info notice stdout' to my configuration and
> will be monitoring the system closely.
>
> Tor was also upgraded to version 0.4.3.5, and the linux kernel was
> upgraded to version 5.6.13 but I do not think this will change
> anything.
>
> Expect a follow-up within the next 12 hours.
>
> William
>
> 2020-05-18 1:40 GMT, Alexander Færøy :
>> Hello,
>>
>> On 2020/05/17 18:20, William Kane wrote:
>>> Occasionally, the CPU usage hit's 100%, and the maximum throughput
>>> drops down to around 16 Mbps from it's usual 80 Mbps. This happens
>>> randomly and not a fixed intervals which makes it pretty hard to
>>> profile.
>>
>> One of the subsystem's that I can think of that could potentially lead
>> to the problem that you are describing is our "consensus diff"
>> subsystem. The consensus diff subsystem is responsible for turning
>> consensus documents into these patch(1)-like diffs that clients can
>> fetch without the need to transfer the whole consensus for each minor
>> change.
>>
>> The subsystem also takes care of compression, which includes LZMA, which
>> is a beast when it comes to burning CPU cycles.
>>
>>> No abnormal entries in the log files.
>>
>> I suspect you're logging at `notice` log-level, which is the reasonable
>> thing to do. We need to log at slightly higher granularity to discover
>> the problem here.
>>
>> Could I get you to add `Log [dirserv]info notice syslog` to your
>> `torrc`? This line makes Tor log everything at notice log-level (the
>> default), to the system logger, except for the directory server
>> subsystem, which will be logged at `info` log-level instead. The code
>> responsible for generating consensus diffs uses the `dirserv` for
>> logging purposes.
>>
>> If the CPU spike happens right after a log message that says something
>> in the line of "The most recent XXX consensus is valid-after XXX. We
>> have diffs to this consensus for XXX/XXX older XXX consensuses.
>> Generating diffs for the other XXX." then I think we have our winner.
>>
>> Please remember to remove the `info` log-level when the experiment is
>> over :-)
>>
>> I'm curious what you figure out here. Let me know if you need any help.
>>
>> All the best,
>> Alex.
>>
>> --
>> Alexander Færøy
>> ___
>> tor-relays mailing list
>> tor-relays@lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor relay occasionally maxing out CPU usage

[William Kane]

Okay, so your suspicion was just confirmed:

consdiffmgr_rescan_flavor_(): The most recent ns consensus is
valid-after 2020-05-19T15:00:00. We have diffs to this consensus for
0/25 older ns consensuses. Generating diffs for the other 25.

Right after, diffs were compressed with zstd and lzma, causing the CPU
usage to spike.

Disabling DirCache still gives me the following warning on Tor 0.4.3.5:

May 19 17:56:42.909 [warn] DirCache is disabled and we are configured
as a relay. We will not become a Guard.

So, unless I sacrifice the Guard flag, there doesn't seem to be a way
to fix this problem in an easy way.

Please correct me if I'm wrong.


2020-05-19 15:07 GMT, William Kane :
> Another thing, from the change-log:
>
> - Update the message logged on relays when DirCache is disabled.
>   Since 0.3.3.5-rc, authorities require DirCache (V2Dir) for the
>   Guard flag. Fixes bug 24312; bugfix on 0.3.3.5-rc.
>
> If I understand this correctly, my relay would no longer be a Guard if
> I choose to disable DirCache in order to prevent Tor from hogging my
> CPU?
>
> From the code that I have seen, simply not setting the directory port
> does not stop the relay from caching / compressing diffs.
>
> Or has this been changed more recently?
>
> Not being a guard would honestly suck, and being a guard but with
> limited bandwidth due to Tor hogging the CPU also sucks.
>
> Any ideas on what to do?
>
> 2020-05-19 13:43 GMT, William Kane :
>> Dear Alexander,
>>
>> I have added 'Log [dirserv]info notice stdout' to my configuration and
>> will be monitoring the system closely.
>>
>> Tor was also upgraded to version 0.4.3.5, and the linux kernel was
>> upgraded to version 5.6.13 but I do not think this will change
>> anything.
>>
>> Expect a follow-up within the next 12 hours.
>>
>> William
>>
>> 2020-05-18 1:40 GMT, Alexander Færøy :
>>> Hello,
>>>
>>> On 2020/05/17 18:20, William Kane wrote:
 Occasionally, the CPU usage hit's 100%, and the maximum throughput
 drops down to around 16 Mbps from it's usual 80 Mbps. This happens
 randomly and not a fixed intervals which makes it pretty hard to
 profile.
>>>
>>> One of the subsystem's that I can think of that could potentially lead
>>> to the problem that you are describing is our "consensus diff"
>>> subsystem. The consensus diff subsystem is responsible for turning
>>> consensus documents into these patch(1)-like diffs that clients can
>>> fetch without the need to transfer the whole consensus for each minor
>>> change.
>>>
>>> The subsystem also takes care of compression, which includes LZMA, which
>>> is a beast when it comes to burning CPU cycles.
>>>
 No abnormal entries in the log files.
>>>
>>> I suspect you're logging at `notice` log-level, which is the reasonable
>>> thing to do. We need to log at slightly higher granularity to discover
>>> the problem here.
>>>
>>> Could I get you to add `Log [dirserv]info notice syslog` to your
>>> `torrc`? This line makes Tor log everything at notice log-level (the
>>> default), to the system logger, except for the directory server
>>> subsystem, which will be logged at `info` log-level instead. The code
>>> responsible for generating consensus diffs uses the `dirserv` for
>>> logging purposes.
>>>
>>> If the CPU spike happens right after a log message that says something
>>> in the line of "The most recent XXX consensus is valid-after XXX. We
>>> have diffs to this consensus for XXX/XXX older XXX consensuses.
>>> Generating diffs for the other XXX." then I think we have our winner.
>>>
>>> Please remember to remove the `info` log-level when the experiment is
>>> over :-)
>>>
>>> I'm curious what you figure out here. Let me know if you need any help.
>>>
>>> All the best,
>>> Alex.
>>>
>>> --
>>> Alexander Færøy
>>> ___
>>> tor-relays mailing list
>>> tor-relays@lists.torproject.org
>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>>
>>
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor relay occasionally maxing out CPU usage

[William Kane]

Dear Alexander,

I have added 'Log [dirserv]info notice stdout' to my configuration and
will be monitoring the system closely.

Tor was also upgraded to version 0.4.3.5, and the linux kernel was
upgraded to version 5.6.13 but I do not think this will change
anything.

Expect a follow-up within the next 12 hours.

William

2020-05-18 1:40 GMT, Alexander Færøy :
> Hello,
>
> On 2020/05/17 18:20, William Kane wrote:
>> Occasionally, the CPU usage hit's 100%, and the maximum throughput
>> drops down to around 16 Mbps from it's usual 80 Mbps. This happens
>> randomly and not a fixed intervals which makes it pretty hard to
>> profile.
>
> One of the subsystem's that I can think of that could potentially lead
> to the problem that you are describing is our "consensus diff"
> subsystem. The consensus diff subsystem is responsible for turning
> consensus documents into these patch(1)-like diffs that clients can
> fetch without the need to transfer the whole consensus for each minor
> change.
>
> The subsystem also takes care of compression, which includes LZMA, which
> is a beast when it comes to burning CPU cycles.
>
>> No abnormal entries in the log files.
>
> I suspect you're logging at `notice` log-level, which is the reasonable
> thing to do. We need to log at slightly higher granularity to discover
> the problem here.
>
> Could I get you to add `Log [dirserv]info notice syslog` to your
> `torrc`? This line makes Tor log everything at notice log-level (the
> default), to the system logger, except for the directory server
> subsystem, which will be logged at `info` log-level instead. The code
> responsible for generating consensus diffs uses the `dirserv` for
> logging purposes.
>
> If the CPU spike happens right after a log message that says something
> in the line of "The most recent XXX consensus is valid-after XXX. We
> have diffs to this consensus for XXX/XXX older XXX consensuses.
> Generating diffs for the other XXX." then I think we have our winner.
>
> Please remember to remove the `info` log-level when the experiment is
> over :-)
>
> I'm curious what you figure out here. Let me know if you need any help.
>
> All the best,
> Alex.
>
> --
> Alexander Færøy
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor relay occasionally maxing out CPU usage

[William Kane]

Not at fixed intervals*, sorry for the typo.

William

2020-05-17 18:20 GMT, William Kane :
> Hi there,
>
> I am the operator of the following relay:
>
> https://metrics.torproject.org/rs.html#details/47E1157F7DA6DF80EC00D745D73ACD7B0A380BCF
>
> The relay is running on my Arch Linux server running kernel version 5.6.11.
>
> This is my tor configuration file:
>
> ORPort 37.157.195.83:38619
> ORPort [2a02:2b88:2:1::3239:0]:38619
> DirPort 37.157.195.83:44776
> Nickname michaelscott
> ContactInfo ttall...@googlemail.com
> ControlPort 9051
> SocksPort 0
> CookieAuthentication 1
> ExitPolicy reject *:*
> DataDirectory /var/lib/tor
> Sandbox 1
>
> Linux kernel boot parameters from grub:
>
> quiet mitigations=off
>
> Kernel parameters from /etc/sysctl.d set on boot through systemd:
>
> kernel.dmesg_restrict = 1
> net.ipv6.ip_nonlocal_bind = 1
> kernel.yama.ptrace_scope = 3
> vm.swappiness = 60
>
> Tor systemd unit (shipped by distribution):
>
> [Unit]
> Description=Anonymizing Overlay Network
> After=network.target
>
> [Service]
> User=tor
> Type=simple
> ExecStart=/usr/bin/tor -f /etc/tor/torrc
> ExecReload=/usr/bin/kill -HUP $MAINPID
> KillSignal=SIGINT
> LimitNOFILE=8192
> PrivateDevices=yes
>
> [Install]
> WantedBy=multi-user.target
>
> Tor systemd unit overrides:
>
> [Service]
> ProtectSystem=strict
> ProtectHome=true
> PrivateTmp=true
> ProtectKernelLogs=true
> ProtectKernelModules=true
> ProtectKernelTunables=true
> ProtectControlGroups=true
> NoNewPrivileges=true
> RestrictSUIDSGID=true
> RestrictAddressFamilies=AF_INET AF_INET6
> ReadWritePaths=/var/lib/tor
>
> Occasionally, the CPU usage hit's 100%, and the maximum throughput
> drops down to around 16 Mbps from it's usual 80 Mbps. This happens
> randomly and not a fixed intervals which makes it pretty hard to
> profile.
>
> No abnormal entries in the log files.
>
> I found ticket #24857 in which someone describes a similar behavior,
> but on _Windows_.
>
> https://trac.torproject.org/projects/tor/ticket/24857
>
> Is this also an issue on Linux?
>
> In that case, setting DirCache to 0 should fix the issue, however that
> would mean that, according to the manual, I would no longer be able to
> mirror directory information.
>
> If anyone else encountered the same problem and found a solution,
> please let me know.
>
> Best Regards,
> William
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Tor relay occasionally maxing out CPU usage

[William Kane]

Hi there,

I am the operator of the following relay:

https://metrics.torproject.org/rs.html#details/47E1157F7DA6DF80EC00D745D73ACD7B0A380BCF

The relay is running on my Arch Linux server running kernel version 5.6.11.

This is my tor configuration file:

ORPort 37.157.195.83:38619
ORPort [2a02:2b88:2:1::3239:0]:38619
DirPort 37.157.195.83:44776
Nickname michaelscott
ContactInfo ttall...@googlemail.com
ControlPort 9051
SocksPort 0
CookieAuthentication 1
ExitPolicy reject *:*
DataDirectory /var/lib/tor
Sandbox 1

Linux kernel boot parameters from grub:

quiet mitigations=off

Kernel parameters from /etc/sysctl.d set on boot through systemd:

kernel.dmesg_restrict = 1
net.ipv6.ip_nonlocal_bind = 1
kernel.yama.ptrace_scope = 3
vm.swappiness = 60

Tor systemd unit (shipped by distribution):

[Unit]
Description=Anonymizing Overlay Network
After=network.target

[Service]
User=tor
Type=simple
ExecStart=/usr/bin/tor -f /etc/tor/torrc
ExecReload=/usr/bin/kill -HUP $MAINPID
KillSignal=SIGINT
LimitNOFILE=8192
PrivateDevices=yes

[Install]
WantedBy=multi-user.target

Tor systemd unit overrides:

[Service]
ProtectSystem=strict
ProtectHome=true
PrivateTmp=true
ProtectKernelLogs=true
ProtectKernelModules=true
ProtectKernelTunables=true
ProtectControlGroups=true
NoNewPrivileges=true
RestrictSUIDSGID=true
RestrictAddressFamilies=AF_INET AF_INET6
ReadWritePaths=/var/lib/tor

Occasionally, the CPU usage hit's 100%, and the maximum throughput
drops down to around 16 Mbps from it's usual 80 Mbps. This happens
randomly and not a fixed intervals which makes it pretty hard to
profile.

No abnormal entries in the log files.

I found ticket #24857 in which someone describes a similar behavior,
but on _Windows_.

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

Is this also an issue on Linux?

In that case, setting DirCache to 0 should fix the issue, however that
would mean that, according to the manual, I would no longer be able to
mirror directory information.

If anyone else encountered the same problem and found a solution,
please let me know.

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

Re: [tor-relays] Tor relay occasionally maxing out CPU usage

[Alexander Færøy]

Hello,

On 2020/05/17 18:20, William Kane wrote:
> Occasionally, the CPU usage hit's 100%, and the maximum throughput
> drops down to around 16 Mbps from it's usual 80 Mbps. This happens
> randomly and not a fixed intervals which makes it pretty hard to
> profile.

One of the subsystem's that I can think of that could potentially lead
to the problem that you are describing is our "consensus diff"
subsystem. The consensus diff subsystem is responsible for turning
consensus documents into these patch(1)-like diffs that clients can
fetch without the need to transfer the whole consensus for each minor
change.

The subsystem also takes care of compression, which includes LZMA, which
is a beast when it comes to burning CPU cycles.

> No abnormal entries in the log files.

I suspect you're logging at `notice` log-level, which is the reasonable
thing to do. We need to log at slightly higher granularity to discover
the problem here.

Could I get you to add `Log [dirserv]info notice syslog` to your
`torrc`? This line makes Tor log everything at notice log-level (the
default), to the system logger, except for the directory server
subsystem, which will be logged at `info` log-level instead. The code
responsible for generating consensus diffs uses the `dirserv` for
logging purposes.

If the CPU spike happens right after a log message that says something
in the line of "The most recent XXX consensus is valid-after XXX. We
have diffs to this consensus for XXX/XXX older XXX consensuses.
Generating diffs for the other XXX." then I think we have our winner.

Please remember to remove the `info` log-level when the experiment is
over :-)

I'm curious what you figure out here. Let me know if you need any help.

All the best,
Alex.

-- 
Alexander Færøy
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] tor relay on windows 10

[Станислав]

already found)) 16.05.2020, 17:56, "Станислав" :hello everyone again.please tell me the command to launch the second instance of tor relay on windows 10.service is already installed and one relay is running.thankС уважением,Станислав  ,___tor-relays mailing listtor-relays@lists.torproject.orghttps://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] tor relay on windows 10

[Станислав]

hello everyone again.please tell me the command to launch the second instance of tor relay on windows 10.service is already installed and one relay is running.thankС уважением,Станислав  
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] tor relay

[Roman Mamedov]

On Fri, 13 Mar 2020 15:22:49 +0300
Станислав  wrote:

>  
>  
> 13.03.2020, 14:55, "teor" :
> Hi,
>  
> Post the entire file without shortening or removing any line. If it complains
> about parse error, there must be something wrong in it, but you don't 
> noticeor don't think it is wrong. People on the mailing list can check if 
> it's ok,but again only if you post the entire file (copy-paste or attach). 
> С уважением,
> Станислав
>  
> 
>  
> There could be a few things wrong here.
>  
> Try setting ServerDNSResolvConfFile to /dev/null,
> or a world-readable empty file, and see if your problem goes away.
>  
> If it does, here are some common issues to check:
>  
> What are the permissions on /etc.resolv.conf ?
> Can the tor user read the file?
>  
> Is the file a symlink?
> (macOS does this, not sure if some Linux distros do as well)
>  
> Are there any hidden characters in the file?
> Does it use Unix newlines?
>  
> Tor uses libevent's evdns_base_resolv_conf_parse() to parse the file.
> https://libevent.org/doc/dns_8h.html#a7e3a053e25ae7c045944a5db0947babb
>  
> How old is your version of libevent?

FYI in a private discussion we figured out that the trailing dot in
"search lan." was indeed what caused the issue.

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

Re: [tor-relays] tor relay

[Roman Mamedov]

On Fri, 13 Mar 2020 13:53:25 +0300
armik...@gmail.com wrote:

> С уважением,
> Станислав

I'm not sure if trailing dot is allowed in the "search" directive. Can you try
removing the dot after "lan"? Or just remove the "search" line entirely.

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

Re: [tor-relays] tor relay

[Станислав]

  13.03.2020, 14:55, "teor" :Hi, Post the entire file without shortening or removing any line. If it complainsabout parse error, there must be something wrong in it, but you don't noticeor don't think it is wrong. People on the mailing list can check if it's ok,but again only if you post the entire file (copy-paste or attach). С уважением,Станислав  There could be a few things wrong here. Try setting ServerDNSResolvConfFile to /dev/null,or a world-readable empty file, and see if your problem goes away. If it does, here are some common issues to check: What are the permissions on /etc.resolv.conf ?Can the tor user read the file? Is the file a symlink?(macOS does this, not sure if some Linux distros do as well) Are there any hidden characters in the file?Does it use Unix newlines? Tor uses libevent's evdns_base_resolv_conf_parse() to parse the file.https://libevent.org/doc/dns_8h.html#a7e3a053e25ae7c045944a5db0947babb How old is your version of libevent? T -- teor-- ,___tor-relays mailing listtor-relays@lists.torproject.orghttps://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays  С уважением,Станислав What are the permissions on /etc.resolv.conf ?read and write Is the file a symlink?I do not know Are there any hidden characters in the file?no Does it use Unix newlines?I do not know How old is your version of libevent?libevent 2.1.11 I deleted this file and managed to start, but such entries appeared: Mar 09 22:32:18.000 [notice] Received reload signal (hup). Reloading config and resetting internal state.Mar 09 22:32:18.000 [notice] Read configuration file "/etc/tor/torrc1".Mar 09 22:32:18.000 [notice] Your ContactInfo config option is not set. Please consider setting it, so we can contact you if your server is misconfigured or something else goes wrong.Mar 09 22:32:18.000 [warn] MyFamily is set but ContactInfo is not configured. ContactInfo should always be set when MyFamily option is too.Mar 09 22:32:18.000 [notice] Tor 0.4.2.5 opening log file.Mar 09 22:32:18.000 [warn] Unable to stat resolver configuration in '/etc/resolv.conf': No such file or directoryMar 09 22:32:18.000 [warn] Could not read your DNS config from '/etc/resolv.conf' - please investigate your DNS configuration. This is possibly a problem. Meanwhile, falling back to local DNS at 127.0.0.1.Mar 09 22:32:18.000 [warn] Unable to stat resolver configuration in '/etc/resolv.conf': No such file or directoryMar 09 22:32:18.000 [warn] Could not read your DNS config from '/etc/resolv.conf' - please investigate your DNS configuration. This is possibly a problem. Meanwhile, falling back to local DNS at 127.0.0.1. ___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] tor relay

[teor]

Hi,

>> Post the entire file without shortening or removing any line. If it complains
>> about parse error, there must be something wrong in it, but you don't notice
>> or don't think it is wrong. People on the mailing list can check if it's ok,
>> but again only if you post the entire file (copy-paste or attach).
> 
> С уважением,
> Станислав
> 
> 

There could be a few things wrong here.

Try setting ServerDNSResolvConfFile to /dev/null,
or a world-readable empty file, and see if your problem goes away.

If it does, here are some common issues to check:

What are the permissions on /etc.resolv.conf ?
Can the tor user read the file?

Is the file a symlink?
(macOS does this, not sure if some Linux distros do as well)

Are there any hidden characters in the file?
Does it use Unix newlines?

Tor uses libevent's evdns_base_resolv_conf_parse() to parse the file.
https://libevent.org/doc/dns_8h.html#a7e3a053e25ae7c045944a5db0947babb

How old is your version of libevent?

T

-- 
teor
--


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

Re: [tor-relays] tor relay

[armik900]

13.03.2020, 13:23, "Roman Mamedov" :
> On Fri, 13 Mar 2020 13:17:48 +0300
> Станислав  wrote:
>
>>  12.03.2020, 23:36, "Sean Greenslade" :
>>  >>>  What are the contents of /etc/resolv.conf ?
>>  >>
>>  >> 127.0.0.1
>>  >> ::1
>>  >
>>  > That's the problem. The format of resolv.conf requires the string 
>> "nameserver" before each ip. Try something like this:
>>  >
>>  > # Up to three nameserver lines are allowed.
>>  > nameserver 127.0.0.1
>>  > nameserver ::1
>>  > #nameserver 
>>  >
>>  > --Sean
>>  >
>>  > ___
>>  > tor-relays mailing list
>>  > tor-relays@lists.torproject.org
>>  > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>
>>  С уважением,
>>  Станислав
>>
>>  that’s exactly what it says, I simply shortened and did not write the word 
>> nameserver
>>  ___
>>  tor-relays mailing list
>>  tor-relays@lists.torproject.org
>>  https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
> Post the entire file without shortening or removing any line. If it complains
> about parse error, there must be something wrong in it, but you don't notice
> or don't think it is wrong. People on the mailing list can check if it's ok,
> but again only if you post the entire file (copy-paste or attach).
>
> --
> With respect,
> Roman

С уважением,
Станислав

# /tmp/resolv.conf generated by Unbound UCI 2020-03-09T22:01:11+0300
nameserver 127.0.0.1
nameserver ::1
search lan.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] tor relay

[Roman Mamedov]

On Fri, 13 Mar 2020 13:17:48 +0300
Станислав  wrote:

> 
> 
> 12.03.2020, 23:36, "Sean Greenslade" :
> >>>  What are the contents of /etc/resolv.conf ?
> >>
> >> 127.0.0.1
> >> ::1
> >
> > That's the problem. The format of resolv.conf requires the string 
> > "nameserver" before each ip. Try something like this:
> >
> > # Up to three nameserver lines are allowed.
> > nameserver 127.0.0.1
> > nameserver ::1
> > #nameserver 
> >
> > --Sean
> >
> > ___
> > tor-relays mailing list
> > tor-relays@lists.torproject.org
> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 
> С уважением,
> Станислав
> 
> 
> that’s exactly what it says, I simply shortened and did not write the word 
> nameserver
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Post the entire file without shortening or removing any line. If it complains
about parse error, there must be something wrong in it, but you don't notice
or don't think it is wrong. People on the mailing list can check if it's ok,
but again only if you post the entire file (copy-paste or attach).

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

Re: [tor-relays] tor relay

[Станислав]

12.03.2020, 23:36, "Sean Greenslade" :
>>>  What are the contents of /etc/resolv.conf ?
>>
>> 127.0.0.1
>> ::1
>
> That's the problem. The format of resolv.conf requires the string 
> "nameserver" before each ip. Try something like this:
>
> # Up to three nameserver lines are allowed.
> nameserver 127.0.0.1
> nameserver ::1
> #nameserver 
>
> --Sean
>
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

С уважением,
Станислав


that’s exactly what it says, I simply shortened and did not write the word 
nameserver
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] tor relay

[Sean Greenslade]

>> What are the contents of /etc/resolv.conf ?
>
>127.0.0.1
>::1

That's the problem. The format of resolv.conf requires the string "nameserver" 
before each ip. Try something like this:

# Up to three nameserver lines are allowed.
nameserver 127.0.0.1
nameserver ::1
#nameserver 

--Sean

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

Re: [tor-relays] tor relay

[newsletter]

On 12.03.2020 08:14, Станислав wrote:

11.03.2020, 22:57, "Sean Greenslade" : On 
March 9, 2020 3:55:38 AM PDT, "Станислав"  wrote: 
hi.I start second instance of tor, but for some reason it stopped

working.after updating the firmware on board pc engines apu2

Mar 09 13:48:46.000 [notice] Bootstrapped 0% (starting): Starting
Mar 09 13:49:03.000 [notice] Starting with guard context "default"
Mar 09 13:49:03.000 [warn] Unable to parse '/etc/resolv.conf', or no
nameservers in '/etc/resolv.conf' (1)
Mar 09 13:49:03.000 [warn] Couldn't set up any working nameservers.
Network not up yet? Will try again soon.
Mar 09 13:49:03.000 [notice] Self-testing indicates your ORPort is
reachable from the outside. Excellent.
Mar 09 13:49:04.000 [notice] Bootstrapped 5% (conn): Connecting to a
relay
Mar 09 13:49:04.000 [warn] Unable to parse '/etc/resolv.conf', or no
nameservers in '/etc/resolv.conf' (1)
Mar 09 13:49:04.000 [notice] Bootstrapped 10% (conn_done): Connected to
a relay
Mar 09 13:49:04.000 [notice] Bootstrapped 14% (handshake): Handshaking
with a relay
Mar 09 13:49:05.000 [notice] Bootstrapped 15% (handshake_done):
Handshake with a relay done
Mar 09 13:49:05.000 [notice] Bootstrapped 75% (enough_dirinfo): Loaded
enough directory info to build circuits
Mar 09 13:49:05.000 [notice] Bootstrapped 90% (ap_handshake_done):
Handshake finished with a relay to build circuits
Mar 09 13:49:05.000 [notice] Bootstrapped 95% (circuit_create):
Establishing a Tor circuit
Mar 09 13:49:06.000 [notice] Bootstrapped 100% (done): Done
Mar 09 13:50:05.000 [notice] Self-testing indicates your DirPort is
reachable from the outside. Excellent. Publishing server descriptor.
Mar 09 13:50:08.000 [notice] Performing bandwidth self-test...done.
Mar 09 13:51:32.000 [notice] Received reload signal (hup). Reloading
config and resetting internal state.
Mar 09 13:51:32.000 [notice] Read configuration file "/etc/tor/torrc1".
Mar 09 13:51:32.000 [notice] Your ContactInfo config option is not set.
Please consider setting it, so we can contact you if your server is
misconfigured or something else goes wrong.
Mar 09 13:51:32.000 [warn] MyFamily is set but ContactInfo is not
configured. ContactInfo should always be set when MyFamily option is
too.
Mar 09 13:51:32.000 [notice] Tor 0.4.2.5 opening log file.
Mar 09 13:51:32.000 [warn] Unable to parse '/etc/resolv.conf', or no
nameservers in '/etc/resolv.conf' (1)
Mar 09 13:51:32.000 [err] set_options(): Bug: Acting on config options
left us in a broken state. Dying. (on Tor 0.4.2.5 )
Mar 09 13:51:32.000 [err] Reading config failed--see warnings above.
For usage, try -h.
Mar 09 13:51:32.000 [warn] Restart failed (config error?). Exiting.
Well, these lines look like a good place to start:

Mar 09 13:49:03.000 [warn] Unable to parse '/etc/resolv.conf', or no 
nameservers in '/etc/resolv.conf' (1)
Mar 09 13:49:03.000 [warn] Couldn't set up any working nameservers. 
Network not up yet? Will try again soon.

What are the contents of /etc/resolv.conf ?

--Sean

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


С уважением,
Станислав

127.0.0.1
::1
but the errors continue.I run of odhcpd+unbound.on a unbound works 
dns-over-tls in log torrc these errors.are what could be the problem?
Mar 09 15:13:37.000 [warn] Unable to parse '/etc/resolv.conf', or no 
nameservers in '/etc/resolv.conf' (1)
Mar 09 15:23:37.000 [warn] Unable to parse '/etc/resolv.conf', or no 
nameservers in '/etc/resolv.conf' (1)
Mar 09 15:33:37.000 [warn] Unable to parse '/etc/resolv.conf', or no 
nameservers in '/etc/resolv.conf' (1)


Hi,
/etc/resolv.conf needs to be formatted like this:
nameserver 1.2.3.4
nameserver 4.3.2.1

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

Re: [tor-relays] tor relay

[Станислав]

11.03.2020, 22:57, "Sean Greenslade" :
> On March 9, 2020 3:55:38 AM PDT, "Станислав"  wrote:
>> hi.I start second instance of tor, but for some reason it stopped
>> working.after updating the firmware on board pc engines apu2
>>
>> Mar 09 13:48:46.000 [notice] Bootstrapped 0% (starting): Starting
>> Mar 09 13:49:03.000 [notice] Starting with guard context "default"
>> Mar 09 13:49:03.000 [warn] Unable to parse '/etc/resolv.conf', or no
>> nameservers in '/etc/resolv.conf' (1)
>> Mar 09 13:49:03.000 [warn] Couldn't set up any working nameservers.
>> Network not up yet? Will try again soon.
>> Mar 09 13:49:03.000 [notice] Self-testing indicates your ORPort is
>> reachable from the outside. Excellent.
>> Mar 09 13:49:04.000 [notice] Bootstrapped 5% (conn): Connecting to a
>> relay
>> Mar 09 13:49:04.000 [warn] Unable to parse '/etc/resolv.conf', or no
>> nameservers in '/etc/resolv.conf' (1)
>> Mar 09 13:49:04.000 [notice] Bootstrapped 10% (conn_done): Connected to
>> a relay
>> Mar 09 13:49:04.000 [notice] Bootstrapped 14% (handshake): Handshaking
>> with a relay
>> Mar 09 13:49:05.000 [notice] Bootstrapped 15% (handshake_done):
>> Handshake with a relay done
>> Mar 09 13:49:05.000 [notice] Bootstrapped 75% (enough_dirinfo): Loaded
>> enough directory info to build circuits
>> Mar 09 13:49:05.000 [notice] Bootstrapped 90% (ap_handshake_done):
>> Handshake finished with a relay to build circuits
>> Mar 09 13:49:05.000 [notice] Bootstrapped 95% (circuit_create):
>> Establishing a Tor circuit
>> Mar 09 13:49:06.000 [notice] Bootstrapped 100% (done): Done
>> Mar 09 13:50:05.000 [notice] Self-testing indicates your DirPort is
>> reachable from the outside. Excellent. Publishing server descriptor.
>> Mar 09 13:50:08.000 [notice] Performing bandwidth self-test...done.
>> Mar 09 13:51:32.000 [notice] Received reload signal (hup). Reloading
>> config and resetting internal state.
>> Mar 09 13:51:32.000 [notice] Read configuration file "/etc/tor/torrc1".
>> Mar 09 13:51:32.000 [notice] Your ContactInfo config option is not set.
>> Please consider setting it, so we can contact you if your server is
>> misconfigured or something else goes wrong.
>> Mar 09 13:51:32.000 [warn] MyFamily is set but ContactInfo is not
>> configured. ContactInfo should always be set when MyFamily option is
>> too.
>> Mar 09 13:51:32.000 [notice] Tor 0.4.2.5 opening log file.
>> Mar 09 13:51:32.000 [warn] Unable to parse '/etc/resolv.conf', or no
>> nameservers in '/etc/resolv.conf' (1)
>> Mar 09 13:51:32.000 [err] set_options(): Bug: Acting on config options
>> left us in a broken state. Dying. (on Tor 0.4.2.5 )
>> Mar 09 13:51:32.000 [err] Reading config failed--see warnings above.
>> For usage, try -h.
>> Mar 09 13:51:32.000 [warn] Restart failed (config error?). Exiting.
>
> Well, these lines look like a good place to start:
>
>>  Mar 09 13:49:03.000 [warn] Unable to parse '/etc/resolv.conf', or no 
>> nameservers in '/etc/resolv.conf' (1)
>>  Mar 09 13:49:03.000 [warn] Couldn't set up any working nameservers. Network 
>> not up yet? Will try again soon.
>
> What are the contents of /etc/resolv.conf ?
>
> --Sean
>
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

С уважением,
Станислав

127.0.0.1
::1
but the errors continue.I run of odhcpd+unbound.on a unbound works dns-over-tls 
in log torrc these errors.are what could be the problem?
Mar 09 15:13:37.000 [warn] Unable to parse '/etc/resolv.conf', or no 
nameservers in '/etc/resolv.conf' (1)
Mar 09 15:23:37.000 [warn] Unable to parse '/etc/resolv.conf', or no 
nameservers in '/etc/resolv.conf' (1)
Mar 09 15:33:37.000 [warn] Unable to parse '/etc/resolv.conf', or no 
nameservers in '/etc/resolv.conf' (1)
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] tor relay

[Sean Greenslade]

On March 9, 2020 3:55:38 AM PDT, "Станислав"  wrote:
>hi.I start  second instance of tor, but for some reason it stopped
>working.after updating the firmware on  board pc engines apu2
>
>Mar 09 13:48:46.000 [notice] Bootstrapped 0% (starting): Starting
>Mar 09 13:49:03.000 [notice] Starting with guard context "default"
>Mar 09 13:49:03.000 [warn] Unable to parse '/etc/resolv.conf', or no
>nameservers in '/etc/resolv.conf' (1)
>Mar 09 13:49:03.000 [warn] Couldn't set up any working nameservers.
>Network not up yet?  Will try again soon.
>Mar 09 13:49:03.000 [notice] Self-testing indicates your ORPort is
>reachable from the outside. Excellent.
>Mar 09 13:49:04.000 [notice] Bootstrapped 5% (conn): Connecting to a
>relay
>Mar 09 13:49:04.000 [warn] Unable to parse '/etc/resolv.conf', or no
>nameservers in '/etc/resolv.conf' (1)
>Mar 09 13:49:04.000 [notice] Bootstrapped 10% (conn_done): Connected to
>a relay
>Mar 09 13:49:04.000 [notice] Bootstrapped 14% (handshake): Handshaking
>with a relay
>Mar 09 13:49:05.000 [notice] Bootstrapped 15% (handshake_done):
>Handshake with a relay done
>Mar 09 13:49:05.000 [notice] Bootstrapped 75% (enough_dirinfo): Loaded
>enough directory info to build circuits
>Mar 09 13:49:05.000 [notice] Bootstrapped 90% (ap_handshake_done):
>Handshake finished with a relay to build circuits
>Mar 09 13:49:05.000 [notice] Bootstrapped 95% (circuit_create):
>Establishing a Tor circuit
>Mar 09 13:49:06.000 [notice] Bootstrapped 100% (done): Done
>Mar 09 13:50:05.000 [notice] Self-testing indicates your DirPort is
>reachable from the outside. Excellent. Publishing server descriptor.
>Mar 09 13:50:08.000 [notice] Performing bandwidth self-test...done.
>Mar 09 13:51:32.000 [notice] Received reload signal (hup). Reloading
>config and resetting internal state.
>Mar 09 13:51:32.000 [notice] Read configuration file "/etc/tor/torrc1".
>Mar 09 13:51:32.000 [notice] Your ContactInfo config option is not set.
>Please consider setting it, so we can contact you if your server is
>misconfigured or something else goes wrong.
>Mar 09 13:51:32.000 [warn] MyFamily is set but ContactInfo is not
>configured. ContactInfo should always be set when MyFamily option is
>too.
>Mar 09 13:51:32.000 [notice] Tor 0.4.2.5 opening log file.
>Mar 09 13:51:32.000 [warn] Unable to parse '/etc/resolv.conf', or no
>nameservers in '/etc/resolv.conf' (1)
>Mar 09 13:51:32.000 [err] set_options(): Bug: Acting on config options
>left us in a broken state. Dying. (on Tor 0.4.2.5 )
>Mar 09 13:51:32.000 [err] Reading config failed--see warnings above.
>For usage, try -h.
>Mar 09 13:51:32.000 [warn] Restart failed (config error?). Exiting.


Well, these lines look like a good place to start:

> Mar 09 13:49:03.000 [warn] Unable to parse '/etc/resolv.conf', or no 
> nameservers in '/etc/resolv.conf' (1)
> Mar 09 13:49:03.000 [warn] Couldn't set up any working nameservers. Network 
> not up yet? Will try again soon.

What are the contents of /etc/resolv.conf ?

--Sean

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

Re: [tor-relays] tor relay

[lists]

On 09.03.2020 11:55, Станислав wrote:

hi.I start  second instance of tor, but for some reason it stopped
working.after updating the firmware on  board pc engines apu2


:-) You have a very nice setup there:

OpenWrt on PC Engines APU 2

--
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays