Hi,
> if i have these relays running it kills a 10Gbps fiber optic line
this sounds like a configuration issue on your router, relays tend to
establish tons of concurrent connections and some routers either can't
handle it or think it's some sort of attack - especially if you run
three relays
Hi,
this can take a few days at most (took around 3-4 days for a relay I
once managed), do a hard-refresh to be sure it isn't cached data in
your browser.
- William
On 09/04/2021, Kathi wrote:
> I changed the name of my relay nick name from to (Correct
> Name) after
> I got it to
Hi,
I'm pretty sure that this error is emitted because Tor parses the
address "as is" and doesn't remove the spaces, so try specifying your
addresses like this:
ORPort 37.157.195.83:38619
ORPort [2a02:2b88:2:1::3239:0]:38619
I'm pretty sure that this will fix your problem.
- William
On
It might not belong to Liberty Global itself even though it was
registered as such but to one of their subsidiaries, likely Virgin
Media or Vodafone.
Random SSH probes happen very frequently, it's nothing to worry about
if you deny root login, force public key (Ed25519 if your version of
sshd
Don't use either, Scaleway now owns Online S.A.S which is also on the
list of ISP's to avoid.
Also avoid Hetzner and DigitalOcean.
- William
On 03/04/2021, Андрей Гвоздев wrote:
> Which ISP is better? Scaleway or OVH?
> ___
> tor-relays mailing list
Hi,
Only allow public key authentication (preferably avoiding RSA, DSA and
ECDSA keys and just going for an Ed25519 one), disabling root login
and then creating an unprivileged user to work on the machine which
will be added to the AllowUsers directive in sshd_config will make
brute-forcing
tps://gitlab.torproject.org/tpo/core/tor/-/issues/40253
I'd advise against such firewall rules and let tor handle it.
- William
On 24/02/2021, Toralf Förster wrote:
> On 2/22/21 7:29 PM, William Kane wrote:
>> A hard limit of 9 might be a little too low - then again, a legit,
>> unm
/2021, Keifer Bly wrote:
> Would running a bridge on ovh be ok? Thanks.
> --Keifer
>
>
> On Thu, Apr 1, 2021 at 1:29 AM William Kane
> wrote:
>
>> Hi,
>>
>> no, OVH is the second most commonly used hosting provider, another
>> relay hosted there w
Hi,
no, OVH is the second most commonly used hosting provider, another
relay hosted there would hurt the network more than it would help:
https://metrics.torproject.org/bubbles.html#as
We need to make the network as diverse as possible, in order to make
it as hard as possible for law
Hi Isaac,
First of all, congratulations on becoming a father!
Any help with the GoodBadISPs document is heavily appreciated.
One particularly helpful piece of data would be the number of Tor
nodes already running under any given autonomous system - making it
easier for the soon-to-be relay
Also, more information would be nice - just some "Please shut down all
of your relays, because I / they have a problem with X" isn't very
descriptive.
Just did some own research:
"The group recently reappointed the controversial developer and
activist to its board; he had previously departed in
>So while I'd share your belief that Tor project should stay out of this, or
>better yet, support >RMS, shutting down nodes seems like taking out your
>punishment on the innocent ones.
This, we already have only a handful of nodes, and even fewer exit
nodes, please don't make the situation
ace, in my opinion making them bad relays -
right now my relay only takes place as a middle in a circuit, so
figuring out the guard is possible (not considering the onion service
scenario right now).
- William
On 23/03/2021, Roger Dingledine wrote:
> On Mon, Mar 22, 2021 at 07:54:43PM +,
@tor-relays:
Sorry for being quite noisy recently but I really need to know how
many people are suffering from the same madness I am encountering
right now.
Quick excerpt from the log:
...
Mar 22 09:48:10 tor[pid_redacted]: Mar 22
09:48:10.000 [warn] Your computer is too slow to handle this
Hi,
Change hosting providers?
Even C3WEyeOfSauron suffers frequent downtimes, and I figured it's the
same host.. not really optimum conditions for running tor relays.
Regards,
William
2021-03-17 13:29 GMT, MacLemon :
> Hi!
>
> FYI: We sadly have to sunset two of our relays due to persistent
>
3-16 11:09 GMT, Peter Gerber :
> Hi William
>
> William Kane:
>> Hi Peter,
>>
>>> Would be great if you could get details about the failing call.
>>
>> I already thought of gathering said details by tracing the process,
>> but did not want to risk my uptime
d figure out why this is
happening, I'm pretty good at C/C++ on Linux / Windows and all the
shenanigans that come with it, but lack time to debug this further.
I've added tor-...@lists.torproject.org as a CC just in case.
- William
2021-03-15 17:10 GMT, Peter Gerber :
> Hi William
>
> William Kane:
&
Hi everyone,
Ever since I upgraded to tor version 0.4.5.6, enabling tor's built-in
seccomp sandbox completely breaks tor, i.e. it gets killed by the
kernel on start for a seccomp violation (fstat(..)) - sandboxing
worked fine on 0.4.4.6, my system configuration did not change between
the updates.
On-topic:
That is the most ridiculous bullshit I've heard this entire year, why
does PayPal even care what you host on your servers, especially when
you are just re-routing traffic? I'm wondering if this is even legal,
sure they have the right to refuse service to anyone, but banning
someone
rent a KVM machine for ~10
bucks with two static IPv4 and IPv6 addresses, it would greatly
increase the value of his tor relay if he also pays attention to
network diversity while choosing a DC.
Just my opinion :p
William
2021-03-11 17:16 GMT, s7r :
> On 3/10/2021 5:31 PM, William Kane wrote:
&g
Hi,
manually specify IP and port, and set the IPv4Only flag for both
ORPort and DirPort.
Reference: https://2019.www.torproject.org/docs/tor-manual.html.en
William
2021-03-09 21:53 GMT, Marco Predicatori :
> s7r wrote on 3/9/21 3:12 PM:
>> Please paste your entire torrc (without any sensitive
That's the one I meant, thanks.
William
2021-03-08 19:08 GMT, Eddie :
> As well as the keys, be sure to also move/copy the pt_state folder and
> contents.
>
> Cheers.
>
>
> On 3/8/2021 8:07 AM, William Kane wrote:
>> Hi,
>>
>> Every bridge is usefu
Hi,
Every bridge is useful, and a possible chance for a tor user to
circumvent censorship, you can't possibly know which bridges are
already blocked for a user, so every bridge in the network counts -
looking at your graphs, on average 50 people are connected to it,
compared to other bridges,
Hi,
This should help you:
https://2019.www.torproject.org/docs/tor-manual.html.en
Installing nyx should also pull in all required packages for it to
work, as long as the ControlPort and CookieAuthentication variables
are configured correctly and nyx is ran under the same user tor is
running
it..
- William
2021-02-24 23:44 GMT, Eddie :
> On 2/24/2021 12:34 PM, William Kane wrote:
>> Thank you for running obfs4 bridges with iat_mode != 0, only very few
>> obfs4 bridges support the additional traffic obfuscation in both
>> directions.
>>
>> Kudos to you my friend
hich
addresses it's supposed to bind to anyway :-)
Thank you for running a relay!
Best Regards,
William
2021-03-01 12:49 GMT, William Kane :
> Hi Matt,
>
> this is non fatal and as you can see by the most recent log entries,
> you could ignore it - anyway, some contributor warned about
Thank you for running obfs4 bridges with iat_mode != 0, only very few
obfs4 bridges support the additional traffic obfuscation in both
directions.
Kudos to you my friend.
- William
2021-02-23 1:18 GMT, torjoy :
> Hi All,
>
> I work with time and frequency references and run some tor bridges.
>Are there any objections against this approach?
A hard limit of 9 might be a little too low - then again, a legit,
unmodified tor binary would hold it's TCP connection established for
as long as needed - so maybe this will block some of the attacks, but
it's very basic - I'd try to go with a
time, it
dips down to 16mbit/s for many minutes - not sure if this is the
attacker or simply tor compressing consensus documents.. log still
spamming the warning mentioned above.
Best Regards,
William
2021-02-04 17:51 GMT, William Kane :
> Hi community,
>
> Unfortunately my otherwise s
Hi community,
Unfortunately my otherwise stable tor guard relay has recently lost
it's guard flag, once again, due to what I think is a new type of
(D)DoS attack, either directly targeted towards my tor relay, or
against some other relays inside the network, facilitated through my
relay.
It all
Permissions issue of /var/lib/tor / DataDirectory most likely, and Tor
can't fix it itself since it's likely owned by root, however the
systemd unit starts it under a separate user.
2021-01-22 12:03 GMT, Patrice Bönig :
> Hi @ list,
>
> I am operating a relay for several years and I really do
Took 15 days the last time you lost it.. nothing you can do but wait, anyway.
William
2021-01-25 10:53 GMT, raltul...@posteo.org :
> Hi Matt, thank you for the reply.
>
> I restarted the server since I hoped it would fix the underlying problem
> but I don't it did.
> I'll wait for 7 days as you
I get around 6-8k PPS on my node pushing around 65-70MBit/s - 450k
seems (very) excessive even though your node has 6 times the capacity
and load of my node.
I constantly see other relay operators complaining about D(D)oS
attacks on this mailing list, so this could be a legitimate attack.
Could
Minor complaint apart from the good job you've done already: The
overlap on the top right side, as pointed out in the attachment, bugs
the hell out of me.
Otherwise, a solid idea and improvement.
William
2021-01-13 21:40 GMT, nusenu :
>> OK. Unfortunately I can only redirect in private
Happened to me a few times, usually depends on AS, location and some
more internal factors.
2020-12-15 1:39 GMT, enrollado :
> Hello all.
>
> I started an exit relay on Saturday. Last night I took a look at the log and
> I saw something like 30 active circuits at the heartbeat and the relay had
>
Forwarding to mailing list since OP has replied to my e-mail address,
and not the list.
-- Forwarded message --
From: William Kane
Date: Mon, 23 Nov 2020 16:07:39 +
Subject: Re: Re: [tor-relays] Bridges under DDoS
To: BRBfGWMz
Dear BRBfGWMz, you can use this script I made
If your server is not responding, no harm done (likely already done if
you have iptables set up to drop unknown (established flag not set)
incoming traffic.).
If it's somehow maxing out your connection speed, then time to talk to
your upstream provider / hosting company - very likely they already
A few days up to a week, some service operators might only fetch IP's
from the Tor relay pool once every weeks or even months though, so the
IP being on Metrics is completely irrelevant.
I'd say at least 3-6 months until you reach a state where most sites
have un-blocked your IP - some might
>The provider said it was due to Spectre mitigations and the only way for me
to fix this would be to switch to a newer (more expensive) plan...
What?
Your provider lied to you / scammed you, Spectre/Meltdown etc.
mitigations have nothing to do with applications freezing or having to
get a faster
Vigilance is always needed and appreciated, both manual and automated.
Stripping encryption only works when there's a non encrypted port
available, in the case of SMTPS / IMAPS / SSH it's not possible.
As for the other questions, I can't really answer them.
2020-09-28 21:00 GMT, Corl3ss :
>
We should at some point probably look into banning or de-prioritizing
relays hosted under the 4 AS's listed above, given enough network
capacity.
Or maybe only allow x% of guard / middle / exit fraction per AS and
then de-prioritize.
2020-08-24 21:17 GMT, nusenu :
> Hello CypherpunkLabs,
>
> I
Dear Josh,
thank you for running a Tor relay, but I have one concern:
If your IPv6 configuration randomly "stops working", and in order to
fix it, you have to restart your entire networking equipment, then
this is going to affect many clients - even if your Consensus Weight
equals the one of a
While I never used unbound, but only the PowerDNS recursor on my exit
nodes, I always set the number of threads to the amount of logical CPU
cores and let the linux scheduler do the rest.
Best Regards,
William Kane
2020-08-22 7:12 GMT, Toralf Förster :
> I do wonder about a reasonable num
Most of the relays from the first group got added at the exact same
time, the second group got added within a few days - tells me someone
looking at the OrNetRadar logs isn't doing his job correctly.
2020-08-19 16:27 GMT, nusenu :
> niftybunny:
>>
I knew about this issue years ago, but there's not much I can do to
mitigate it except for spinning up more, legit Tor exit instances to
try and limit the probability of an attack happening to a user.
We need way more legitimate relays, and not just on OVH, Hetzner and
Online's up streams which
Yes, maximum is 2 relays on one IP.
2020-08-13 5:42 GMT, Keifer Bly :
> Hi,
>
>
>
> So my relay at
> https://metrics.torproject.org/rs.html#details/79E3B585803DE805CCBC00C1EF36B1E74372861D
>
>
>
> And my bridge at
>
!
William :-)
2020-08-10 15:59 GMT, Sebastian Hahn :
> Hi William,
>
> you failed to take into account the algorithm that weighs more frequent
> downtime more than less recent downtime. You seem to have just
> extrapolated linearly.
>
> Cheers
> Sebastian
>
>> On 8.
Never mind - looks like I got my guard flag back now, yay!
Thanks so much for the help everyone.
William
2020-08-06 0:45 GMT, William Kane :
> 2145977 of 2190729 are 97.96%.. if it's really changing that slowly,
> it's gonna take at least another 32 days, seeing that it took 8 days
> t
I already explained this to you - from my own experience in running
tor relays (8+ years) it can take 6 months up to 1 year until the
relays are fully used, and some relays for some reason just never ramp
up properly for various reasons.
2020-08-06 16:13 GMT, Neel Chauhan :
> Hi
ite.. dumb mistake on my
end.
Thank you and have a great weekend everyone.
2020-08-05 19:27 GMT, Sebastian Hahn :
>
>> On 5. Aug 2020, at 17:25, William Kane wrote:
>>
>> Strange, it's still missing the Guard flag after 8 days of consecutive
>> uptime - maybe I'm just
really want my Guard flag back :-(
2020-08-01 11:24 GMT, li...@for-privacy.net :
> On 31.07.2020 14:41, William Kane wrote:
>
>> That was very informative and educational compared to the other
>> replies.
> +1
>
> On 29.07.2020 05:21, ECAN - Matt Westfall wrote
I think this is related to available file system descriptors.
Try increasing the number of descriptors, around 8192 should be fine
for most relays.
If running systemd, edit the service (systemctl edit )
and append the following, then restart:
[Service]
LimitNOFILE=8192
You might also need to
Thank you!
That was very informative and educational compared to the other replies.
Best Regards,
William Kane
2020-07-29 3:18 GMT, Sebastian Hahn :
> Hi William,
>
>> On 29. Jul 2020, at 00:45, Matt Traudt wrote:
>>
>> The Guard flag conditions are
>> https://git
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
, I please ask for it to be
resolved - however, if it's the Directory Authorities disqualifying my
relay, then there's nothing to be done except to wait.
Greetings,
William Kane
___
tor-relays mailing list
tor-relays@lists.torproject.org
https
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 +
>>
Clients can and will fetch directory information over the ORPort, right?
If so, then count me in:
https://metrics.torproject.org/rs.html#details/47E1157F7DA6DF80EC00D745D73ACD7B0A380BCF
2020-07-19 19:45 GMT, jvoisin :
>
> Nos oignons' relays:
>
> F47B 13BF CE4E F48C DEF6 C4D7 C7A9 9208 EBB9
Which you can answer with a template document, stating that you are
not responsible for the traffic and that you, as the ISP / network
provider are protected by law, and can not be held responsible for
data passing through your routers.
2020-07-19 4:41 GMT, John Ricketts :
> I have received more
How do you define abusive traffic?
Do analyze dumps of your network traffic?
Is your ISP sending more abuse letters than usual?
If the latter, then it might just be a fluke - when I ran exits, the
same thing happened - one month 17 abuse reports, the other month
193.. nothing you can do about
Tor already has code that avoids having multiple nodes from a single
/16 range or from the same AS (correct me on that one if I'm wrong,
not totally sure about it) in the same circuit, so as long as your
MyFamily setting is set correctly, I see no problem here.
Throughput is important as you will
it at
/etc/security/limits.conf.
Don't forget to reboot.
2020-06-20 13:10 GMT, William Kane :
> Tor already has code that avoids having multiple nodes from a single
> /16 range or from the same AS (correct me on that one if I'm wrong,
> not totally sure about it) in the same circuit, s
It can take up to 6 months in my experience until a relay is fully
utilized, and some just never never reach peak bandwidth throughput
for whatever reason.
2020-06-13 5:51 GMT, Neel Chauhan :
> Hi tor-relays@,
>
> I run a FreeBSD-based Tor relay across two instances on "Wave G", a
> Gigabit ISP
ould 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
. 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,
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
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 re
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
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 rec
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 u
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.
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
>> randoml
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
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
73 matches
Mail list logo
