On 10/30/24 16:01, Pierre Bourdon wrote:
(props on them, I didn't send it to them myself!).
I replied to an Hetzner email at 10/29/24, 08:55 +0100 and pointed them
to this thread.
--
Toralf
OpenPGP_signature.asc
Description: OpenPGP digital signature
___
On 10/29/24 04:33, Pierre Bourdon wrote:
A few hours ago I received a forwarded abuse report from Hetzner for
one of my machines running a Tor relay (not exit).
Fun fact - the abuse email is in HTML format.
No comment.
--
Toralf
___
tor-relays mailin
On 10/29/24 04:33, Pierre Bourdon wrote:
Some tcpdumps showing random RSTs coming back to my machines running
relays (with no traffic being initiated by said machines beforehand):
You used somethign like this? :
tcpdump -i enp8s0 'tcp[13] & 4 != 0 && port 22'
--
Toralf
___
On 10/2/24 17:43, meskio wrote:
I think best right now is to configure them to be distributed over "settings".
As this is what will be automatically used by Tor Browser and other clients.
Thx.
--
Toralf
___
tor-relays mailing list
tor-relays@lists.t
On 10/2/24 13:03, meskio wrote:
Not a concrete one. My plan is to review the situation early next month and
depending on the usage bring the conversation on what to do with those bridges
to our thursdays Anti-Censorship meetings.
I plan to change set the bridge distribution for my 4 unassigned
On 9/19/24 18:46, meskio wrote:
We plan to watch the usage of moat bridges and evaluate moving them
to another distributor depending on the usage[3].
Is there any timeline for the movement?
--
Toralf
___
tor-relays mailing list
tor-relays@lists.to
On 9/24/24 20:56, boldsuck via tor-relays wrote:
Oh, you're right. It's nicer because I have instance name in front of it.
Then "grep -h" is your friend
;)
--
Toralf
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torprojec
On 9/24/24 18:39, David Fifield wrote:
The numbers are rounded to reduce precision.
https://spec.torproject.org/dir-spec/extra-info-document-format.html
ah, thx.
I'm just curious, if 4 is rounded to 0 or to 8 ?
--
Toralf
___
tor-relays mailing lis
Never cared about this before, but isn't the "8" too often here? :
$ cat ~/tmp/tor_bridge_stats
i10 bridge-ips
ru=264,br=16,de=16,us=16,au=8,cl=8,co=8,cz=8,dz=8,eg=8,es=8,fr=8,gb=8,gr=8,hk=8,id=8,in=8,ir=8,it=8,kr=8,lt=8,lv=8,nl=8,ph=8,sa=8,sg=8,tw=8,ua=8,ve=8
i11 bridge-ips ru=152,ir=16,cn=8,cz=
On 9/24/24 15:40, boldsuck via tor-relays wrote:
https://paste.systemli.org/?d3987a7dc4df49fa#7GF2qk8hyTVgkinZshff9Dc9R6ukDDZo6BQqwQURzjQy
OT, but useless use of cat ;)
--
Toralf
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lis
On 9/16/24 21:13, boldsuck via tor-relays wrote:
Some court documents are linked here, in the google sheets:
https://safereddit.com/r/TOR/comments/19benkx/operation_liberty_lane_le_running_gaurd_and/?rdt=40060
Gus may have gotten some more documents.
returns: "Failed to parse page JSON data"
On 8/14/24 19:44, boldsuck wrote:
upgrades are running or not. And that I have to reboot because of the kernel
upgrade or similar. (I don't like auto reboots)
Ah, ok.
I like it and have therefore unattended upgrade configured
unconditionally for all packages [1].
Furthermore I do use needresta
On 8/14/24 16:13, boldsuck wrote:
If you have 'unattended upgrades' enabled, you will get an ERROR email.
Highly depends on a configured mailer IMO.
--
Toralf
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/c
On 8/2/24 17:38, Hiro wrote:
We are now opening NSA for testing
May I ask, what the abbreviation "NSA" means?
--
Toralf
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On 7/12/24 00:52, boldsuck wrote:
This has been looking damn good for 4 days :-)
https://metrics.torproject.org/rs.html#search/ForPrivacyNETbr
Flags, Uptime and green dot is OK
But the behaviour is not fixed. It just happened less often.
--
Toralf
_
On 7/16/24 14:03, boldsuck wrote:
wget
-qO-https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc
| gpg --dearmor | tee /usr/share/keyrings/tor-archive-keyring.gpg >/dev/null
Is the name important?
I'm asking b/c Ansible [1] seems to use "deb.torproject.org-k
On 7/12/24 00:14, boldsuck wrote:
The idea is not bad. But can you simply discard every ≤ 50byte packet?
Probably not
I drop fragments and uncommon TCP MSS values.
ip frag-off & 0x1fff != 0 counter drop
IIUC then using conntrack via iptables means that this filter cannot be
implemented, rig
Regarding to https://gitlab.torproject.org/tpo/core/tor/-/issues/40958 I
do wonder if that issue happened for stable Tor versions too - I do run
myself git HEAD only.
FWIW at my bare metal relay the RAM consumption per Tor process
decreased by about 0.7 GiB.
--
Toralf
___
On 7/11/24 22:51, boldsuck wrote:
cat /proc/sys/net/ipv4/tcp_syncookies
cat /proc/sys/net/ipv4/tcp_tcp_timestamps
I prefer sysctl:
$ sysctl net.ipv4.tcp_syncookies
net.ipv4.tcp_syncookies = 1
$ sysctl net.ipv4.tcp_timestamps
net.ipv4.tcp_timestamps = 1
--
Toralf
On 7/10/24 00:32, Osservatorio Nessuno via tor-relays wrote:
In both cases with 32GB of DDR5 RAM (we can max to 64 if needed, but is
it?).
IMO 4 GiB RAM per tor process is needed, with 2 GiB I sometimes
experienced an OOM.
--
Toralf
___
tor-relays
On 7/9/24 19:03, David Fifield wrote:
"A case study on DDoS attacks against Tor relays"
Tobias Höller, René Mairhofer
https://www.petsymposium.org/foci/2024/foci-2024-0014.php
After reading that paper I do wonder if a firewall rule would work which
drops network packets with destination to the
On 5/2/24 18:48, gus wrote:
- When: May 11, 19.00 UTC
hhm, the ESC in Malmö is at the same time :-/
--
Toralf
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On 4/19/24 22:53, tor--- via tor-relays wrote:
have a significant
tor_bug_reached_count rate (around 8 per second).
Here the rate is about 2-4 per hour (git-HEAD)
--
Toralf
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.to
On 3/26/24 09:54, Alessandro Greco via tor-relays wrote:
Recently, I've noticed an interesting pattern with my relay node (ID:
47B72187844C00AA5D524415E52E3BE81E63056B [1]). I've followed
TorProject's recommendations [2] and configured automatic updates, which
has led to frequent restarts of th
On 2/15/24 17:16, li...@for-privacy.net wrote:
I let nightly's upgrade automatically, but not stable.
Therefore I have the following config in
/etc/apt/50unattended-upgrades
Unattended-Upgrade::Origins-Pattern {
...
// Update TorProject's nightly dev packages: (Suite & Codename:
tor-nightly-mai
On 2/27/24 21:14, boldsuck wrote:
Gentoo & FreeBSD-Port Dev's and users are years
ahead ;-)
Whilst I'd agree on that my Tor bridges and Snowflakes do run under a
recent Debian. However Tor et al are compiled from sources. [1] [2]
[1]
https://github.com/toralf/tor-relays/blob/main/playbooks/
On 2/27/24 16:38, boldsuck wrote:
ORPort 127.0.0.1:14255
ORPort [::1]:14255
I do not specified the ipv6 port explicietly:
SandBox 0
ORPort 127.0.0.1:auto
AssumeReachable 1
ExtORPort auto
ServerTransportPlugin obfs4 exec /usr/bin/lyrebird
Would it be needed?
--
Toralf
__
On 2/26/24 20:07, meskio wrote:
Rdsys, the new bridgeDB, will not automatically assign bridges to Lox for now,
but will instead accept bridges with the 'BridgeDistribution lox' configured in
torrc.
BTW by accident I configured "any" but restarted tor with "lox" 2
minutes later. Does that work?
On 2/26/24 20:07, meskio wrote:
At the moment we're
looking for 10 new bridges for Lox.
9 left
--
Toralf
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On 1/13/24 18:29, George Hartley via tor-relays wrote:
Is anyone else experiencing this?
Yes,
https://gitlab.torproject.org/tpo/core/tor/-/issues/40749
--
Toralf
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.
On 12/8/23 04:19, Mulloch94 via tor-relays wrote:
-A INPUT -j DROP
HHm, what's about local traffic, e.g.: -A INPUT --in-interface lo -j ACCEPT
or ICMP, e.g.: -A INPUT -p icmp -j ACCEPT
To persist your firewall rules take a look at this doc [1]
[1] https://github.com/toralf/torutils#quick-sta
On 10/3/23 10:24, Fran via tor-relays wrote:
Any ideas?
yes - DNAT the remote prometheus ip to the local address [1]
[1]
https://github.com/toralf/tor-relays/blob/main/playbooks/roles/setup-snowflake/tasks/firewall.yaml#L10
--
Toralf
___
tor-relay
Yesterday I stumbled together 2-3 dashboards [1] for Tor relay(s), Tor
Snowflake(s) and the DDoS solution [2].
Feedback is welcome.
[1] https://github.com/toralf/torutils/tree/main/dashboards
[2] https://github.com/toralf/torutils/tree/main
--
Toralf
On 9/7/23 14:12, telekobold wrote:
A bit research reveled that apparently, an automatic update set the
systemd setting "NoNewPrivileges=no" in
/lib/systemd/system/tor@default.service and tor@.service [1] back to yes,
You probably need another entry too (grabed from [1]):
[Service]
NoNewPriv
Few days ago the throughput of my Tor relay went down to nearly zero for
about 3 minutes. It turned out that the reason (maybe) was a change here
in my iptables rules. Especially I switched these 2 lines:
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP
iptables -A INPUT -m conntrack
On 8/1/23 19:38, li...@for-privacy.net wrote:
Yes ;-)
cool - this simplifies my Ansible role (I randomly choosed an ORPort
between 30K and 62K)
Unfortunately, they come every 1-2 hours
np - I'll ignore that
Thx !
--
Toralf
___
tor-relays mailing l
On 8/1/23 18:54, li...@for-privacy.net wrote:
== Announcements ==
rdsys is ignoring the running flag now :)
* To hide your bridge's ORPort:
ORPort 127.0.0.1:auto
AssumeReachable 1
I do assume I can ignore this log message ? :
"Aug 01 17:18:19.000 [warn] The IPv4 ORPort address 127.0.0.1 does
On 6/26/23 23:44, gus wrote:
- Recommendation: Do not run snowflake proxy on the same IP as a
relay/bridge. It's a good call to run it on a machine with public
dynamic IP address.
I setup 6 snowflakes as VPS with a fixed IP.
After which time those IPs should be changed ?
--
Toralf
Given that hosters of a VPS often gives a big /48, /56 or /64 ipv6
subnet to a VPS I do wonder if the BridgeLine for ipv6 could benefit
from that?
With
ip6tables -t nat -I PREROUTING -p tcp -j DNAT --to-destination [obfs4
address]
/usr/sbin/ip6tables-save > /etc/iptables/rules.v6
all in
On 3/22/23 20:25, gus wrote:
But here's the trick: you need to run it on a
residential connection -- you won't need a static IPv4 --,
So the local bridge reports its (eg at 4 o'clock in the morning changed)
ip to the bridge db asap? And then ?
--
Toralf
_
I found the time and wrote a Bash script [1] to export iptables and
ipset metrics to Prometheus/Grafana.
It works at least with [2].
[1] https://github.com/toralf/torutils/blob/main/metrics.sh
[2] https://github.com/toralf/torutils#readme
--
Toralf
__
On 3/15/23 03:19, Jeff Teitel wrote:
Conntrack.sh shows count: 65535.
You can increase that size, look at [1] for an example.
[1] https://github.com/toralf/torutils/blob/main/ipv4-rules.sh#L157
--
Toralf
___
tor-relays mailing list
tor-relays@lists
On 3/4/23 17:29, gus wrote:
What's the goal? To have a private exit that only you can use?
Indeed, similar goal as for private bridges.
There is this very interesting paper and project called HebTor:
https://dl.acm.org/doi/10.1145/3372297.3417245
Thx, so I have sth to read.
--
Toralf
tl;dr;
restricted access + usage of an exit
longer:
An exit is sooner or later abused. A reduced exit policy does not
prevent that.
What about setup a tor exit relay with 'PublishServerDescriptor = 0' ?
Having an access line like for bridges would restrict the access. An
alternative could b
On 12/20/22 15:27, Anonforpeace via tor-relays wrote:
Dec 20 08:55:16 mxh-HP-Compaq-Pro-6300-SFF kernel: [137278.310446]
audit: type=1400 audit(1671544516.974:36): apparmor="DENIED"
operation="open" profile="system_tor"
name="/sys/kernel/mm/transparent_hugepage/hpage_pmd_size" pid=17728
comm="obf
On 12/9/22 07:02, David Fifield wrote:
But now there is rdsys and bridgestrap, which may have the ability to
test the obfs4 port rather than the ORPort. I cannot say whether that
removes the requirement to expose the ORPort.
Would be a step toward to make scanning for bridges harder IMO, if the
On 12/6/22 19:44, Roger Dingledine wrote:
But it seems
like this role separation never quite matches up well to the security
issues that arise in practice, whereas it definitely adds complexity
both to the design and to operation. This piece of the design could use
some new ideas.
So the concep
On 12/6/22 19:44, Roger Dingledine wrote:
We
could start by encouraging directory authority operators to participate
in the monthly virtual relay operator meetups.
I'd appreciate it.
--
Toralf
OpenPGP_signature
Description: OpenPGP digital signature
___
On 11/8/22 10:57, Chris wrote:
The main reason is that a simple SYN flood can quickly fill up your
conntrack table and then legitimate packets are quietly dropped and you
won't see any problems thinking everything is perfect with your server
unless you dig into your system logs.
Hhm, my system
The graphs in [1] and [2] are IMO good examples related to [3]:
"... in addition to network filtering, the (currently) sharp input
signal ... is transformed into a smeared output response ... This shall
make it harder for an attacker to gather infromation using time
correlation techniques."
On 10/21/22 22:09, Alexander Dietrich wrote:
This is still experimental, so if you decide to give the script a try,
please keep an eye on it.
IMO a "reload tor" is fully sufficient and should be preferrred over
"restart", or ?
Years ago I wrote a bash script, which created for an ip to be bloc
On 10/17/22 11:41, meskio wrote:
Will be nice to add those fixes to the package. Maybe you can open two issues on
the debian bugtracker for them.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021911.
--
Toralf
___
tor-relays mailing list
tor-re
On 10/16/22 09:50, Toralf Förster wrote:
After configuring the installation of the unattended_upgrade package to
consider all packages [1] the new obfs4proxy was installed - but Tor was
not restarted nor obfs4proxy reloaded.
Isn't this a task for the software package ?
And IMO the D
On 10/14/22 11:28, meskio wrote:
If you use debian you can find the Debian package in stable-backports:
https://packages.debian.org/stable-backports/obfs4proxy
After configuring the installation of the unattended_upgrade package to
consider all packages [1] the new obfs4proxy was installed -
On 10/14/22 19:09, meskio wrote:
The upstream changelog is here:
https://gitlab.com/yawning/obfs4/-/blob/master/ChangeLog
But I understand is not easy to understand what the problem is from that
changelog.
Indeed.
BTW the fix was made 5 weeks ago, so I do assume, the (eg. Debian)
package neede
On 10/14/22 11:28, meskio wrote:
The latest version of obfs4proxy (0.0.14) comes with an important security fix.
Is there a Changelog available ?
--
Toralf
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-
On 10/4/22 18:15, Isaac Grover, Aileron I.T. wrote:
According to tor metrics, there have been nearly three times the number
of relays as bridges over the last three months so I would like to move
my handful of middle relays to bridges. They will keep their same IP
address. Is there a best pract
On 10/3/22 12:26, Richie wrote:
My apologies if its not the right place to ask.
greetz
Korrupt
Every place is the right place for feedback, thx for yours !
I updated the readme [1] at the experimental branch and will merge it to
main soon. Feel free to give additional feedback -and/or- make
On 9/30/22 17:57, Sandro Auerbach wrote:
30 minutes later still 22000 connections...
Have you observed something similar?
I reduced those spikes [1] by using certain iptables rules [2].
[1] https://github.com/toralf/torutils/blob/main/sysstat.svg
[2] https://github.com/toralf/torutils
--
Tor
Playing with Python and Stem I wrote a script to monitor the
ORStatus.CLOSED event reasons [1]. A helper script [2] gives statistics
from those data.
From the last 2 days I got:
$> orstatus-stats.sh /tmp/orstatus.29051 CONNECTRESET
6197 CONNECTRESET
13214 DONE
18769 IOERROR
58 NOROUT
On 8/18/22 22:10, li...@for-privacy.net wrote:
IPv6 connections should better be limited to /48 subnets in the Tor protocol.
Or /32
Limiting IPv6 to N connections per /64 will definitely affect relays of
https://metrics.torproject.org/rs.html#search/2a0b:f4c2:2
Similar to their /24 IPv4 segme
On 8/18/22 21:31, li...@for-privacy.net wrote:
If that's really the case, I can set up the ip|nftables rules much more
strictly.
Currently I do have it set to "3" [1], before it was 2, which seemed to
work too.
[1] https://github.com/toralf/torutils/blob/main/ipv4-rules.sh
--
Toralf
On 8/18/22 18:19, li...@for-privacy.net wrote:
kantorkel's Article10 relays have more than 100 connections per IP to me.
Those IPs mostly close with an error:
$> grep -h " 185.220.101.*" /tmp/orstatus.*9051 | awk '{ print $1 }' |
sort | uniq -c
341 CONNECTRESET
78 DONE
783 IOERROR
On 8/18/22 18:19, li...@for-privacy.net wrote:
10, 20 or more users can have set up the circuits using the same relays.
kantorkel's Article10 relays have more than 100 connections per IP to me.
IMO there'se no 1:1 relation of circuits to TCP connections, or ?
Doesn't 1 TCP connection between 2
On 8/18/22 18:19, li...@for-privacy.net wrote:
D767979FE4C99D310A46EC49037E9FE7E3F64E9D is a particularly frequent
naughty boy.
;-) It is very, very unlikely that there is a naughty relay in AS680.
That relay most likely does DNS-, BW- or network healing test in the Tor
network.
https://metric
On 8/2/22 20:58, Eldalië via tor-relays wrote:
Recently I noticed that my ISP started to reset my IP a few
hours after the node gets the Guard flag,
The Guard flag is given after a more or less constant time (or?) - so
I'd not see a conincidence here.
--
Toralf
Issue 40636 and others deal with DDoS / concurrent connections. Here're
few numbers from my attempt [1] of the last days to block such ip
addresses. The stats are from 2 relays running at the same ip.
Currently there're 700 ip addresses (15 IPv6) caught in the denylist.
Those either opened >4 con
On 7/25/22 19:56, David Goulet wrote:
On Linux, we use /proc/meminfo (MemTotal line) and so whatever also max limit
the kernel would put for that.
Here both Tor relays do use about 4 GB each:
$ pgrep tor | xargs -n 1 pmap | grep total
total 4211476K
total 4226580K
whilst m
On 7/25/22 14:48, David Goulet wrote:
It is usually set around 75% of your total memory
Is there's a max limit ?
--
Toralf
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On 7/20/22 23:34, bidulock_ringrose--- via tor-relays wrote:
Side note: I am using Toralf's ddos-inbound script, which has not
dropped any connections at all for me when using the -b then -s switch.
In the mean while I try here for my 2 relays a different approach [1].
In the meanwhile I do pre
On 7/10/22 22:28, Logforme wrote:
A week ago I implemented connection limits per Toralf's post:
iptables -A INPUT -p tcp --destination-port 443 -m connlimit
--connlimit-mask 32 --connlimit-above 30 -j DROP
This reduced the number of connections to about 1.
I just now noticed that the rel
On 6/15/22 20:17, Eddie wrote:
I have been running the relay for almost 5 years without any previous
flagging.
There are block list providers which have Tor exit relays lists and
sells those lists to their customers.
Mayve they extend their algorithm to all Tor relays.
Anyway, "Do not run a
On 5/7/22 05:56, Xiaoqi Chen (Danny) wrote:
I temporarily mitigated the issue by turning off sandbox mode (remove
"Sandbox 1" in torrc). Does anyone know how to properly resolve the
crashing issue?
usually by filing a bug here :
https://gitlab.torproject.org/tpo/core/tor/-/issues/new
;)
--
T
On 5/3/22 07:31, Keifer Bly wrote:
Err:15 https://deb.torproject.org/torproject.org amd64 Release
Certificate verification failed: The certificate is NOT trusted. The
certificate chain uses expired certificate. Could not handshake: Error
in the certificate verification. [IP: 95.216.163.36 443
I do appreciate those for my attempt here:
https://github.com/toralf/tor-relays
TIA
--
Toralf
OpenPGP_signature
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/ma
On 3/21/22 18:45, meskio wrote:
Thank you for running bridges,
let me know if you need any help upgrading it.
I'm not really familar with Debian and do wonder, what line I have to
add to /etc/apt/apt.conf.d/50unattended-upgrades to get that
automatically installed ? Maybe I need to add the re
On 3/20/22 17:14, Felix wrote:
They were kicked off by the packetfilter
IMO it is a bad idea to filter Tor traffic.
--
Toralf
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
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 signatur
On 3/8/22 19:48, Eddie wrote:
as I'm certain that there's no way to "move" them to the new location
Yes.
And that's why I do wonder why you want to "continue" the stats ?
--
Toralf
OpenPGP_signature
Description: OpenPGP digital signature
___
tor-re
On 3/8/22 18:39, Erasme via tor-relays wrote:
Thanks to the community, the Ansible role now supports more operating systems
to deploy obfs4 bridges.
- Debian 11
If bridges are added to the hosts of the inventory, then existing
bridges are restarted at "-t install_all".
What is the preferre
On 2/19/22 12:48, meskio wrote:
If you have restricted NAT I would recommend you to open the UDP port range of
32768-60999.
Thx, I opened those UDP ports for incoming UDP traffic.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info:
https://meskio.net/crypto.txt
OT, but: You're
I do simply run here
~/devel/go/src/snowflake/proxy/proxy &>>/tmp/snowflake-proxy.log &
and was wondering if I have to open special UDP inbound ports ?
From the stats snowflake iseems to be working:
2022/02/18 19:29:59 In the last 1h0m0s, there are 13 connections.
Traffic Relayed ↑ 192 MB, ↓
On 12/29/21 18:45, Toralf Förster wrote:
Said that you should set "PublishServerDescriptor 0" at bridges where
you distribute the connection info yourself.
Or maybe set it to
BridgeDistribution none
to have bridge stats at metrics.org.
--
Toralf
OpenPGP_signature
D
On 12/29/21 15:37, Space Oddity via tor-relays wrote:
Also, I can not rule out that some step in my distribution chain was
compromised -- I gave out these bridges privately to a few friends.
IMO you should not mix private brtdges with those where you delegate the
to distribute the connection i
On 12/14/21 17:06, Nick Mathewson wrote:
A relay operator has asked me, offline, if it is possible under this
proposal for a relay to belong to more than one family. (For example,
if there were two relay operators who each operated some relays on their
own, but also operated some relays join
On 11/6/21 10:39 PM, Logforme wrote:
Got the following in my log today:
Nov 06 18:19:01.000 [warn] Possible compression bomb; abandoning stream.
Nov 06 18:19:01.000 [warn] Unable to decompress HTTP body (tried
Zstandard compressed, on Directory connection (client reading) with
45.66.33.45:80).
On 11/6/21 3:36 PM, Nick Mathewson wrote:
Option 3 requires regular updates to all the relays in the family,
which makes it cumbersome.
Except for people who already have offline relay keys.
For those it is just 1 additonal file to copy ;)
--
Toralf
OpenPGP_signature
Description: OpenPGP
On 10/23/21 12:41 AM, Felix wrote:
Toralf, it would be super nice if you could check on your end, or
somebody else can confirm?
Hi,
we here in Gentoo decided to stop supporting LibreSSL, so I cannot tell
you if it would work here or not.
--
Toralf
On 9/23/21 3:39 PM, Silvia/Hiro wrote:
Let us known how you find this new feature.
It would be nice if even the search form would have that feature too.
Currently here all is green:
https://metrics.torproject.org/rs.html#search/zwiebeltoralf
wherease the details of each of the 2 relays s
On 9/25/21 4:11 PM, Silvia/Hiro wrote:
If it happens again there are two buttons at the end of the page where
you can see the latest server and extra-info descriptors.
Only, if the DirPort is (still) opened, or ?
--
Toralf
___
tor-relays mailing list
On 9/2/21 9:11 AM, Georg Koppen wrote:
No. As far as it matters for the test those two relays are independent
relays which each get tested as two random relays would get.
Except, that both shares the same network card ...
--
Toralf
___
tor-relays mai
On 8/25/21 12:02 PM, Georg Koppen wrote:
Hello!
You might recall we ran two "speed tests" so far for investigating the
accuracy of a relay's advertised bandwidth, one in 2021[1] and another
one earlier this year[2].
I do run 2 relays at the same ip address.
Do the tests consider that ?
--
To
On 8/15/21 6:04 AM, Eddie wrote:
I know how to maintain the keys for both relays and bridges for the
replacements, but was wondering exactly what does that buy me, as both
will now be running at different IPv4/6 addresses.
As opposed to just blowing away the current ones and starting fresh copie
On 6/24/21 1:59 AM, S1l3nt Hash wrote:
Address xxx.xxx.xxx.xxx (static public ip)
DirPort 9030 NoAdvertise
DirPort xxx.xxx.xxx.xxx:9030 NoListen (static public ip)
ORPort 9001 NoAdvertise
ORPort xxx.xxx.xxx.xxx:9001 NoListen (static public ip)
Hiding those IP addresses (and other *sensitive*) d
On 6/12/21 5:42 PM, Cor.ling wrote:
Jun 12 15:13:59 PC tor[38309]: Jun 12 15:13:59.476 [warn]
/var/lib/tor/keys is not owned by this user (debian-tor, 124) but by
root (0). Perhaps you are running Tor as the wrong user?
Jun 12 15:13:59 PC tor[38309]: Jun 12 15:13:59.476 [warn] Failed to
parse/val
On 4/24/21 9:21 PM, nusenu wrote:
Hi Toralf,
Toralf Förster:
On 4/24/21 12:11 PM, nusenu wrote:
* tor 0.4.7: no longer assign the exit flag to relays not having a ContactInfo
(< 5 chars) in their descriptor.
Log a warning for relay operators,
I've opened 1-2 dozen ports
On 4/24/21 12:11 PM, nusenu wrote:
* tor 0.4.7: no longer assign the exit flag to relays not having a ContactInfo
(< 5 chars) in their descriptor.
Log a warning for relay operators,
I've opened 1-2 dozen ports - except 80 sand 443 at 2 relays.
So I do not have the Exit flag.
Never
On 4/24/21 7:18 AM, Scott Bennett wrote:
I went through the process to get an account at gitlab.torproject.org
in order to file a problem report for a very irksome and tiresome daily
abort in tor 0.4.5.7 and 0.4.6.1-alpha under FreeBSD 11.4. However, I do
not find anywhere on that web site
On 4/23/21 2:03 PM, Matt Traudt wrote:
Keeping tor up to date, and the OS and all the other things installed on
it up to date, is much more important than maintaining your flags.
You'll get them back.
IMO relays with a way too long uptime should get a penalty.
--
Toralf
___
On 4/21/21 12:15 PM, Sebastian Hahn wrote:
Moria applies its own criteria which differ from dir-spec. Its operator is
testing future improvements to the Tor network and therefore frequently doesn't
follow all the specs.
bastet too, or ?
--
Toralf
__
1 - 100 of 474 matches
Mail list logo
