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 the

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&A
> - 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

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

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

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

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&A

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?
(https://libraryfreedompro

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

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

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

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

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 onlin

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

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

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

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

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&response=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
automati

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

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

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
> 
_

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

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

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

Re: [tor-relays] tor relay

[lists]

On 09.03.2020 14:51, Станислав wrote:

system openwrt.I have a bunch of odhcpd+unbound.on a unbound works
dns-over-tls in  end face log torrc these errors.are what could be the
problem? the unbound is not configured correctly.
Mar 09 15:13:37.000 [warn] Unable to parse '/etc/resolv.conf', or no
nameservers in '/etc/resolv.conf' (1)


Please post the output of:

~$ cat /etc/resolv.conf
~$ cat /etc/dhcpcd.conf

--
╰_╯ 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

Re: [tor-relays] tor relay ipv6

[Matt Westfall]

That's why I personally just disable all firewalls and just configure acls in 
vulnerable services themselves.

Don't let mysql listen on anything but local host, server secured lol. 
-- 
Matt Westfall
President & CIO 
ECAN Solutions, Inc. 
804.592.1672 

On August 22, 2019 11:46:44 AM EDT, Roman Mamedov  wrote:
>On Thu, 22 Aug 2019 13:07:21 +
>"Matt Westfall"  wrote:
>
>> So perhaps your ISP is wonking with tor traffic as suggested.
>
>We happened to meet in a Telegram group chat and after some more
>discussion
>the cause turned out to be firewall rules on the relay machine itself.
>
>-- 
>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 ipv6

[Станислав]

22.08.2019, 18:46, "Roman Mamedov" :
> On Thu, 22 Aug 2019 13:07:21 +
> "Matt Westfall"  wrote:
>
>>  So perhaps your ISP is wonking with tor traffic as suggested.
>
> We happened to meet in a Telegram group chat and after some more discussion
> the cause turned out to be firewall rules on the relay machine itself.
>
> --
> With respect,
> Roman
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
thank you all for your help.problem resolved.
С уважением,
Станислав



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

Re: [tor-relays] tor relay ipv6

[Roman Mamedov]

On Thu, 22 Aug 2019 13:07:21 +
"Matt Westfall"  wrote:

> So perhaps your ISP is wonking with tor traffic as suggested.

We happened to meet in a Telegram group chat and after some more discussion
the cause turned out to be firewall rules on the relay machine itself.

-- 
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 - RelayBandwidthRate vs. RelayBandwidthBurst

[petrarca]

Great, and many thanks - that explains it: if the bursting-timespan is 1 sec 
only only I obviously can't see that bandwidth bursting with my resolution of 
10 sec measurements.



‐‐‐ Original Message ‐‐‐
On Thursday, 22. August 2019 05:02, teor  wrote:

> Hi,
>
> > On 20 Aug 2019, at 20:23, petra...@protonmail.ch wrote:
> > I'm struggling a bit with the two config options for RelayBandwidthRate and 
> > RelayBandwidthBurst - what I currently have in my torrc config file is:
> > ...
> > RelayBandwidthRate 8 Mbit
> > RelayBandwidthBurst 12 Mbit
> > ...
> > My assumption was that on average the Relay would consume 8 Mbps max. but 
> > over a shorter period of time also up to 12 Mbps in case needed.
> > What I see (historical monitor data at 10 s intervals for the past 6 
> > months) is that the bandwidth usage never exceeds 8 Mbps. I can also see 
> > the consumption to be levelled out at 8 Mbps for minutes or hours so it 
> > looks like there would be a need for more bandwidth.
>
> Yes the Tor network does need more bandwidth, particularly for exits.
>
> > My question: why can't I see the bandwidth usage going above 8 Mbps and 
> > making use of the allowed burst? Btw, I'm typically using the latest stable 
> > tor, currently the relay is on 0.4.0.5.
>
> The burst is over a very short period of time.
> I think it's about 1 second.
>
> The rate is averaged is over a slightly longer period of time, and
> includes any burst bandwidth. That is, if the bandwidth burst to
> 12 Mbps in the last second, the bandwidth in this second will be
> 4 Mbps. The lower bandwidth in the next second keeps the average to
> 8 Mbps.
>
> T
>
> ---
>
> teor
>
> -
>
> 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 ipv6

[Matt Westfall]

I can traceroute to your ipv6 address:

traceroute to 2a03:e2c0:bc7::2 (2a03:e2c0:bc7::2), 30 hops max, 80 byte 
packets
 1  2001:559:800c:1900::5a01 (2001:559:800c:1900::5a01)  0.356 ms  0.345 
ms  0.449 ms
 2  2001:558:180:1c::1 (2001:558:180:1c::1)  0.317 ms  0.435 ms  0.429 
ms
 3  2001:558:180:36::1 (2001:558:180:36::1)  7.756 ms  7.763 ms  7.864 
ms
 4  be-21508-cr02.ashburn.va.ibone.comcast.net (2001:558:0:f6cd::1)  
10.873 ms * *

 5  * * *
 6  * * *
 7  * * *
 8  lo-0-v6.ear4.frankfurt1.level3.net (2001:1900:2::3:12b)  96.479 ms  
96.505 ms  96.654 ms
 9  2001:1900:5:2:2::5be2 (2001:1900:5:2:2::5be2)  108.774 ms  108.757 
ms  108.757 ms
10  rt.mr.msk.ru.retn.net (2a02:2d8::57f5:e005)  141.933 ms  142.148 ms  
141.996 ms
11  gw-mediaserviceplus.retn.net (2a02:2d8:0:82a:232a::1)  136.907 ms  
136.871 ms  136.670 ms
12  2a04:5200:: (2a04:5200::)  142.424 ms  141.550 ms  141.963 
ms
13  2a03:e2c0:bc7::2 (2a03:e2c0:bc7::2)  140.933 ms  141.737 ms  141.245 
ms


So perhaps your ISP is wonking with tor traffic as suggested.

Thanks,

Matt Westfall
President & CIO
ECAN Solutions, Inc.
Everything Computers and Networks
804.592.1672

-- Original Message --
From: "teor" 
To: tor-relays@lists.torproject.org
Sent: 8/22/2019 7:23:03 AM
Subject: Re: [tor-relays] tor relay ipv6


Hi,


 On 22 Aug 2019, at 20:00, Станислав  wrote:

 22.08.2019, 06:57, "teor" :




  On 21 Aug 2019, at 23:38, armik...@gmail.com wrote:

  hi.in relay stopped working ipv6.address is correct all pings, including tor 
to the servers, but relay does not work.before that it worked perfectly 2 
months.


 Please tell us your relay's fingerprint.


 CE5ED345398CC02D573347C2F238F80B18E680EE.



Your relay's IPv6 address is not reachable from the directory authorities:
https://metrics.torproject.org/rs.html#details/CE5ED345398CC02D573347C2F238F80B18E680EE

All 6 directory authorities on IPv6 can't reach your relay on IPv6:
https://consensus-health.torproject.org/consensus-health-2019-08-22-10-00.html#CE5ED345398CC02D573347C2F238F80B18E680EE

But your relay is still reachable over IPv4 from the 3 directory authorities
that don't have IPv6.


 Please copy and paste the notice-level logs that tor creates on startup,
 from launch to the end of the ORPort and DirPort reachability checks.


And your relay is reachable over IPv6 on its ORPort and DirPort from at least
one relay in the tor network.

It looks like your torrc matches your local network config.


 Please copy and paste your torrc, particularly the Address, ORPort, DirPort,
 and OutboundBindAddress options.


Your torrc looks correct.


 It can be hard to set up IPv6 for a relay, we're working on a grant to make
 it easier.


Tor doesn't do IPv6 reachability checks yet, that's part of the grant.

The only issue I can see is that all 6 directory authorities on IPv6 can't
reach your relay on IPv6.

Has your provider stopped routing your IPv6 address to your relay?
Does your provider censor Tor over IPv6?

It looks like the problem is somewhere between your relay machine and
the IPv6 internet.

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

Re: [tor-relays] tor relay ipv6

[Matt Westfall]

Here's all the info you need to setup IPv6 in Debian:

root@ateam:~# ifconfig
eno1: flags=4163 mtu 1500
inet 50.238.252.6 netmask 255.255.255.252 broadcast 50.238.252.7
inet6 2001:559:800c:1900::5a02 prefixlen 126 scopeid 0x0

root@ateam:/etc/network# pwd
/etc/network
root@ateam:/etc/network# cat interfaces
iface eno1 inet6 static
address 2001:559:800c:1900::5a02
netmask 126
gateway 2001:559:800c:1900::5a01
dns-nameserver 2620:0:ccc::2 2620:0:ccd::2



Matt Westfall
President & CIO
ECAN Solutions, Inc.
Everything Computers and Networks
804.592.1672

-- Original Message --
From: "teor" 
To: tor-relays@lists.torproject.org
Sent: 8/22/2019 6:08:14 AM
Subject: Re: [tor-relays] tor relay ipv6


Hi Paul,


 On 22 Aug 2019, at 14:26, Paul Templeton  wrote:


 It can be hard to set up IPv6 for a relay, we're working on a grant to make
 it easier.


 It could be helpful to do a request/survey to relay operators to find out 
their experiences.
 That is those who have ipv6 configured what was the process and if there were 
any problems in the process.
 For those who haven't yet configured ipv6 what is the barriers preventing them 
from using ipv6.


Yes, I'd love to know what problems relay operators have with setting up IPv6.
I have some idea from helping people out, but hard data is more useful.

We tried to add a survey/advocacy component to the grant, but there wasn't
enough time in the grant budget.

Would you like to run a survey or start a mailing list thread?


 For me it was a problem at the ISPs end then it wasn't clear how to get 
network config to use ipv6. I got the shits with it in the end and just used 
iface eth0 inet6 dhcp. It works... LOL


Yeah it took me a while to learn how to set up IPv6 on Linux.
Most VPS providers don't do it automatically.

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

Re: [tor-relays] tor relay ipv6

[Matt Westfall]

IPv6 at the OS Side is not difficult whatsoever.

My node is running IPv6, I have 2Gbps Comcast Fiber.

It's literally no different than configuring IPv4 other than its 
hexidecimal and a lot more digits :-D




Matt Westfall
President & CIO
ECAN Solutions, Inc.
Everything Computers and Networks
804.592.1672

-- Original Message --
From: "Paul Templeton" 
To: tor-relays@lists.torproject.org
Sent: 8/22/2019 12:26:09 AM
Subject: Re: [tor-relays] tor relay ipv6




 It can be hard to set up IPv6 for a relay, we're working on a grant to make
 it easier.


It could be helpful to do a request/survey to relay operators to find out their 
experiences.
That is those who have ipv6 configured what was the process and if there were 
any problems in the process.
For those who haven't yet configured ipv6 what is the barriers preventing them 
from using ipv6.

For me it was a problem at the ISPs end then it wasn't clear how to get network 
config to use ipv6. I got the shits with it in the end and just used iface eth0 
inet6 dhcp. It works... LOL

Paul
___
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 ipv6

[Roman Mamedov]

On Thu, 22 Aug 2019 21:23:03 +1000
teor  wrote:

> Your relay's IPv6 address is not reachable from the directory authorities:
> https://metrics.torproject.org/rs.html#details/CE5ED345398CC02D573347C2F238F80B18E680EE
> 
> All 6 directory authorities on IPv6 can't reach your relay on IPv6:
> https://consensus-health.torproject.org/consensus-health-2019-08-22-10-00.html#CE5ED345398CC02D573347C2F238F80B18E680EE

To be more specific, from my tests the IP in question is reachable by ICMP,
but it is "Connection refused" on port 443.

@Станислав,
Maybe you didn't reload (or better yet, restart) Tor after
commenting/uncommenting some of the IPv6-related lines in torrc? (Which looks
kind of weird, and hints that perhaps you were experimenting with various 
changes)

---
## Required: what port to advertise for incoming Tor connections.
#ORPort 9001
## If you want to listen on a port other than the one advertised in
## ORPort (e.g. to advertise 443 but bind to 9090), you can do it as
## follows.  You'll need to do ipchains or other port forwarding
## yourself to make this work.
ORPort 443 
#ORPort [2a03:e2c0:bc7::2]:443
#ORPort 127.0.0.1:9090 NoAdvertise

## The IP address or full DNS name for incoming connections to your
## relay. Leave commented out and Tor will guess.
Address [2a03:e2c0:bc7::2]

## If you have multiple network interfaces, you can specify one for
## outgoing traffic to use.
## OutboundBindAddressExit will be used for all exit traffic, while
## OutboundBindAddressOR will be used for all OR and Dir connections
## (DNS connections ignore OutboundBindAddress).
## If you do not wish to differentiate, use OutboundBindAddress to
## specify the same address for both in a single line.
#OutboundBindAddressExit 10.0.0.4
OutboundBindAddress [2a03:e2c0:bc7::2]
ORPort [2a03:e2c0:bc7::2]:443
---

The "Address" and "OutboundBindAddress" IPv6 lines should not be necessary,
only the ORPort one is required, i.e. 

  ORPort 443 
  ORPort [2a03:e2c0:bc7::2]:443

should be fine, all the rest can be deleted.

Also check firewall on the router and the machine itself, that IPv6
connections on port 443 are accepted from the outside.

Lastly, rather than using a tunnel, check if you get native IPv6 from your
ISP, I think yours should provide it in some areas. However then you might get
a dynamic prefix, which is a pain to use with Tor currently (speaking of
v6-related Tor issues...)

-- 
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 ipv6

[teor]

Hi,

> On 22 Aug 2019, at 20:00, Станислав  wrote:
> 
> 22.08.2019, 06:57, "teor" :
>> 
>> 
>>>  On 21 Aug 2019, at 23:38, armik...@gmail.com wrote:
>>> 
>>>  hi.in relay stopped working ipv6.address is correct all pings, including 
>>> tor to the servers, but relay does not work.before that it worked perfectly 
>>> 2 months.
>> 
>> Please tell us your relay's fingerprint.
> 
> CE5ED345398CC02D573347C2F238F80B18E680EE.


Your relay's IPv6 address is not reachable from the directory authorities:
https://metrics.torproject.org/rs.html#details/CE5ED345398CC02D573347C2F238F80B18E680EE

All 6 directory authorities on IPv6 can't reach your relay on IPv6:
https://consensus-health.torproject.org/consensus-health-2019-08-22-10-00.html#CE5ED345398CC02D573347C2F238F80B18E680EE

But your relay is still reachable over IPv4 from the 3 directory authorities
that don't have IPv6.

>> Please copy and paste the notice-level logs that tor creates on startup,
>> from launch to the end of the ORPort and DirPort reachability checks.

And your relay is reachable over IPv6 on its ORPort and DirPort from at least
one relay in the tor network.

It looks like your torrc matches your local network config.

>> Please copy and paste your torrc, particularly the Address, ORPort, DirPort,
>> and OutboundBindAddress options.

Your torrc looks correct.

>> It can be hard to set up IPv6 for a relay, we're working on a grant to make
>> it easier.

Tor doesn't do IPv6 reachability checks yet, that's part of the grant.

The only issue I can see is that all 6 directory authorities on IPv6 can't
reach your relay on IPv6.

Has your provider stopped routing your IPv6 address to your relay?
Does your provider censor Tor over IPv6?

It looks like the problem is somewhere between your relay machine and
the IPv6 internet.

T



signature.asc
Description: Message signed with 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 ipv6

[Станислав]

22.08.2019, 06:57, "teor" :
> Hi,
>
>>  On 21 Aug 2019, at 23:38, armik...@gmail.com wrote:
>>
>>  hi.in relay stopped working ipv6.address is correct all pings, including 
>> tor to the servers, but relay does not work.before that it worked perfectly 
>> 2 months.
>
> Please tell us your relay's fingerprint.
>
> Please copy and paste the notice-level logs that tor creates on startup,
> from launch to the end of the ORPort and DirPort reachability checks.
>
> Please copy and paste your torrc, particularly the Address, ORPort, DirPort,
> and OutboundBindAddress options.
>
> If we need your machines network config, we'll let you know.
>
> It can be hard to set up IPv6 for a relay, we're working on a grant to make
> it easier.
>
> T
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

CE5ED345398CC02D573347C2F238F80B18E680EE.

Aug 21 11:41:35.000 [notice] Tor 0.4.0.5 opening new log file.
Aug 21 11:41:34.967 [notice] Tor 0.4.0.5 running on Linux with Libevent 
2.1.8-stable, OpenSSL 1.1.1c, Zlib 1.2.11, Liblzma N/A, and Libzstd N/A.
Aug 21 11:41:34.967 [notice] Tor can't help you if you use it wrong! Learn how 
to be safe at https://www.torproject.org/download/download#warning
Aug 21 11:41:34.967 [notice] Read configuration file "/etc/tor/torrc".
Aug 21 11:41:34.996 [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.
Aug 21 11:41:34.997 [notice] Based on detected system memory, MaxMemInQueues is 
set to 2948 MB. You can override this by setting MaxMemInQueues by hand.
Aug 21 11:41:34.999 [notice] Opening Socks listener on 127.0.0.1:9050
Aug 21 11:41:34.999 [notice] Opened Socks listener on 127.0.0.1:9050
Aug 21 11:41:35.000 [notice] Opening OR listener on 0.0.0.0:443
Aug 21 11:41:35.000 [notice] Opened OR listener on 0.0.0.0:443
Aug 21 11:41:35.000 [notice] Opening OR listener on [2a03:e2c0:bc7::2]:443
Aug 21 11:41:35.000 [notice] Opened OR listener on [2a03:e2c0:bc7::2]:443
Aug 21 11:41:35.000 [notice] Opening Directory listener on 0.0.0.0:80
Aug 21 11:41:35.000 [notice] Opened Directory listener on 0.0.0.0:80
Aug 21 11:41:36.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip.
Aug 21 11:41:37.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
Aug 21 11:41:37.000 [notice] Configured to measure statistics. Look for the 
*-stats files that will first be written to the data directory in 24 hours from 
now.
Aug 21 11:41:38.000 [notice] Your Tor server's identity key fingerprint is 
'armik CE5ED345398CC02D573347C2F238F80B18E680EE'
Aug 21 11:41:38.000 [notice] Bootstrapped 0% (starting): Starting
Aug 21 11:42:17.000 [notice] Starting with guard context "default"
Aug 21 11:42:17.000 [notice] Bootstrapped 5% (conn): Connecting to a relay
Aug 21 11:42:17.000 [notice] Bootstrapped 10% (conn_done): Connected to a relay
Aug 21 11:42:17.000 [notice] Bootstrapped 14% (handshake): Handshaking with a 
relay
Aug 21 11:42:17.000 [notice] Guessed our IP address as 109.173.41.42 (source: 
131.188.40.189).
Aug 21 11:42:18.000 [notice] Bootstrapped 15% (handshake_done): Handshake with 
a relay done
Aug 21 11:42:18.000 [notice] Bootstrapped 75% (enough_dirinfo): Loaded enough 
directory info to build circuits
Aug 21 11:42:18.000 [notice] Bootstrapped 90% (ap_handshake_done): Handshake 
finished with a relay to build circuits
Aug 21 11:42:18.000 [notice] Bootstrapped 95% (circuit_create): Establishing a 
Tor circuit
Aug 21 11:42:20.000 [notice] Bootstrapped 100% (done): Done
Aug 21 11:42:20.000 [notice] Now checking whether ORPort 109.173.41.42:443 and 
DirPort 109.173.41.42:80 are reachable... (this may take up to 20 minutes -- 
look for log messages indicating success)
Aug 21 11:42:22.000 [notice] Self-testing indicates your DirPort is reachable 
from the outside. Excellent.
Aug 21 11:42:23.000 [notice] Self-testing indicates your ORPort is reachable 
from the outside. Excellent. Publishing server descriptor.
Aug 21 11:43:22.000 [notice] Performing bandwidth self-test...done.
Aug 21 17:42:17.000 [notice] Heartbeat: It seems like we are not in the cached 
consensus.
Aug 21 17:42:17.000 [notice] Heartbeat: Tor's uptime is 6:00 hours, with 0 
circuits open. I've sent 1.92 MB and received 6.28 MB.
Aug 21 17:42:17.000 [notice] Average packaged cell fullness: 87.497%. TLS write 
overhead: 20%
Aug 21 17:42:17.000 [notice] Circuit handshake stats since last time: 0/0 TAP, 
19/19 NTor.
Aug 21 17:42:17.000 [notice] Since startup we initiated 0 and received 0 v1 
connections; initiated 0 and received 0 v2 connections; initiated 0 and 
received 1 v3 connections; initiated 1 and received 6 v4 connections; initiated 
16 and received 186 v5 connections.
Aug 21 17:42:17.000 [notice] DoS mitigation since startup: 0 circuits killed 
with too many cells. 0 circuits rejected, 0 marked addresses. 0 c

Re: [tor-relays] tor relay ipv6

[teor]

Hi Paul,

> On 22 Aug 2019, at 14:26, Paul Templeton  wrote:
> 
>> It can be hard to set up IPv6 for a relay, we're working on a grant to make
>> it easier.
> 
> It could be helpful to do a request/survey to relay operators to find out 
> their experiences.
> That is those who have ipv6 configured what was the process and if there were 
> any problems in the process.
> For those who haven't yet configured ipv6 what is the barriers preventing 
> them from using ipv6.

Yes, I'd love to know what problems relay operators have with setting up IPv6.
I have some idea from helping people out, but hard data is more useful.

We tried to add a survey/advocacy component to the grant, but there wasn't
enough time in the grant budget.

Would you like to run a survey or start a mailing list thread?

> For me it was a problem at the ISPs end then it wasn't clear how to get 
> network config to use ipv6. I got the shits with it in the end and just used 
> iface eth0 inet6 dhcp. It works... LOL

Yeah it took me a while to learn how to set up IPv6 on Linux.
Most VPS providers don't do it automatically.

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

Re: [tor-relays] tor relay ipv6

[Paul Templeton]

> It can be hard to set up IPv6 for a relay, we're working on a grant to make
> it easier.

It could be helpful to do a request/survey to relay operators to find out their 
experiences.
That is those who have ipv6 configured what was the process and if there were 
any problems in the process.
For those who haven't yet configured ipv6 what is the barriers preventing them 
from using ipv6.

For me it was a problem at the ISPs end then it wasn't clear how to get network 
config to use ipv6. I got the shits with it in the end and just used iface eth0 
inet6 dhcp. It works... LOL

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

Re: [tor-relays] tor relay ipv6

[teor]

Hi,

> On 21 Aug 2019, at 23:38, armik...@gmail.com wrote:
> 
> hi.in relay  stopped working ipv6.address is correct all pings, including  
> tor to the servers, but  relay does not work.before that it worked perfectly 
> 2 months.

Please tell us your relay's fingerprint.

Please copy and paste the notice-level logs that tor creates on startup,
from launch to the end of the ORPort and DirPort reachability checks.

Please copy and paste your torrc, particularly the Address, ORPort, DirPort,
and OutboundBindAddress options.

If we need your machines network config, we'll let you know.

It can be hard to set up IPv6 for a relay, we're working on a grant to make
it easier.

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

Re: [tor-relays] Tor Relay - RelayBandwidthRate vs. RelayBandwidthBurst

[teor]

Hi,

> On 20 Aug 2019, at 20:23, petra...@protonmail.ch wrote:
> 
> I'm struggling a bit with the two config options for RelayBandwidthRate and 
> RelayBandwidthBurst - what I currently have in my torrc config file is:
> 
> ...
> RelayBandwidthRate  8 Mbit
> RelayBandwidthBurst 12 Mbit
> ...
> 
> My assumption was that on average the Relay would consume 8 Mbps max. but 
> over a shorter period of time also up to 12 Mbps in case needed.
> What I see (historical monitor data at 10 s intervals for the past 6 months) 
> is that the bandwidth usage never exceeds 8 Mbps. I can also see the 
> consumption to be levelled out at 8 Mbps for minutes or hours so it looks 
> like there would be a need for more bandwidth.

Yes the Tor network does need more bandwidth, particularly for exits.

> My question: why can't I see the bandwidth usage going above 8 Mbps and 
> making use of the allowed burst? Btw, I'm typically using the latest stable 
> tor, currently the relay is on 0.4.0.5.

The burst is over a very short period of time.
I think it's about 1 second.

The rate is averaged is over a slightly longer period of time, and
includes any burst bandwidth. That is, if the bandwidth burst to
12 Mbps in the last second, the bandwidth in this second will be
4 Mbps. The lower bandwidth in the next second keeps the average to
8 Mbps.

T

--
teor
--



signature.asc
Description: Message signed with 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 has low consensus weight

[nottryingtobelame]

It is normal for a relay to take some time to come up to its full speed. The 
only issue I can think of would be if you have something else hogging 
bandwidth. I couldn't figure out why my year-old relay's advertised bandwidth 
was dropping significantly until I realized someone else was running torrents 
on the same router and using most of the upload bandwidth. Someone more 
knowledgeable may be able to clarify further.

‐‐‐ Original Message ‐‐‐
On Saturday, August 3, 2019 2:38 PM, Piers  wrote:

> Hi, i have been running a tor relay (link: 
> https://metrics.torproject.org/rs.html#details/858BEC79D7355EC0631E98D47CF14B576BFD6D0F)
>  on a raspberry pi 2 for 15 days, however i think there might be a problem 
> with it. My consensus weight is only 43 and thus the relay doesn't get used 
> much. Please advise if there is an issue
>
> --
> Many thanks,
> -Piers___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor relay has low consensus weight

[teor]

Hi,

We get this question a lot.

> On 4 Aug 2019, at 00:38, Piers  wrote:
> 
> Hi, i have been running a tor relay (link: 
> https://metrics.torproject.org/rs.html#details/858BEC79D7355EC0631E98D47CF14B576BFD6D0F)
>  on a raspberry pi 2 for 15 days, however i think there might be a problem 
> with it. My consensus weight is only 43 and thus the relay doesn't get used 
> much. Please advise if there is an issue
> 
There are lots of reasons why relays are slow. Maybe your relay can't do
Tor's cryptography fast enough on its CPU?

We've noticed similar issues with other Raspberry Pi 2 relays.

Try reading this problem-solving guide, and let us know how you go:
https://trac.torproject.org/projects/tor/wiki/doc/MyRelayIsSlow

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

Re: [tor-relays] Tor relay operators meetup, 25/05/2019 @ RADIX hacklab, Athens

[Vasilis]

Hi,

The public notes of the event can be found here:
https://trac.torproject.org/projects/tor/wiki/org/meetings/AthensMeetupMay19

Thanks to everyone for joining.


Cheers,
~Vasilis
-- 
Fingerprint: 8FD5 CF5F 39FC 03EB B382 7470 5FBF 70B1 D126 0162
Pubkey: https://pgp.mit.edu/pks/lookup?op=get&search=0x5FBF70B1D1260162



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 Meeting at the Gulaschprogrammiernacht

[Christophe Kemp]

Hello everyone,

the Meetup will be this saturday from 17:45 to 18:45 o'clock at the ZKM
CodeHUB.

Best regards

Chrëscht

International Ambassador

Frënn vun der Ënn A.S.B.L.

Am 19.05.19 um 11:00 schrieb Christophe Kemp:
> Hello everyone,
>
> there will be a Tor Relay Operator Meeting at the Gulaschprogrammiernacht :)
>
> You will find soon more information here: https://entropia.de/GPN
>
> See you there!
>
> Best regards
>
> Chrëscht
>
> International Ambassador
>
> Frënn vun der Ënn A.S.B.L
>
>
> ___
> 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 says it is reachable, but is not appearing on the network.

[Keifer Bly]

Hi, so I am now auto upgrading tor using the method at
https://trac.torproject.org/projects/tor/wiki/TorRelayGuide/DebianUbuntuUpdates


Upon testing, this is what I got.



 Initial blacklisted packages:
Initial whitelisted packages:
Starting unattended upgrades script
Allowed origins are: []
Checking: firefox-esr ([])
Checking: google-cloud-sdk ([])
Checking: google-compute-engine ([])
Checking: google-compute-engine-oslogin ([])
Checking: libavcodec57 ([])
Checking: libavfilter6 ([])
Checking: libavformat57 ([])
Checking: libavresample3 ([])
Checking: libavutil55 ([])
Checking: libpostproc54 ([])
Checking: libswresample2 ([])
Checking: libswscale4 ([])
Checking: python-google-compute-engine ([])
Checking: python3-google-compute-engine ([])
pkgs that look like they should be upgraded:
Fetched 0 B in 0s (0 B/s)

fetch.run() result: 0
blacklist: []
whitelist: []
No packages found that can be upgraded unattended and no pending
auto-removals

What I am attempting to do is automatically install new tor versions when
they are released. Will this do that automatically? How can I keep this
process running? Thanks.

--Keifer


On Fri, May 24, 2019 at 12:38 AM Conrad Rockenhaus 
wrote:

> Hello,
>
> My bust, confirmation bias.
>
> Thanks,
>
> Conrad
>
> On Thu, May 23, 2019 at 11:45 PM teor  wrote:
>
>> Hi,
>>
>> > On 24 May 2019, at 14:08, Conrad Rockenhaus 
>> wrote:
>> >
>> > In April 2018 Google released an update that caused VPNs and Tor
>> services to stop working on GCE and App Engine. It was a long planned
>> network update.
>> >
>> > The following ticket refers:
>> https://trac.torproject.org/projects/tor/ticket/25804
>>
>> That ticket is about domain-fronting, which is used by meek and snowflake
>> bridges.
>> But these issues do not affect other relays.
>>
>> Do you have any information about Google blocking relays?
>>
>> T
>> ___
>> tor-relays mailing list
>> tor-relays@lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>
> --
> Conrad Rockenhaus
> https://www.rockenhaus.com
> Cell: (254) 292-3350
> Fax: (254) 875-0459
> ___
> 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 says it is reachable, but is not appearing on the network.

[Conrad Rockenhaus]

Hello,

My bust, confirmation bias.

Thanks,

Conrad

On Thu, May 23, 2019 at 11:45 PM teor  wrote:

> Hi,
>
> > On 24 May 2019, at 14:08, Conrad Rockenhaus 
> wrote:
> >
> > In April 2018 Google released an update that caused VPNs and Tor
> services to stop working on GCE and App Engine. It was a long planned
> network update.
> >
> > The following ticket refers:
> https://trac.torproject.org/projects/tor/ticket/25804
>
> That ticket is about domain-fronting, which is used by meek and snowflake
> bridges.
> But these issues do not affect other relays.
>
> Do you have any information about Google blocking relays?
>
> T
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
-- 
Conrad Rockenhaus
https://www.rockenhaus.com
Cell: (254) 292-3350
Fax: (254) 875-0459
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor relay says it is reachable, but is not appearing on the network.

[teor]

Hi,

> On 24 May 2019, at 11:41, Keifer Bly  wrote:
> 
> Hi all, so I believe I found the problem. In my torrc file, there was a rogue 
> line which read "PublishServerDescriptor" with nothing after it. I removed 
> this line and restarted the relay, now it is saying "May 24 01:38:16.000 
> [notice] Self-testing indicates your ORPort is reachable from the outside. 
> Excellent. Publishing server descriptor.
> May 24 01:38:20.000 [notice] Performing bandwidth self-test...done."
> 
> So it seems this solved the problem.

It looks like your relay changed keys about 2 hours ago:
https://metrics.torproject.org/rs.html#search/torworld

If you keep changing your relay keys, it won't be used very much.

> Now, I am also wondering, is there a tool that can be used to automatically 
> update tor? Thank you.

Yes!

From my last email:

>>> When I tried updating tor I got a message saying that was the
>>> newest version.
>> 
>> It looks like you're on Debian or Ubuntu, please follow these instructions
>> to update:
>> https://2019.www.torproject.org/docs/debian.html.en

>>> May 21 20:01:32.000 [warn] You are running Tor as root. You don't need to, 
>>> and you probably shouldn't.
>> 
>> I don't know how you are configuring and running your relay. Using a guided
>> relay configuration tool might help you. See my suggestion below.

>> You seem to have a lot of trouble configuring relays manually.
>> You might have a better experience with a guided setup tool, like this
>> Tor Relay role in Ansible:
>> https://github.com/nusenu/ansible-relayor

I really think that something like ansible is your best chance of having a
working relay.

T



signature.asc
Description: Message signed with 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 says it is reachable, but is not appearing on the network.

[teor]

Hi,

> On 24 May 2019, at 14:08, Conrad Rockenhaus  wrote:
> 
> In April 2018 Google released an update that caused VPNs and Tor services to 
> stop working on GCE and App Engine. It was a long planned network update.
> 
> The following ticket refers: 
> https://trac.torproject.org/projects/tor/ticket/25804

That ticket is about domain-fronting, which is used by meek and snowflake 
bridges.
But these issues do not affect other relays.

Do you have any information about Google blocking relays?

T


signature.asc
Description: Message signed with 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 says it is reachable, but is not appearing on the network.

[Conrad Rockenhaus]

Hi,

I apologize for top posting, but it’ll be the simplest way to convey the 
message.

In April 2018 Google released an update that caused VPNs and Tor services to 
stop working on GCE and App Engine. It was a long planned network update.

The following ticket refers: 
https://trac.torproject.org/projects/tor/ticket/25804

Thanks,

Conrad

> On May 23, 2019, at 8:15 PM, teor  wrote:
> 
> Hi,
> 
>> On 24 May 2019, at 09:19, Keifer Bly  wrote:
>> 
>> Hi all, so this is the tor log since the last restart. It includes the relay 
>> fingerprint. The tor version is (0.2.9.16-1).
> 
> The log you posted is missing a few lines at the start, including the lines
> that tell us the tor version.
> 
> We need to see the tor version that is *running*, not the tor version that
> you installed. Just in case they are different. (Authorities reject really old
> Tor versions.)
> 
>> When I tried updating tor I got a message saying that was the
>> newest version.
> 
> It looks like you're on Debian or Ubuntu, please follow these instructions
> to update:
> https://2019.www.torproject.org/docs/debian.html.en
> 
>> The relay has an assigned static ip and port which are both allowed by the 
>> firewall. It seems strange that
>> Dmitrii Tcvetkov was able to reach the relay though teor cannot,
> 
> We looked in different places:
> 
> Dmitrii connected to the IP and ports of your relay using SSL.
> I looked for your relay in the votes and the consensus, but I did not find it.
> 
>> also that the relay says it is reachable and receiving traffic but not 
>> appearing in the relay list.
> 
> I think your relay is not publishing its descriptor. See my comments below
> about the relay log.
> 
>> It seems like the relay
>> would not be able to start at all if Google was blocking it.
> 
> There are lots of different ways to block relays. Some let the relay start, 
> but
> it never gets in the consensus. But I don't think that has happened to your
> relay.
> 
>> May 21 20:01:32.000 [warn] You are running Tor as root. You don't need to, 
>> and you probably shouldn't.
> 
> I don't know how you are configuring and running your relay. Using a guided
> relay configuration tool might help you. See my suggestion below.
> 
>> May 21 20:01:33.000 [notice] Your Tor server's identity key fingerprint is 
>> 'torworld 3A4E582092E7C6B822EC01F4D76F680F6C65B0A2'
> 
> I have confirmed that this fingerprint is not in the votes or consensus.
> 
>> May 21 20:01:33.000 [notice] Bootstrapped 0%: Starting
>> May 21 20:03:53.000 [notice] Bootstrapped 80%: Connecting to the Tor network
>> May 21 20:03:54.000 [notice] Guessed our IP address as 104.154.93.253 
>> (source: 128.31.0.34).
> 
> 128.31.0.34 is the IP address of moria1, so your relay can connect to the 
> directory
> authorities. That means that Google isn't blocking connections out.
> 
>> May 21 20:03:58.000 [notice] Bootstrapped 100%: Done
>> May 21 20:03:58.000 [notice] Now checking whether ORPort 
>> 104.154.93.253:65534 is reachable... (this may take up to 20 minutes -- 
>> lookfor log messages indicating success)
>> May 21 20:04:01.000 [notice] Self-testing indicates your ORPort is reachable 
>> from the outside. Excellent.
> 
> Your relay and Dmitrii have confirmed that this port is reachable from the
> outside.
> 
> But your relay log does not say "Publishing server descriptor." That's why 
> your
> relay is not in the votes or the consensus.
> 
> So we need to answer these questions:
> * Is your relay configured as a bridge?
> * Is your relay configured to *not* publish its descriptor?
>  (Relays publish their descriptors by default.)
> 
> Please copy and paste your torrc into your next email.
> 
> Your logs were also missing these things:
> 
>> * tor version,
>> * role (relay or bridge), and
>> * descriptor posts to authorities.
> 
> Please post the parts of your logs that contain this information.
> There is no need to paste more than 2 repetitions of the
> Heartbeat/Cell/Circuit/Connection/DoS lines.
> 
> You seem to have a lot of trouble configuring relays manually.
> You might have a better experience with a guided setup tool, like this
> Tor Relay role in Ansible:
> https://github.com/nusenu/ansible-relayor
> 
> T
> 
>> On Thu, May 23, 2019 at 2:09 PM teor  wrote:
>> 
>> On 23 May 2019, at 18:41, Dmitrii Tcvetkov  wrote:
>> 
>>> On Tue, 21 May 2019 23:36:28 -0700
>>> Keifer Bly  wrote:
>>> 
 Hi, so the relay in question does indeed have a reserved Static IP
 (104.154.93.253), and the traffic is allowed by the firewall, but the
 relay is still not appearing in the consensus. The port it's running
 on is 65534. This is starting to seem odd.any thoughts are
 appreciated. Thanks. --Keifer
 
>>> 
>>> Indeed, I don't have any problem connecting to your relay with openssl
>>> from multiple locations (at least Russia, Netherlands and Germany):
>>> 
>>> 
>>> $ openssl s_client -connect 104.154.93.253:65534
>>> 
>>> Certificate chain
>>> ...
>> 
>> I can't find a relay 

Re: [tor-relays] Tor relay says it is reachable, but is not appearing on the network.

[Keifer Bly]

Hi all, so I believe I found the problem. In my torrc file, there was a
rogue line which read "PublishServerDescriptor" with nothing after it. I
removed this line and restarted the relay, now it is saying "May 24
01:38:16.000 [notice] Self-testing indicates your ORPort is reachable from
the outside. Excellent. Publishing server descriptor.
May 24 01:38:20.000 [notice] Performing bandwidth self-test...done."

So it seems this solved the problem. Now, I am also wondering, is there a
tool that can be used to automatically update tor? Thank you.

--Keifer


On Thu, May 23, 2019 at 6:16 PM teor  wrote:

> Hi,
>
> > On 24 May 2019, at 09:19, Keifer Bly  wrote:
> >
> > Hi all, so this is the tor log since the last restart. It includes the
> relay fingerprint. The tor version is (0.2.9.16-1).
>
> The log you posted is missing a few lines at the start, including the lines
> that tell us the tor version.
>
> We need to see the tor version that is *running*, not the tor version that
> you installed. Just in case they are different. (Authorities reject really
> old
> Tor versions.)
>
> > When I tried updating tor I got a message saying that was the
> > newest version.
>
> It looks like you're on Debian or Ubuntu, please follow these instructions
> to update:
> https://2019.www.torproject.org/docs/debian.html.en
>
> > The relay has an assigned static ip and port which are both allowed by
> the firewall. It seems strange that
> > Dmitrii Tcvetkov was able to reach the relay though teor cannot,
>
> We looked in different places:
>
> Dmitrii connected to the IP and ports of your relay using SSL.
> I looked for your relay in the votes and the consensus, but I did not find
> it.
>
> > also that the relay says it is reachable and receiving traffic but not
> appearing in the relay list.
>
> I think your relay is not publishing its descriptor. See my comments below
> about the relay log.
>
> > It seems like the relay
> > would not be able to start at all if Google was blocking it.
>
> There are lots of different ways to block relays. Some let the relay
> start, but
> it never gets in the consensus. But I don't think that has happened to your
> relay.
>
> > May 21 20:01:32.000 [warn] You are running Tor as root. You don't need
> to, and you probably shouldn't.
>
> I don't know how you are configuring and running your relay. Using a guided
> relay configuration tool might help you. See my suggestion below.
>
> > May 21 20:01:33.000 [notice] Your Tor server's identity key fingerprint
> is 'torworld 3A4E582092E7C6B822EC01F4D76F680F6C65B0A2'
>
> I have confirmed that this fingerprint is not in the votes or consensus.
>
> > May 21 20:01:33.000 [notice] Bootstrapped 0%: Starting
> > May 21 20:03:53.000 [notice] Bootstrapped 80%: Connecting to the Tor
> network
> > May 21 20:03:54.000 [notice] Guessed our IP address as 104.154.93.253
> (source: 128.31.0.34).
>
> 128.31.0.34 is the IP address of moria1, so your relay can connect to the
> directory
> authorities. That means that Google isn't blocking connections out.
>
> > May 21 20:03:58.000 [notice] Bootstrapped 100%: Done
> > May 21 20:03:58.000 [notice] Now checking whether ORPort
> 104.154.93.253:65534 is reachable... (this may take up to 20 minutes --
> lookfor log messages indicating success)
> > May 21 20:04:01.000 [notice] Self-testing indicates your ORPort is
> reachable from the outside. Excellent.
>
> Your relay and Dmitrii have confirmed that this port is reachable from the
> outside.
>
> But your relay log does not say "Publishing server descriptor." That's why
> your
> relay is not in the votes or the consensus.
>
> So we need to answer these questions:
> * Is your relay configured as a bridge?
> * Is your relay configured to *not* publish its descriptor?
>   (Relays publish their descriptors by default.)
>
> Please copy and paste your torrc into your next email.
>
> Your logs were also missing these things:
>
> > * tor version,
> > * role (relay or bridge), and
> > * descriptor posts to authorities.
>
> Please post the parts of your logs that contain this information.
> There is no need to paste more than 2 repetitions of the
> Heartbeat/Cell/Circuit/Connection/DoS lines.
>
> You seem to have a lot of trouble configuring relays manually.
> You might have a better experience with a guided setup tool, like this
> Tor Relay role in Ansible:
> https://github.com/nusenu/ansible-relayor
>
> T
>
> > On Thu, May 23, 2019 at 2:09 PM teor  wrote:
> >
> > On 23 May 2019, at 18:41, Dmitrii Tcvetkov  wrote:
> >
> >> On Tue, 21 May 2019 23:36:28 -0700
> >> Keifer Bly  wrote:
> >>
> >>> Hi, so the relay in question does indeed have a reserved Static IP
> >>> (104.154.93.253), and the traffic is allowed by the firewall, but the
> >>> relay is still not appearing in the consensus. The port it's running
> >>> on is 65534. This is starting to seem odd.any thoughts are
> >>> appreciated. Thanks. --Keifer
> >>>
> >>
> >> Indeed, I don't have any problem connecting to your relay with open