[ 22.120385] [ cut here ]
[ 22.120389] WARNING: CPU: 13 PID: 11 at
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_dpp.c:501
dpp3_deferred_update+0x106/0x330 [amdgpu]
[ 22.120484] Modules linked in: fuse michael_mic hid_jabra
ip6table_filter ip6_tables xt_LOG nf_
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
https://bugs.kde.org/show_bug.cgi?id=493445
--- Comment #4 from Toralf Förster ---
(In reply to Marco Martin from comment #2)
> wayland or x11?
x11 here at a stable hardened Gentoo Linux
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=493445
Bug ID: 493445
Summary: logout menue does not pop up after "Save Session"
Classification: Plasma
Product: plasmashell
Version: 6.1.5
Platform: Gentoo Packages
OS: Linux
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/11/23 21:38, Ulrich Mueller wrote:
The standard is defined by sno-color.org.
http://no-color.org
--
Toralf
PGP 23217DA7 9B888F45
OpenPGP_signature.asc
Description: OpenPGP digital signature
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
On 9/18/23 16:17, Alex Deucher wrote:
Yes. Fixed in this commit:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=69a959610229
Alex
A cool, backport is in 6.5.4-rc1
Thx!
--
Toralf
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
https://bugs.kde.org/show_bug.cgi?id=473455
Bug ID: 473455
Summary: kate crash when switching the desktop
Classification: Applications
Product: kate
Version: 23.04.3
Platform: Compiled Sources
OS: Linux
Status:
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
On Tue, 15 Nov 2022 10:11:25 +0100 =?UTF-8?Q?Toralf_F=c3=b6rster?=
wrote:
On 11/15/22 01:08, Paul Wise wrote:
> One workaround would be for you to add an apt hook for this:
>
> /etc/apt/apt.conf.d/99-obfs4proxy-capability:
>
> DPkg::Post-Invoke { "setcap cap_net_bind_service=+ep
/usr/bi
On 6/7/23 15:09, Jeff Gazso wrote:
Can you give me a list
of common pain points?
My wish would be a -bin package.
Even with -j12 it takes here 5-6 hours compile time, which is a pain.
--
Toralf
PGP 23217DA7 9B888F45
OpenPGP_signature
Description: OpenPGP digital signature
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 5/16/23 21:09, Andreas Sturmlechner wrote:
That's not really related to any certain USE flag setting though, right? I
mean, www-client/chromium has USE=wayland but can still be started in X mode.
indeed.
--
Toralf
PGP 23217DA7 9B888F45
OpenPGP_signature
Description: OpenPGP digital signa
On 5/16/23 20:15, Sam James wrote:
We should probably note that it's fine for people to use -wayland in
make.conf if they want although we'd discourage it for the Plasma
profile?
+1
IIRC I experienced a nagging issue with chromium in the past. Its window
size wasn't resizeable:
chromium --d
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
https://bugs.kde.org/show_bug.cgi?id=457763
--- Comment #2 from Toralf Förster ---
Created attachment 155183
--> https://bugs.kde.org/attachment.cgi?id=155183&action=edit
New crash information added by DrKonqi
kate (22.08.3) using Qt 5.15.7
I chanegd the background image and it h
https://bugs.kde.org/show_bug.cgi?id=457763
Toralf Förster changed:
What|Removed |Added
CC||toralf.foers...@gmx.de
--
You are receiving
On 1/6/23 01:20, alexey+gen...@asokolov.org wrote:
If the test fails with "die", Xvfb keeps running forever; but it's
cleaned up correctly with die -n
At my tinderbox I do experience sometimes a running dirmngr process
solely running since days. /me wonders if that's the result of a similar
s
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/15/22 20:22, Florian Schmaus wrote:
o use PORTDIR_OVERLAY and multiple repositories on their system: a
system-wide, managed by portage, and a dev repository (in your HOME),
scoped in via PORTDIR_OVERLAY.
Isn't this covered by /etc/portage/repos.conf/*
eg here's my config:
cat /etc/port
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 12/3/22 10:53, Michał Górny wrote:
On Sat, 2022-12-03 at 09:39 +0100, Ulrich Mueller wrote:
Then rename UNCONFIRMED to NEW-WITH-SUGAR-ON-TOP-WE-ARE-A-HAPPY-
COMMUNITY,
Done.
I do search for bugs using pybugz and gre3p for CONFIRMED and do wonder
if/when I shall grep for NEW too ?
--
On 11/15/22 01:08, Paul Wise wrote:
One workaround would be for you to add an apt hook for this:
/etc/apt/apt.conf.d/99-obfs4proxy-capability:
DPkg::Post-Invoke { "setcap cap_net_bind_service=+ep /usr/bin/obfs4proxy";
};
This is a good work around - thx.
--
Toralf
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."
https://bugs.kde.org/show_bug.cgi?id=461347
Bug ID: 461347
Summary: plasmashell crashed when applyinig "Breeze Dark" to
"appearance" and "Desktop"
Classification: Plasma
Product: plasmashell
Version: 5.25.5
Platform: Co
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
Package: obfs4proxy
Version: 0.0.14-1 amd64
Issue: overwriting capabilities
During update the package overwrites an installed /usr/bin/obfs4proxy
without preserving the capabilities, eg. set by
setcap cap_net_bind_service=+ep /usr/bin/obfs4proxy
So a Tor bridge with a port below 1024
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/13/22 18:01, Jeff Gazso wrote:
Wouldn't it make more sense to silo these ebuilds (and similar) under
something
like fintech instead?
Whatever sounds more natural, it needs a "-" in its name IMO.
--
Toralf
PGP 23217DA7 9B888F45
OpenPGP_signature
Description: OpenPGP digital signature
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
On 9/11/22 17:04, Toralf Förster wrote:
On 9/11/22 16:06, Paul Smith wrote:
You also should be able to get back the old behavior by adding the
--jobserver-style=pipe option to your make invocation.
will do that, - thx
And run now into (had --shuffle set):
rm -f
/var/tmp/portage/sys-libs
On 9/11/22 16:06, Paul Smith wrote:
You also should be able to get back the old behavior by adding the
--jobserver-style=pipe option to your make invocation.
will do that, - thx
--
Toralf
PGP 23217DA7 9B888F45
OpenPGP_signature
Description: OpenPGP digital signature
Hi,
I do maintain a Gentoo Linux build bot. I tried to install the package
sys-devel/make-, which is latest -git HEAD always.
At a so-called no-multilib system I run yesterday into this error:
>>> Source configured.
>>> Compiling source in
/var/tmp/portage/mail-client/s-nail-14.9.22/wo
I do get at all of my Debian bullseye VPS at Hetzner this message during
boot (once):
Aug 16 06:08:42 uhu kernel: [1726344.567946] device-mapper: uevent:
version 1.0.3
Aug 16 06:08:42 uhu kernel: [1726344.571939] device-mapper: ioctl:
4.43.0-ioctl (2020-10-01) initialised: dm-de...@redhat.com
On 9/2/22 21:19, Mike Pagano wrote:
+[[ -n ${SKIP_KERNEL_CHECK} ]] && return
Sounds promising, so SKIP_KERNEL_CHECK="y" in make.conf will make it ?
--
Toralf
PGP 23217DA7 9B888F45
OpenPGP_signature
Description: OpenPGP digital signature
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
Package: systemd/stable 247.3-7 amd64
I do wonder why the unattended upgrade is scheduled at all of my 21
bullseye systems between 6 am and 7 am. I'd expect a 24h flat
distribution of scheduled events instead.
Every system was setup at AS Hetzner this year using a simple Ansible
role [1].
FWIW:
Package: systemd/stable 247.3-7 amd64
I do wonder why the unattended upgrade is scheduled at all of my 21
bullseye systems between 6 am and 7 am. I'd expect a 24h flat
distribution of scheduled events instead.
Every system was setup at AS Hetzner this year using a simple Ansible
role [1].
FWIW:
https://bugs.kde.org/show_bug.cgi?id=457763
Bug ID: 457763
Summary: Kate crashed when changing the back ground
Product: kate
Version: 22.04.3
Platform: Compiled Sources
OS: Linux
Status: REPORTED
Keywords:
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
https://bugs.kde.org/show_bug.cgi?id=456175
--- Comment #2 from Toralf Förster ---
(In reply to Waqar Ahmed from comment #1)
> Hi,
>
> thanks for the report. Can you provide steps to reproduce this?
>
> Doesn't seem like its directly related to kate.
I do have 2 des
https://bugs.kde.org/show_bug.cgi?id=456175
Bug ID: 456175
Summary: kate crash
Product: kate
Version: 21.12.3
Platform: Compiled Sources
OS: Linux
Status: REPORTED
Keywords: drkonqi
Severity: cra
https://bugs.kde.org/show_bug.cgi?id=455658
Bug ID: 455658
Summary: kate crashed w/o any action
Product: kate
Version: 21.12.3
Platform: Compiled Sources
OS: Linux
Status: REPORTED
Keywords: drkonqi
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
https://bugs.kde.org/show_bug.cgi?id=453372
--- Comment #2 from Toralf Förster ---
It is not only spam - rsibreak malforms under wayland.
--
You are receiving this mail because:
You are watching all bug changes.
1 - 100 of 1666 matches
Mail list logo
