>Hi tor-relays mailing list,
>
>Good news! Verizon unblocked tor26 (86.59.21.38).
>
>I posted something similar on NANOG (with modifications for network people)
>here:
>https://mailman.nanog.org/pipermail/nanog/2018-May/095386.html
>
>Someone nice at Verizon must have read NANOG (VZ NOC people pr
At 18:29 5/21/2018 +, Logforme wrote:
>
>How can I find this information on my relay?
>(855BC2DABE24C861CD887DB9B2E950424B49FC34)
>
Is visible here
https://metrics.torproject.org/rs.html#details/855BC2DABE24C861CD887DB9B2E950424B49FC34
Click on the Bandwidth History "3-Month" tab. Your re
Recently I noticed excessive DirPort requests to my relay, where DirPort
bandwidth reached 15% of ORPort bandwidth. Normal DirPort load is around 2%.
https://lists.torproject.org/pipermail/tor-relays/2018-May/015253.html
Just looked over a sample of FallBackDir relays in Relay Search and
it app
On May 20, 2018 17:37:07 UTC, Damian Johnson atagar at torproject.org wrote:
>
>> There don't seem to be any examples of ORPort endpoints in the Stem
>> repository. I think Dave plans to add some more documentation as part of Tor
>> Summer of Privacy.
>
>Oh interesting. You're right. I recently add
On May 20, 2018 10:08:17 UTC, gustavo wrote:
>
>On May 18, 2018 4:25:23 PM UTC, starlight.2017q4 at binnacle.cx wrote:
>>Lately seeing escalating abuse traffic on the relay dirport, now up to
>>20k rotating source IP addresses per week.
>
>How do you detect it?
FI
Dirport is a handy convenience, but is not essential to proper
functioning of the network. Put a connection rate-limit on
dirport and it stopped the abuser cold. Dirport traffic went
from 15% of total back down to 1-2% where it belongs.
Nonetheless the questions posed are valid.
At 12:25 5/18
At 19:25 5/15/2018 +, r1610091651 wrote:
>I've noticed unusual load on the relay. Notice the huge change in load
>between 3-8 am (CET).
...
>Wondering if others experienced it recently?
One here. Perhaps isolated probes?
May 18 11:23 Tor[]: Circuit ... : 10279/10279 TAP, 296594/296595 NTor
Lately seeing escalating abuse traffic on the relay dirport, now up to 20k
rotating source IP addresses per week.
The simple solution is to disable dirport, but the relay is a fallback
directory and I don't want to make a change that will negatively affect the
relay's ability to function as suc
At 03:20 3/23/2018 +, tor wrote:
>> Suggestion: DoSCircuitCreationMinConnections=1 be established in consensus
>
>The man page for the above option says:
>
>"Minimum threshold of concurrent connections before a client address can be
>flagged as executing a circuit creation DoS. In other words
Came in a day early with six authorities voting yea and three voting nay.
Implies the median uptime percentage for guard candidates is slightly under
95.8.
NSDFreedom_guard_recovery.xls
Description: Binary data
___
tor-relays mailing list
tor-relays@l
Please note:
Here parameter DoSCircuitCreationMinConnections=1 is set (rather than the
default value of 3).
Mar 11 17:23:53 Tor[]: DoS mitigation since startup: 0 circuits rejected . . .
. . .
Mar 22 11:23:54 Tor[]: DoS mitigation since startup: 299608 circuits rejected.
. .
Mar 22 17:23:54 Tor
Can't win! Lesson here is never hack a spread-sheet
for someone else's relay ;-)
Data elements were reverse-order relative to the
sheet and I forgot to reverse them. I _think_
this is correct. . .Guard flag comes back Saturday 3/24.
I'll have to write a perl or python script sometime
to pull da
Actually I badly munged the entire right-side.
Should have written a perl script or C program
to do this--spread-sheet is a terrible hack.
Fixup attached here.
Your relay should be a guard again by the end
of next Wednesday on 3/28, allowing the auths
are in a nice mood and 96.2 is adequate.
Worst
Flubbed a date paste on the right-side (visual aid only)
but calc is correct. Fix is to copy I3, paste it to I4:I8.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
What might not be directly obvious is the calculation bases
on 12-hour intervals where on each interval the previous
uptime is down-weighted to 95% of the next-most-recent. OnionOO
uptime intervals are four hours, so each set of three OO
intervals are averaged as a single 12-hour interval and then
>While I understand that my relay lost the guard flag because of a weekend
>of downtime, I would expect that it would get it back after a while of
>stable again? Anyone able to shed some light on when it will get the flag
>back?
>https://metrics.torproject.org/rs.html#details/924B24AFA7F075D059E8EE
Back to normal! Check out the final two log entries.
Thank you David Goulet and all the Tor devs!!!
Feb 24 22:45 Tor 0.3.3.2-alpha (...) running on Linux with . . .
.
.
.
Mar 2 21:09 Circuit handshake stats since last time: 247305/247482 TAP,
4620773/4622133 NTor.
Mar 3 03:09 Circuit handsha
>> On 19. Feb 2018, at 22:38, starlight.2017q4 at binnacle.cx wrote:
>>
>> noticed gablemoo's BW scanner is offline and the entry for it at
>>
>> https://consensus-health.torproject.org/#bwauthstatus
>>
>> was removed; is it gone or just taking
noticed gablemoo's BW scanner is offline and the entry for it at
https://consensus-health.torproject.org/#bwauthstatus
was removed; is it gone or just taking an extended break?
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://list
On 12 Feb (19:44:02 UTC), David Goulet wrote:
>Wow... 1599323088 bytes is insane. This should _not_ happen for only 1
>circuit. We actually have checks in place to avoid this but it seems they
>either totally failed or we have a edge case.
>
>Can you tell me what scheduler were you using (look for
After many crashes and much pain, I determined that
having CellStatistics enabled causes a busy relay
to consume at least two or three _gigabytes_ of
additional memory. Relay operators with less than
16GB per instance are advised to disable it.
By default CellStatistics is disabled unless explici
At 07:36 12/31/2017 -0500, I wrote:
>
>. . . suggest adding support for circuit-extend rate-limiting of some kind or
>another. . .
also:
Heartbeat: Tor's uptime is 10 days 0:00 hours, with 115583 circuits open.
I've sent 5190.11 GB and received 5048.62 GB.
Circuit handshake stats since last time
At 07:36 12/31/2017 -0500, I wrote:
>
>. . . suggest adding support for circuit-extend rate-limiting of some kind or
>another. . .
Further in support of the request, for _12_hours_ preceding the most recent
crash, the daemon reported:
Your computer is too slow to handle this many circuit creati
At 18:25 12/30/2017 -0500, Roger Dingledine wrote:
Thank you Roger for your detailed reply.
I have some observations:
1) An additional contingent of dubious clients exists aside from the newly
arrived big-name-hoster instances each generating _hundreds_of_thousands_ of
connection requests _per
I realize we're in the middle of the Christmas / New Year dead week, but it
would be great one of the developers could says something (anything) about the
ongoing denial-of-service attacks.
My node crashed a second time a fews days back, and while the second iteration
of hardening appears have
>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 has run
>smoothly since.
I missed this thread, thank you for highlighting it!
>My only concer
Guard relay here appears to have come under steadily increasing abuse over the
last several months. Belive the two previous threads relate to the same issue:
Failing because we have 4063 connections already
// Number of file descriptors
DoS attacks are real
Several times a day a large
; wrote:
>
>> On Tue, Nov 28, 2017 at 08:06:11PM -0500, starlight.2017q4 at binnacle.cx
>> wrote:
>> > The population of these has been climbing for more than a week and
>> no-one has commented, which seems odd. No contact provided.
>> >
>> > https://atlas
The population of these has been climbing for more than a week and no-one has
commented, which seems odd. No contact provided.
https://atlas.torproject.org/#search/UbuntuCore
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.to
29 matches
Mail list logo
