> On 6 Jan 2018, at 06:05, Zack Weinberg wrote:
>
>> On Fri, Jan 5, 2018 at 1:44 PM, tor wrote:
>> For relay operators using iptables connlimit to mitigate DoS attacks (or
>> increased load from new clients), is it better for the Tor network to use
>> "DROP" rules, or should we use something
On 08.01.2018 23:59, Dave Warren wrote:
> On 2018-01-08 14:09, Tortilla wrote:
>>
>> On Mon, January 8, 2018 11:25 am, Dave Warren wrote:
>>> On 2018-01-08 03:21, Florentin Rochet wrote:
> Perhaps in the case that the HS operator is not trying to mask the HS
> location, the act of mixing
Hi,
On 09/01/18 01:16, teor wrote:
> The FallbackDir flags on Consensus Health [2] have been updated.
> The flags on Relay Search (Atlas) [3] might take a few days to update.
Relay Search has now been updated.
Thanks,
Iain.
signature.asc
Description: OpenPGP digital signature
Dear Relay Operators,
Thanks to everyone who opted-in their relays as fallback directory
mirrors.
We rebuilt the list of fallbacks on the weekend. [0] The new list will
come out in Tor 0.3.2.9. It will be backported to all supported Tor
releases. [1]
The FallbackDir flags on Consensus Health [2]
Cool
> We have a map of over-loaded and under-loaded regions now:
> Go to https://atlas.torproject.org/#map
> And select "consensus weight versus bandwidth".
paul
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.
On Mon, Jan 08, 2018 at 03:59:25PM -0700, Dave Warren wrote:
> Even if Tor didn't supply any relay
> statistics, a curious and enterprising individual could "explore" by seeing
> what happens to a particular onion when one launches a DoS attack against an
> external IP that one believes might be c
On 2018-01-08 14:09, Tortilla wrote:
On Mon, January 8, 2018 11:25 am, Dave Warren wrote:
On 2018-01-08 03:21, Florentin Rochet wrote:
Perhaps in the case that the HS operator is not trying to mask the HS
location, the act of mixing public relay traffic can be nothing but a
*help* to defeat an
> On 9 Jan 2018, at 09:44, Paul Templeton wrote:
>
> Hi all,
>
> just a query - I get these unusual spikes on
> https://atlas.torproject.org/#details/867B95CACD64653FEEC4D2CEFC5C49B4620307A7
> (have a look at the three month chart) and I notice some of the other AU
> relays do the same.
>
>
Hi all,
just a query - I get these unusual spikes on
https://atlas.torproject.org/#details/867B95CACD64653FEEC4D2CEFC5C49B4620307A7
(have a look at the three month chart) and I notice some of the other AU relays
do the same.
can anyone tell me what they are
Paul
__
> On 9 Jan 2018, at 05:56, John D. McDonnell wrote:
>
> I'd appreciate any tips and pointers you can send my way. And if the consumer
> routers are the issue, I can move my one exit relay to one of the other
> connections I have and not use it at the location (or just run one that's
> slower)
Yeah, I've read the lifecycle of a new relay but since I'm running exits, I
thought it might try to use more of my bandwidth by default. So I'm not sure if
it's just the warmup period or if it's something I've misconfigured. I'm also
not sure if it's just a limitation of the hardware I'm running
On Mon, January 8, 2018 11:25 am, Dave Warren wrote:
> On 2018-01-08 03:21, Florentin Rochet wrote:
>>> Perhaps in the case that the HS operator is not trying to mask the HS
>>> location, the act of mixing public relay traffic can be nothing but a
>>> *help* to defeat anyone trying to correlate t
On Mon, January 8, 2018 2:21 am, Florentin Rochet wrote:
> Hey Tortilla,
>
> Sorry for the late reply:
>
> On 2018-01-05 21:13, Tortilla wrote:
>>> The issue is fixed by adding the above warning message: if you care
>>> about your hidden service's "hidden" property, do not run a relay on
>>> the
Thanks John, glad to hear the average is more in line. Sorry if you're
already aware of this but here's a nice read that might help...
https://blog.torproject.org/lifecycle-new-relay
It can take a long while for the bandwidth authorities to warm up to
relays. If you're seeing slack in a new-ish r
Normalcitizen: E51620B90DCB310138ED89EDEDD0A5C361AAE24E
> Original Message
> Subject: [tor-relays] Become a Fallback Directory Mirror
> Local Time: 21 December 2017 12:50 AM
> UTC Time: 20 December 2017 23:50
> From: teor2...@gmail.com
> To: tor-relays@lists.torproject.org
>
>
Sorry for top posting, but I don't have my mail client configured for a more
proper inline or bottom posting. (I did that when I first got here but was
forced to change it to appease my boss.)
The average metric you are referring to is the one that is updated with the bar
graph correct? That on
Hi John, thanks for pointing this out! Just took a quick peek at the
source and the 'measured: x' comes from your relay's consensus entry.
On reflection though that's stupid of me since that's the bandwidth
authority weight which is a unit-less heuristic (baka!).
https://gitweb.torproject.org/tors
On 2018-01-08 03:21, Florentin Rochet wrote:
Perhaps in the case that the HS operator is not trying to mask the HS
location, the act of mixing public relay traffic can be nothing but a
*help* to defeat anyone trying to correlate traffic coming to the HS with
traffic emanating from any one client.
I'm not sure if reporting is off or something isn't configured right or
whatever it could be, but when running nyx, it is telling me that the measured
rate is 229.0 B/s which to me, sounds ridiculously slow. Where is it getting
the measured rate from? Is it a calculation on how much data is pass
Fingerprint:
A2A6616723B511D8E068BB71705191763191F6B2
Address:
87.118.122.120:443
> Original Message
> Subject: [tor-relays] Become a Fallback Directory Mirror
> Local Time: 21 December 2017 12:50 AM
> UTC Time: 20 December 2017 23:50
> From: teor2...@gmail.com
> To: tor-relays@l
Hi
Added two new members to my family
92412EA1B9AA887D462B51D816777002F4D58907
360CBA08D1E24F513162047BDB54A1015E531534
They are few days old and about to be confirmed.
Best regards
Anders
Sent with [ProtonMail](https://protonmail.com) Secure Email.
> Original Message
> Subje
2018-01-08 1:15 GMT+00:00 George :
>
> For anyone running *BSD bridges that wasn't aware, there are obfs4proxy
> packages/ports available for each of the BSDs:
>
> FreeBSD as security/obfs4proxy-tor
>
> NetBSD as net/obfs4proxy
>
> OpenBSD as net/obfs4proxy
>
> DragonFlyBSD as security/obfs4proxy-t
Hey Tortilla,
Sorry for the late reply:
On 2018-01-05 21:13, Tortilla wrote:
The issue is fixed by adding the above warning message: if you care
about your hidden service's "hidden" property, do not run a relay on the
same process.
Would you mind elaborating? As I read the tracker link, the i
23 matches
Mail list logo
