I run the non-exit relay 8F6A78B1EA917F2BF221E87D14361C050A70CCC3
Today I noticed two [warn] lines in the Tor log file that I have not
seen before:
[warn] Error relaying cell across rendezvous; closing circuits
[warn] circuit_mark_for_close_(): Bug: Duplicate call to
circuit_mark_for_close at
On 2023-08-01 23:14, Eldalië via tor-relays wrote:
My guess is that some widely used black list started including middle relay
IPs, but I have no proofs.
Has anyone had similar experiences? Any thoughts on this?
I run a non-exit relay at home and have run into the same issue.
Some Swedish gover
On 2022-10-20 03:35, Alex Xu (Hello71) via tor-relays wrote:
for these reasons, I haven't aggressively pursued this plan. I have some
more ideas based on intra-family correlation, but they also have similar
problems as well as more implementation problems. in the long term, our
best hope is th
On 2022-10-19 17:10, Chris wrote:
You may want to check these links:
https://gitlab.torproject.org/tpo/community/support/-/issues/40093
https://github.com/Enkidu-6/tor-ddos
https://github.com/toralf/torutils
Thank you for the reply and the links.
From what I can understand those links conc
I run the relay 8F6A78B1EA917F2BF221E87D14361C050A70CCC3
Like most relays mine has been targeted by the DoS attack. Hundreds of
VPS IPs creating millions of IP connections. This I mitigated with rules
in my firewall. Looking at the firewall counters it looks like that
attack has now stopped.
On 2022-09-01 06:53, Scott Bennett wrote:
My question is, do other relay operators whose relays are being
attacked see the same phenomenon?
My relay's (8F6A78B1EA917F2BF221E87D14361C050A70CCC3) heartbeat messages
show a steady increase. This could be because I only get HB every 6 hours.
I run the relay 8F6A78B1EA917F2BF221E87D14361C050A70CCC3
I have tried to mitigate the current DoS by implemented connection
limits in my iptables using Toralf's template: More than 25 connection
during 10 mins and you end up on my naughty list.
Lots of connection attempts from the naughty list
On 2022-07-06 21:19, Roger Dingledine wrote:
But it was replaced with a new overload (boo), from way too many Tor
clients running at a few cloud providers. The main result for relay
operators is greatly increased file descriptor use, with a few IP
addresses or /24's generating the majority of the
I am contacting you because I don't understand why my relay is not
considered as a guard relay (entry relay), since I already have the
following flags: Fast, HSDir, Running, Stable, V2Dir, Valid.
The dir-spec.txt document
(https://github.com/torproject/torspec/blob/main/dir-spec.txt) specifi
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).
45.66.33.45 is tor.dizum.com, a Tor d
On 2021-05-26 08:18:32, "Scott Bennett" wrote:
I interpret that as meaning that one
or more criteria being used by one or more authorities has changed,
What I have noticed on my relay is that the "Consensus Weight" is
fluctuating.
CW is too complicated for my tiny brain but I believe the meas
On 2021-05-25 12:08:34, "John Csuti"
wrote:
I second this. We are in 2021 and a relay is considered fast if it is
above 100KB/s...? I don’t think a later dialup service should be
considered a fast relay.
100KB/s is about 800Kb/s
(https://en.wikipedia.org/wiki/Data-rate_units). I envy the d
On 2021-05-22 11:31:12, "Scott Bennett" wrote:
What are all the current requirements for a relay to get a
HSDir flag? 96 (97?) hours of uptime and what else?
Can someone tell me what my relay, MYCROFTsOtherChild, is
missing for a HSDir flag?
From the spec:
https://github.com/torpr
On 2021-02-12 07:20:02, "Eddie" wrote:
Just trying to understand if this is normal or if something else is going on.
I have 2 bridges on a VPS. One is designated as "moat", the other "email".
Until earlier today, for over a year, both averaged under 10 unique clients, per 6-hour reporting
p
On 2020-09-21 11:19:20, "Андрей Гвоздев"
wrote:
Hello
I'm running a TOR relay, every time I SSH to my server I see a message
that there were thousands of failed login attempts
Do you see this message too?
Exposing a SSH server to the internet will get you lots of login
attempts.
Here are so
ow we want to whitelist changes.# Assume details
update is permanent85.230.184.93:9030 orport=443
id=855BC2DABE24C861CD887DB9B2E950424B49FC34 # Logforme
Logforme is my relay. I've repeatedly asked for it to be blacklisted. Does "Now we
want to whitelist changes" mean you want to
My relay Logforme (855BC2DABE24C861CD887DB9B2E950424B49FC34) is
currently flagged as fallback dir.
The relay runs on a dynamic ip address that will change rarely. I have
over the years tried multiple times to get the relay excluded from the
fallback dir list but it keeps popping back in there
On 2020-04-29 17:13:49, "Secure Node" wrote:
I'm looking for new router for good price which can handle more connections and
traffic ;-)
Can you recommend any specific models? Should I avoid some products lines or
companies?
If you have an old PC with 2 ethernet ports laying around or you ca
On 2019-12-12 17:49:22, "NOC" wrote:
than lets drop all IPv4 only relays from consensus 2020 finally.
I would be sad to no longer be able to contribute to the Tor network.
My ISP, Telenor Sweden, does not provide IPv6 and have no (public)
roadmap for supporting IPv6.
I can't switch ISP since
Tonight my relay 855BC2DABE24C861CD887DB9B2E950424B49FC34 restarted with
the following in the log file:
Nov 20 19:08:07.000 [notice] Heartbeat: Tor's uptime is 20 days 12:00
hours, with 29939 circuits open. I've sent 46193.23 GB and received
45940.92 GB.
Nov 20 19:08:07.000 [notice] Circuit hand
On 2019-08-06 23:31:39, "Rob Jansen" wrote:
Today, I started running the speedtest on all relays in the network. So far, I
have finished about 100 relays (and counting). I expect that the advertised
bandwidths reported by metrics will increase over the next few days. For this
to happen, the
On 2019-05-05 14:32:52, to...@protonmail.com wrote:
Though I realize that my vision of the local "mom and pop" relays has gotten
more and more outdated.
I think it's more important than ever. In my mind diversity is more
important than throughput.
If everyone ran GBit relays at a few providers
On 2019-04-07 23:57:58, "teor" wrote:
It looks like your relay could be CPU-core-limited, or limited by some other
local resource, or limited by its location.
Currently the CPU is only using 40% of 1 core (out of 4). All of it from
Tor when BW is close to 250Mbps
When routing from the LAN (iper
I run the non-exit relay:
https://metrics.torproject.org/rs.html#details/855BC2DABE24C861CD887DB9B2E950424B49FC34
The relay run on a debian stretch machine with an i5-4670 at 3.8GHz with
4GB memory. CPU usage at 250Mbps traffic is around 40% of 1 core out of
4.
On April 1st my ISP doubled my b
On 2019-01-31 14:19:31, "Felix" wrote:
Hi everybody
Circuit storms observed of up to 100k and 250k per relay for over hours.
Consumed BW rises by about 10%. Number of stateful server connections is
higher. Using Tor 356 to 401.
Anybody else observes that?
Only way I know to check circuits is
On 2018-12-04 16:33:33, tscha...@posteo.de wrote:
Furthermore it was clear for me that fix periods of 21 min 21 sec
couldn't be a normal client. Missing more information about bridge
directory authority …
From https://blog.torproject.org/new-bridge-authority:
"The Bridge Authority is a simple
On 2018-10-30 16:51:42, to...@protonmail.com wrote:
Before I download months of gzipped archives and zgrep them myself, is
there a way to search the messages themselves? I'm looking at:
https://lists.torproject.org/pipermail/tor-relays/
but maybe there as another setup somewhere else.
I use G
"Your relay has a very large number of connections to other relays. Is
your outbound address the same as your relay address? Found 12
connections to 8 relays. Found 12 current canonical connections, in 0
of which we were a non-canonical peer. 4 relays had more than 1
connection, 0 had more than
Hi to all, is it a god ide to setup torrelays directly on WAN port ?
Yes there are an firewall, but direkt in the torserver. So no extern
firwall.
I run my relay on my firewall machine.
I have a headless debian server box set up to be firewall/router between
the WAN and LAN NICs. It's also DH
On 2018-06-26 16:16:46, "dave levi" wrote:
I'm testing few things in Tor and I noticed that if im changing(from
the source code) the number of hop's(nodes) to be more then 3 hop's it
work's fine(slowly, but still working) and if im sting only 2 hop's
its still works great. but, when i'm sett
I run the non-exit relay 855BC2DABE24C861CD887DB9B2E950424B49FC34
Two days now I've seen this in my log file:
Jun 05 06:25:02.000 [warn] Refusing to apply consensus diff because the
base consensus doesn't match the digest as found in the consensus diff
header.
Jun 05 06:25:02.000 [warn] Expect
After reading this post
https://lists.torproject.org/pipermail/tor-relays/2018-May/015277.html I
started looking into what is happening on the dir port on my relay
(855BC2DABE24C861CD887DB9B2E950424B49FC34)
The bandwidth ratio of dir/or traffic is around 3% to 4%. Not excessive
according to t
So I am considering running a bridge alongside my relay gotland
Would the bridge use the same public IP address as the relay?
Since you already run a relay, that IP address is public. The point of
bridges is that they are not public so they are harder to block.
A government that censors the inte
Just looked over a sample of FallBackDir relays in Relay Search and
it appears this excess-load abuse is directed at them in particular.
Some fall-back directories show more than a month of excess request
traffic, presumably on the DirPort. Logs here indicate six weeks
of abuse escalating in inc
There are new security releases today. The official announcement just
went to tor-announce, but I want to make sure that people on this list
see it too.
The debian package showed up today. I upgraded from 3.2.9 to 3.2.10 and
removed my firewall connection limits.
My early first impressions ar
On 2018-02-20 22:37:42, "teor" wrote:
Please open a ticket with the full stack trace, and your OS.
I opened a ticket:
https://trac.torproject.org/projects/tor/ticket/25316#ticket
Please let me know if there is anything more you need to know
___
tor
My relay (855BC2DABE24C861CD887DB9B2E950424B49FC34) just crashed with
the following error:
Feb 20 14:33:40.000 [err] tor_assertion_failed_(): Bug:
../src/or/circuitmux_ewma.c:711: scale_active_circuits: Assertion
e->last_adjusted_tick == pol->active_circuit_pqueue_last_recalibrated
failed; abor
No clue what it means and why it's necessary to spam the log file with
it.
I did report my situation in the only ticket I could find that seems
even vaguely appropriate:
https://trac.torproject.org/projects/tor/ticket/22212
___
tor-relays mailing lis
Check the logs, but they won't tell you much, and that's deliberate.
So I checked the tor log.
First part is before the "weirdness":
Dec 20 16:00:08.000 [notice] Heartbeat: Tor's uptime is 4 days 23:59
hours, with 36191 circuits open. I've sent 3686.92 GB and received
3646.75 GB.
Dec 20 16:00
My little guard node (855BC2DABE24C861CD887DB9B2E950424B49FC34) have
suddenly started to behave strangely. iftop (my "bandwidth monitor"),
shows twice as much sent traffic as received traffic. The traffic seems
to be distributed to a lot of ip addresses. No ip address stands out as
receiving ve
My relay ran out of connections once and also crashed once so I followed
the suggestions in the "DoS attacks are real (probably)" thread and
implemented connection limits in my firewall. Everything have run
smoothly since.
My only concern is how low I can set the number of connections per IP
I run the non-exit relay Logforme
(855BC2DABE24C861CD887DB9B2E950424B49FC34).
Today I saw a new warning in my tor log file:
Dec 07 09:48:12.000 [warn] Failing because we have 32735 connections
already. Please read doc/TUNING for guidance.
The relay runs on an old Debian Wheezy machine. Me
Saw a new thing in my tor log today:
Aug 01 11:07:27.000 [warn] Established prop224 intro point on circuit
799774346
According to google, prop224 is a new hidden service protocol?
https://trac.torproject.org/projects/tor/ticket/12424
Which sounds like a great thing. But why do I get a warning
On 2017-06-27 12:35:21, "Sebastian Urbach" wrote:
Dear list,
My Exit:
https://atlas.torproject.org/#details/4198BD138E5E11B15B05C826B427148CED7D99FE
My Consendus Weight dropped to 20 today and i found the following in
notices.log:
Jun 27 12:03:35.000 [warn] http status 502 ("Bad Gateway")
Just upgraded my relay 855BC2DABE24C861CD887DB9B2E950424B49FC34 to
0.2.9.10 and now I get a new warning in the log file:
Mar 13 12:02:22.000 [notice] Bootstrapped 100%: Done
Mar 13 12:03:20.000 [warn] Cannot make an outgoing connection without a
DirPort.
Mar 13 12:03:21.000 [notice] Self-testin
I had 3 today on my non-exit relay. Can't remember seeing them before.
Maybe they are new in 0.2.8.8?
Times are UTC+2
Oct 06 09:14:03.000 [warn] Duplicate rendezvous cookie in
ESTABLISH_RENDEZVOUS.
Oct 06 14:08:13.000 [warn] Duplicate rendezvous cookie in
ESTABLISH_RENDEZVOUS.
Oct 06 14:08:14.
Looking at Atlas your relay advertises 2.45 MB/s which is quite low for
a 100Mbit connection: 2.45 MByte x 8 = 19.6 MbitWhat value do you have
in your torrc? For a 100mbit connection it should be at least:
BandwidthRate 12 MB
-- Originalmeddelande --
Från: "Roman Mamedov"
Till: "Aeri
My relay, Logforme (855BC2DABE24C861CD887DB9B2E950424B49FC34), is not on
the list even though it fits all the criteria, except the HSDir flag
which I lost when I upgraded to the latest version.
Hint, hint, Mr Roger "We should somehow teach everybody that losing
their flags for a few da
On 2015-12-14 19:12, Dr. Who wrote:
> Wouldn't it be better to monitor the reason for a drop in uptime? In
> case at the same time a restart occurs the version increases it might be
> given the HSdir flag again?
>
Can't see why, for example the Debian /etc/init.d/tor script, couldn't
send tor a fla
On 2015-11-09 08:56, Matthew Finkel wrote:
> On Wed, Nov 04, 2015 at 08:00:52AM +0100, Logforme wrote:
>> After seeing this I upgraded to the latest version 0.2.7.4-rc and on the
>> restart it again used Faravahar to (correctly) guess the IP:
>>
>> Nov 04 07:47:49.
Happened again tonight:
Nov 04 05:23:43.000 [notice] Our IP Address has changed from
84.219.173.60 to 185.99.185.61; rebuilding descriptor (source:
154.35.175.225).
Nov 04 05:23:43.000 [notice] Self-testing indicates your ORPort is
reachable from the outside. Excellent. Publishing server descripto
rting the issue and running a relay.
>
> All the best,
> Sina
>
>
> "Be the change that you wish to see in the world." - Mahatma Gandhi
>
> - On Oct 22, 2015, at 11:22 AM, Logforme m7...@abc.se wrote:
>
>> I run the relay Logforme (855BC2DABE24C861CD887DB9B2E9
I run the relay Logforme (855BC2DABE24C861CD887DB9B2E950424B49FC34)
Saw this in yesterday's log file:
Oct 22 03:17:55.000 [notice] Our IP Address has changed from
84.219.173.60 to 154.35.32.5; rebuilding descriptor (source:
154.35.175.225).
Oct 22 03:17:55.000 [notice] Self-testing indicates
FYI
I run the relay 855BC2DABE24C861CD887DB9B2E950424B49FC34. Today I found
a message in the log file I have not seen before:
Jun 26 18:05:20.000 [warn] circuit_unlink_all_from_channel(): Bug:
Circuit on detached list which I had no reason to mark
Relay continues to run fine with 30 days uptime.
On 2014-12-15 19:43, Nick Mathewson wrote:
> On Wed, Dec 10, 2014 at 2:31 AM, Roger Dingledine wrote:
>> On Sun, Dec 07, 2014 at 01:43:46PM +0100, Logforme wrote:
>>> To me it looks like an attacker that ramped up over a 6 hour period and
>>> then stopped building
On 2014-12-10 08:31, Roger Dingledine wrote:
> Careful with your conclusion there -- because of memory fragmentation,
> the process can still hold the memory even when Tor has freed the memory.
htop currently shows 3622/3858 Mem used and 1545/3136 Swap used. (if I
remember correctly it's usually le
On 2014-12-07 12:20, Roger Dingledine wrote:
> Has anybody else here seen messages like this?
I looked through the old log files and found the following memory messages:
Dec 06 03:33:06.000 [notice] Removed 334229280 bytes by killing 1
circuits; 16401 circuits remain alive.
Dec 06 05:27:25.000 [no
I run the relay Logforme (855BC2DABE24C861CD887DB9B2E950424B49FC3).
Yesterday I saw new messages in the log file:
Dec 06 09:28:13.000 [notice] We're low on memory. Killing circuits with
over-long queues. (This behavior is controlled by MaxMemInQueues.)
Dec 06 09:28:16.000 [notice] Re
Update to the latest version of tor: 0.2.5.10
I believe that resolution was clearly stated here. And also mentioned in
the announcement of 0.2.5.10
https://blog.torproject.org/blog/tor-02510-released-and-tor-023x-deprecated
"Downgrade the severity of the 'unexpected sendme cell from client' from
'w
The relay is reported as having "Advertised Bandwidth: 60.55 kB/s"
(about 480 kbits/s):
https://globe-node.herokuapp.com/relay/48ADFCC561402D7EBB1CDE233F206B01D8FA0765
What does your bandwidth rate values in torrc say?
On 2014-11-01 10:46, Rafael Rodriguez wrote:
>
> Anyone knows how often bwauths
Click on the "Download" button on torproject.org. This brings you to the
"easy" download page with just the browser bundle. Click on the "View
All Downloads" link to get all available options:
https://www.torproject.org/download/download.html.en
On 2014-10-31 09:18, Rafael Rodriguez wrote:
>
> Hel
My tor log file is usually quite boring but today it looks like this:
Jun 14 13:42:46.000 [warn] Hash of session info was not as expected.
Jun 14 13:57:56.000 [warn] Hash of session info was not as expected.
Jun 14 14:11:58.000 [warn] Hash of session info was not as expected.
A new line about ever
On 2013-10-14 22:01, Chris Whittleston wrote:
> I see - so I'll probably still see the problem with a huge number of
> circuits being created after I've finished building 0.2.4. Is there
> any way to limit this, I'm guessing reducing the bandwidth wouldn't
> actually help? I guess I'll look into ho
If you look at #2 here:
https://metrics.torproject.org/relay-search.html?search=72227B12964210DE79DD6413AF8BB39DE93C4C8C
it says "Unmeasured=1". #1 does not have that. So I guess the dirauths
have not gotten around to measure the real bandwidth of #2. It's still
in "phase one" or "phase two" accord
Weird that #1 has the stable flag and #2 don't then.
"Stable" -- A router is 'Stable' if it is active, and either its
Weighted MTBF is at least the median for known active routers or its
Weighted MTBF corresponds to at least 7 days."
The above suggests that #1 has been known to the dirauths for a w
Your #2 relay is only advertising 83.96 KB/s so it's no surprise it gets
low traffic.
Can it be that #1 is an old relay and #2 is relatively new? If #2 is new
it needs time to ramp up traffic:
https://blog.torproject.org/blog/lifecycle-of-a-new-relay
On 2013-09-18 18:57, Christian Dietrich wrote:
Don't know if it's of interest but here's my log for the first 24 hours
with 0.2.4.17-rc:
Sep 05 17:23:59.000 [notice] Circuit handshake stats since last time:
435758/1722581 TAP, 1503/1503 NTor.
Sep 05 18:23:59.000 [notice] Circuit handshake stats since last time:
167983/1616396 TAP, 1427/1427 NT
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Upgraded to 0.2.4.17-rc and almost immediately got the following in my
syslog:
debian kernel: [5000394.949751] TCP: Possible SYN flooding on port 443.
Sending cookies. Check SNMP counters.
No idea what it means. 443 is my or port. Tor is running fin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> I'm currently seeing more than a doubling of connections (from a mean of
> c. 2000 established connections to just over 5000) on my relay at
> 0xbaddad. The log is full of the (expected) messages:
> "Your computer is too slow to handle this many ci
var:
When the relay starts our Internet goes down. Its more like some
DNS problem but i cant point the finger on it. The connection is
still there but he need a lot of time to resolve the names.
Is this a overkill for our router?
My first question is, what kind of router are you using, and does
Thanks for all the input guys.
See some advice here:
http://archives.seul.org/or/relays/Aug-2010/msg00034.html
Found that before and I have followed it to the letter when I set up the
relay
Also are you running with a lot of iptables/ip6tables rules active (or
any at
all)? If you do, conside
I recently upgraded from an adsl line to a 100mbit fiber connection.
Naturally I want to use most of this new bandwidth for my non-exit tor
relay. However, I run into messages like these:
Jul 22 17:40:26.000 [warn] Your computer is too slow to handle this many
circuit creation requests! Please c
I assume the ISP did a port scan. Do you have port 9050 open in your
firewall?
On 2013-07-10 15:57, Steve Snyder wrote:
My ISP recently sent to me a CERT-FI auto-report on malware-infected
servers in my ISP's address space. I was send this report because my
IP address was among those flagged.
73 matches
Mail list logo
